[just_curioussss]

This part is also suspicious:

p->fts_statp = (struct stat )ALIGN(p->fts_name + namelen + 2);*

Unless ALIGN aligns the pointer towards the lower address( which would be weird ), that +2 might get out of bounds depending on how many bytes is ALIGNBYTES.

Please correct me if I'm wrong.

Edit:

This is the header that defines the struct FTSENT:

https://opensource.apple.com/source/Libc/Libc-1044.40.1/incl...

[userbinator]

ALIGNBYTES is probably 3 or 7, depending on what ALIGN does, but the +2 seems like a bug to me. I think the intended layout is [FTSENT][name][0][optional [possible alignment padding][struct stat]] which means that +2 should really be a +1. The total memory allocated should be

    sizeof(FTSENT) + namelen + 1 + (padding + sizeof(struct stat))

(I Googled 'site:opensource.apple.com "#define ALIGNBYTES" inurl:.h' and got my query rewritten without the quotes and the dots in the domain name. No, I did NOT mean to search for anything else. Then I browsed to the 2nd page and got the "we detected suspicious activity" CAPTCHA. WTF?)

[just_curioussss]

I found a couple different definitions:

https://opensource.apple.com/source/OpenSSH/OpenSSH-95/opens...

https://opensource.apple.com/source/xnu/xnu-792.13.8/bsd/ppc...

https://opensource.apple.com/source/sendmail/sendmail-32/sen...

They align toward the higher address.

[anonbanker]

so the +2 is indeed out of bounds?

[just_curioussss]

Depending on the value of namelen, and the padding at the end of the struct FTSENT, struct p->fts_statp will occupy one byte out of bounds of the allocated memory.

The comment made in the code is incorrect:

Since the fts_name field is declared to be of size 1, the fts_name pointer is namelen + 2 before the first possible address of the stat structure.

namelen + 1 is the first possible address for the stat structure.

[just_curioussss]

Note, this refers to: https://opensource.apple.com/source/Libc/Libc-1044.40.1/gen/...

[just_curioussss]

No one will ever read this, but I just wanted to point out that the whole allocation is simply incorrect.

Even with just namelen+1 you can still get undefined behavior. This is because if namelen is shorter than the padding of the object struct FTSENT, the beginning of the next object struct stat, will overlap with the previous object.

The correct solution is to make sure that the next object begins after the first one, and still remains inside of the allocated block. This is a good example, why the struct hack just isn't worth it, and it itself is arguably undefined behavior.

To allocate it all, remove the struct hack and simply call the malloc three times, once for each struct and then for the string. If one allocation is required, then allocate enough memory for all three objects separated by enough alignment padding. Doing this will allocate a couple of bytes more which is a couple percent overall, but at least your code will be correct. Since they don't pack the struct thus loosing bytes for internal padding anyway, I can't understand why the usage of the struct hack.