This is the mail archive of the
mailing list for the glibc project.
Re: Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c
Thanks a lot Godmar for your very kind and detailed explanation, and I
quite agree with you :D
On Mon, May 21, 2018 at 10:26 PM, Godmar Back <email@example.com> wrote:
> If you're looking at just the C standard, uintptr_t wouldn't help
> since it's only guaranteed to hold object pointers, not function
> I would dig deeper in terms of "implementation-defined". The C
> standards says that a conforming implementation should define the
> behavior of pointer to int conversions (except where undefined, which
> conversion of function pointers to integers are not). So somewhere,
> gcc/clang etc. - if conforming - will have to define what a function
> pointer converts to when converted to an int. This is, IMO, different
> from undefined behavior where the compiler can do whatever they please
> and doesn't owe anyone an explanation.
> See J.3 pg 566 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
> On Mon, May 21, 2018 at 9:18 AM, Remus Clearwater
> <firstname.lastname@example.org> wrote:
> > PS:
> > The definition of uintptr_t in C99 is:
> > “an unsigned integer type with the property that any valid pointer to
> > can be converted to this type, then converted back to pointer to void,
> > the result will compare equal to the original pointer”
> > On Mon, May 21, 2018 at 9:08 PM, Remus Clearwater
> > <email@example.com> wrote:
> >> Sorry for forgot to CC libc-help.
> >> ----
> >> Thanks a lot Godmar.
> >> But it didn't say `sizeof(function_pointer)` are must equal or less than
> >> `sizeof(void*)`.
> >> I found this in POSIX.1-2008
> >> http://pubs.opengroup.org/onlinepubs/9699919799.
> >> "All function pointer types shall have the same representation as the
> >> pointer to void. Conversion of a function pointer to void * shall not
> >> the representation. A void * value resulting from such a conversion can
> >> converted back to the original function pointer type, using an explicit
> >> cast, without loss of information.
> >> Note:
> >> The ISO C standard does not require this, but it is required for POSIX
> >> conformance."
> >> So under POSIX.1-2008 the kinda usage of `function_address = (uintptr_t)
> >> funcfp;` is correct, but in POSIX.1-2017 this section 2.13.3 has been
> >> removed. This means in POSIX.1-2017 that kinda conversition is still not
> >> defined.