[PATCH] Fix incorrect sign-extension of pointer in 32-bit acl __to_entry

[Corinna Vinschen]

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