On Jul 10 18:31, David Allsopp via Cygwin-patches wrote: > Corinna Vinschen wrote: > > On Jul 10 15:22, David Allsopp via Cygwin-patches wrote: > > > Corinna Vinschen wrote: > > > > On Jul 9 20:30, David Allsopp via Cygwin-patches wrote: > > > > > I have some code where the acl_t returned by get_file_acl is > > > > > allocated at 0x80038248. As a result the acl_entry_t generated by > > > > > acl_get_entry has an "index" of -1, since the pointer was sign- > > extended to 64-bits. > > > > > > > > > > My fix is trivial and simply casts the pointer to uintptr_t first. > > > > > > > > Pushed. I still don't quite understand what the compiler is > > > > thinking there, sign-extending a pointer when casted to an unsigend > > > > int type, but your patch works, so all is well, I guess. > > > > > > Thank you - it is indeed hard to imagine when you'd ever want that > > behaviour! > > > > I wonder if this is a bug in x86 gcc... Jon? > > I put it to our C gurus in the OCaml team - one (who has also written > a formally verified C compiler which on purpose 0-extends in this > case) observed that GCC does the same for ARM32 and another (who has > occasionally delighted in abusing language memory models to concoct > highly bizarre, but legal, abuses of undefined behaviour) found > https://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html...
"Bizarre" is the right description here :) Corinna -- Corinna Vinschen Cygwin Maintainer