From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43112 invoked by alias); 22 May 2018 06:47:37 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 43043 invoked by uid 89); 22 May 2018 06:47:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*c:alternative X-HELO: mail-qt0-f171.google.com Received: from mail-qt0-f171.google.com (HELO mail-qt0-f171.google.com) (209.85.216.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 22 May 2018 06:47:29 +0000 Received: by mail-qt0-f171.google.com with SMTP id q13-v6so22075076qtp.4 for ; Mon, 21 May 2018 23:47:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uYimJC8siDNlPTziuBIr91b1Pvgcqi+dDnFBaI+OcNs=; b=sfG7ahahPAIVKxQEMpmd02ntfg/AsdFbJv6JORC9YX1rOuqaTdnCwpwcPRG0nVIAef QdZ3yFh+lBvuYawGpIAxNVZG5gCkqgYKpHSSEBzKwvJq7hJ+oUxNmtrkTQNpXeUkg2d+ z/iYBpMQkjxlDBFw4qMiyjC15FP6arrgKbserm1qi/mUnTdVl77uwrTYUSmxQkdTwSNJ Qdi0c0SWAZ8CE8/YtGsDmLqv5MUJN/h1XJhMlkoCNK2YCSB11UrPmTdYveu8OgPDY4Uh N//7m2zh/8h9TLGTMfO6I1F3ZWu8eR65HiJSPAUNLe6pSRGjUUOgeFNZ6b7FDBvkhnX+ V6KQ== X-Gm-Message-State: ALKqPweUablcWjZYXFjpoJ9YxHBq1/3HoTsTnwZXUAD71z+gEqXgWB9P IaNxLrxtg17JGSX5D0FaYKgpfbpaB7aKvuvBnyo= X-Google-Smtp-Source: AB8JxZqnWo1QthuqceAQhxYaxg175Oeg9+dyQDS0ygHNB9Wv79ePjuWatYYXqsdtGTsqB1W9iZYL+CwkTKKFAZwoiEk= X-Received: by 2002:ac8:6d2:: with SMTP id j18-v6mr20727264qth.306.1526971647649; Mon, 21 May 2018 23:47:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.232.13 with HTTP; Mon, 21 May 2018 23:47:27 -0700 (PDT) In-Reply-To: References: From: Remus Clearwater Date: Tue, 22 May 2018 06:47:00 -0000 Message-ID: Subject: Re: Undefined behaviour code used in sysdeps/unix/sysv/linux/x86_64/makecontext.c To: Godmar Back Cc: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00026.txt.bz2 Thanks a lot Godmar for your very kind and detailed explanation, and I quite agree with you :D All best Remus On Mon, May 21, 2018 at 10:26 PM, Godmar Back 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 > pointers > > 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 > wrote: > > PS: > > > > The definition of uintptr_t in C99 is: > > > > =E2=80=9Can unsigned integer type with the property that any valid poin= ter to > void > > can be converted to this type, then converted back to pointer to void, > and > > the result will compare equal to the original pointer=E2=80=9D > > > > On Mon, May 21, 2018 at 9:08 PM, Remus Clearwater > > 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 th= an > >> `sizeof(void*)`. > >> > >> I found this in POSIX.1-2008 > >> http://pubs.opengroup.org/onlinepubs/9699919799. > 2008edition/functions/V2_chap02.html#tag_15_12_03: > >> > >> "All function pointer types shall have the same representation as the > type > >> pointer to void. Conversion of a function pointer to void * shall not > alter > >> the representation. A void * value resulting from such a conversion can > be > >> 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 =3D (uintpt= r_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 n= ot > >> defined. > >> > > >