That's one hell of an ugly command line#define! Do you really have ~1,000 separate strings in flash? Or, am I missing something with the comment in the header?

Can you also please put in the same PR tohttps://github.com/earlephilhower/newlib-xtensa ? The newlib-xtensa is the original source of this header, and when we update the library or compiler, if it's not in that other repo changes will get lost.

I counted 1128 PSTRs in Tasmota. And I agree this is the ugliest command line option I've ever seen. I maybe escaped too much, but I won't optimize it.

I will do the PR in newlib-xtensa too.

Can we add aPSTR16() PSTR4() to give the old behavior? Printing fromumm_info()umm_info(NULL, true) is using a (heap-less) print function that relies on16 4-byte alignment. It will need to be updated. I also have at least one other PR that depends on16 4-byte alignment.

Edited: changed reference to 16 to 4-byte alignment.

@mhightower83 are you sure about the 16 byte alignment thing? I am pretty sure we never had a 16 byte aligned PSTR. It used to be packed, byte-wise (which is what this PR is enabling)...

Oops, brain fog today that should have been 4 bytes. PSTR4()

@s-hadinger as@mhightower83 said, there may be issues with changing the alignment. How much have you tested with that macro override?

I didn't think this could be an issue since regular strings are not 4-bytes aligned.

I have Tasmota devices running for a few days with this macro and didn't observe any issue or crash. There was no issue reported on Discord either, but it's still a recent change.

I would expect a possible problem whenumm_info(NULL, true) is called. The print code usesets_strcpy() andets_strlen() which is only safe with word-aligned strings when usingPROGMEM. I don't think this would be used in production code, the printed results can only be seen on the serial port. Thus, I expect calls toumm_info(NULL, false), which does not print, would be harmless.

-edit- I see we crossposted, but had the same answer. :)

@s-hadinger, it's a little more complicated than that. RAM is fine reading byte-wide, but IROM(PSTR) needs special instructions to only to 32-bit reads and extract the byte needed.

The main library routines (all printf* variants, strcpy, etc.) all work with any alignment of data in strings.

However,@mhightower83 has some routines in a special-use section that need to be 4 byte aligned because his code can't afford to do the adjustments.

Good to know. As far as I know, we don't compile withumm_info() enabled in Tasmota.

The only places where I found a use ofumm_info_safe_printf_P was using theDBGLOG_FORCE which is used inumm_info.c with RAM strings only, noPSTR().

Did I miss something?

Anyways, there is no harm in adding aPSTR4() variant for 4-bytes aligned PSTR strings.

@s-hadinger, sorry there is a bit of macro nesting going on here to make it easier to change things as a group:

and I think only that last line will need to be changed to usePSTR4()

@mhightower83 thanks, I missed that macro.

@earlephilhower I changed the PR to addPSTR4() macro and changed theUMM_INFO_PRINTF() macro accordingly.

Thanks! LGTM.

Gentle bump. Is there anything more needed for merging?

@s-hadinger can you also port these final changes to newlib so they don't get lost? Thx!

With either 1 or 4 byte alignment I am getting crashes on my own code, which uses PSTR in the way tasmota does. To be specific "loadProhibited" and errors related to alignment when trying to use debug builds with vscode/platformio. Did you come across this and if so did you manage to clear the error. Many thanks.

@sparkplug23 Can you share the code of where it crashes?

@s-hadinger Thanks for replying. After spending days on this, as it always happens, the second you ask for help you find the problem! It seems I was using a PSTR incorrectly withsprintf, I am amazed this worked in release mode but not debug builds. Hopefully this was my only issue, I could be back haha. Great work on the code. I have around 2000 PSTRs in my code, so I know the feeling.