Message ID | 2f2f96d3-5487-f791-8554-310beae0721b@gmail.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 112846 invoked by alias); 13 Jun 2018 18:19:15 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <libc-alpha.sourceware.org> List-Unsubscribe: <mailto:libc-alpha-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 112778 invoked by uid 89); 13 Jun 2018 18:19:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=customizing, Customizing, interfere X-HELO: mail-oi0-f68.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=r2ZSLtJYWb+3OD/CA+BOuILtmFV7GbXUSULBdbxuGaI=; b=edLkoAG/nky/m8MIWig80oP2kHaLAg8B3S/s4airCZOaCZglri19lzC0GvFax93hhI J07qyaPdxqZ8Vvg0K2Jqz5Jz+Sqr+1Cecjb8RcGSFo6neJN04BqDVodaldwJn3JVTaF7 YFyOmEXRK8QB/jbbanAeUB+ASx0PZTC8qwuGi5yBNmKh4hb3ZqOjzAItP3tIKJmgVvGa 2kHRLcnPMKfoXkq9Mv9m+WyKHhz4j8DM6QBCEVcJdxdgu4Br91/LUzF7wGPC6sgU1R70 9NW8obUTJTjsT4iZ/F78mdTTgKHHRVClMc/JPpRHDEZHjwRdoIeVz0g2PGSNrE2xHgdC u3EQ== X-Gm-Message-State: APt69E2HRxsOwiF/Fyn1SbED3fkLtGzFD85HWZGafwkutFgsMxBuiLge kTBrnPCUQAw+e0xZ0D1CX4WbCg== X-Google-Smtp-Source: ADUXVKJQhGuDaIEB43YjBJN2sacOqVC0sP87lIk+jdZJET6krZ3TYDDJIo4cBuJkoQGeHBecKa9QEg== X-Received: by 2002:aca:f5d5:: with SMTP id t204-v6mr5248210oih.27.1528913944512; Wed, 13 Jun 2018 11:19:04 -0700 (PDT) To: GNU C Library <libc-alpha@sourceware.org> From: Martin Sebor <msebor@gmail.com> Subject: [PATCH] mention disabling GCC built-ins for customization Message-ID: <2f2f96d3-5487-f791-8554-310beae0721b@gmail.com> Date: Wed, 13 Jun 2018 12:19:00 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------DB97722BA970804A50F42B56" |
Commit Message
Martin Sebor
June 13, 2018, 6:19 p.m. UTC
The GCC sprintf optimization introduced in GCC 7 relies on the conformance of the library implementation of formatted I/O functions. When a sprintf customization changes the effects of the function in a way that's observable by a strictly conforming program it might interfere with the optimization. Since this may not be obvious to users the attached patch adds a couple of sentences to the manual to make it clear that the sprintf built-in handling needs to be disabled when customizing the function. Martin
Comments
* Martin Sebor: > @strong{Portability Note:} The ability to extend the syntax of > @code{printf} template strings is a GNU extension. ISO standard C has > -nothing similar. > +nothing similar. When using the GNU C compiler or any other compiler > +that interprets calls to standard I/O functions according to the rules > +of the language standard it is necessary to disable such handling by > +the appropriate compiler option. Otherwise the behavior of a program > +that relies on the extension is undefined. Aren't there ISO extensions to C which define additional format specifiers which GCC knows nothing about? So maybe it makes more sense to say that if the application uses format specifiers not known by GCC, behavior is undefined (unless the compiler option is used).
On 06/13/2018 02:35 PM, Florian Weimer wrote: > * Martin Sebor: > >> @strong{Portability Note:} The ability to extend the syntax of >> @code{printf} template strings is a GNU extension. ISO standard C has >> -nothing similar. >> +nothing similar. When using the GNU C compiler or any other compiler >> +that interprets calls to standard I/O functions according to the rules >> +of the language standard it is necessary to disable such handling by >> +the appropriate compiler option. Otherwise the behavior of a program >> +that relies on the extension is undefined. > > Aren't there ISO extensions to C which define additional format > specifiers which GCC knows nothing about? So maybe it makes more > sense to say that if the application uses format specifiers not known > by GCC, behavior is undefined (unless the compiler option is used). The GCC optimization is disabled when the format string contains invalid or unhandled specifiers/modifiers etc, so even those may still be undefined in Glibc they aren't a problem for GCC. What would cause a problem for the GCC optimization is a change to the behavior of one of the standard conversions, like %i, or %s. One example would be changing the number of bytes output by the conversion. Another example of a future GCC optimization that would lead to undefined behavior is a hook that modified the string argument to %s (when GCC starts to assume that the argument is not clobbered by a sprintf call). Martin
* Martin Sebor: > On 06/13/2018 02:35 PM, Florian Weimer wrote: >> * Martin Sebor: >> >>> @strong{Portability Note:} The ability to extend the syntax of >>> @code{printf} template strings is a GNU extension. ISO standard C has >>> -nothing similar. >>> +nothing similar. When using the GNU C compiler or any other compiler >>> +that interprets calls to standard I/O functions according to the rules >>> +of the language standard it is necessary to disable such handling by >>> +the appropriate compiler option. Otherwise the behavior of a program >>> +that relies on the extension is undefined. >> >> Aren't there ISO extensions to C which define additional format >> specifiers which GCC knows nothing about? So maybe it makes more >> sense to say that if the application uses format specifiers not known >> by GCC, behavior is undefined (unless the compiler option is used). > > The GCC optimization is disabled when the format string contains > invalid or unhandled specifiers/modifiers etc, so even those may > still be undefined in Glibc they aren't a problem for GCC. Good. > What would cause a problem for the GCC optimization is a change > to the behavior of one of the standard conversions, like %i, or > %s. One example would be changing the number of bytes output by > the conversion. Another example of a future GCC optimization > that would lead to undefined behavior is a hook that modified > the string argument to %s (when GCC starts to assume that > the argument is not clobbered by a sprintf call). So it's not so much about extending the syntax, but altering the behavior of existing syntax, right?
On 06/13/2018 03:01 PM, Florian Weimer wrote: > * Martin Sebor: > >> On 06/13/2018 02:35 PM, Florian Weimer wrote: >>> * Martin Sebor: >>> >>>> @strong{Portability Note:} The ability to extend the syntax of >>>> @code{printf} template strings is a GNU extension. ISO standard C has >>>> -nothing similar. >>>> +nothing similar. When using the GNU C compiler or any other compiler >>>> +that interprets calls to standard I/O functions according to the rules >>>> +of the language standard it is necessary to disable such handling by >>>> +the appropriate compiler option. Otherwise the behavior of a program >>>> +that relies on the extension is undefined. >>> >>> Aren't there ISO extensions to C which define additional format >>> specifiers which GCC knows nothing about? So maybe it makes more >>> sense to say that if the application uses format specifiers not known >>> by GCC, behavior is undefined (unless the compiler option is used). >> >> The GCC optimization is disabled when the format string contains >> invalid or unhandled specifiers/modifiers etc, so even those may >> still be undefined in Glibc they aren't a problem for GCC. > > Good. > >> What would cause a problem for the GCC optimization is a change >> to the behavior of one of the standard conversions, like %i, or >> %s. One example would be changing the number of bytes output by >> the conversion. Another example of a future GCC optimization >> that would lead to undefined behavior is a hook that modified >> the string argument to %s (when GCC starts to assume that >> the argument is not clobbered by a sprintf call). > > So it's not so much about extending the syntax, but altering the > behavior of existing syntax, right? Yes, that's probably pretty close. Just to be clear, it extends beyond changes to the printf behavior of directives. A %s hook, for example, cannot rely on being called for every %s conversion, even if it doesn't change its behavior. (Say if all it did was count its occurrences.) This is because GCC transforms printf("%s", s) to puts(s) and sprintf(d, "%s", s) to stcrpy(d, s). But adding a hook for a new/undefined conversion specification that doesn't match an existing one in any way should not be okay. Martin
On Jun 13 2018, Martin Sebor <msebor@gmail.com> wrote: > diff --git a/manual/stdio.texi b/manual/stdio.texi > index 38be236..d945955 100644 > --- a/manual/stdio.texi > +++ b/manual/stdio.texi > @@ -2963,7 +2963,11 @@ The facilities of this section are declared in the header file > > @strong{Portability Note:} The ability to extend the syntax of > @code{printf} template strings is a GNU extension. ISO standard C has > -nothing similar. > +nothing similar. When using the GNU C compiler or any other compiler > +that interprets calls to standard I/O functions according to the rules > +of the language standard it is necessary to disable such handling by > +the appropriate compiler option. Otherwise the behavior of a program > +that relies on the extension is undefined. The manual already says that redefining existing conversions causes problems: You can redefine the standard output conversions, but this is probably not a good idea because of the potential for confusion. Library routines written by other people could break if you do this. We should extend that with a stronger language, independent of any compiler behaviour. Andreas.
ChangeLog: * manual/stdio.texi (Customizing printf): Add a note to disable built-in handling. diff --git a/manual/stdio.texi b/manual/stdio.texi index 38be236..d945955 100644 --- a/manual/stdio.texi +++ b/manual/stdio.texi @@ -2963,7 +2963,11 @@ The facilities of this section are declared in the header file @strong{Portability Note:} The ability to extend the syntax of @code{printf} template strings is a GNU extension. ISO standard C has -nothing similar. +nothing similar. When using the GNU C compiler or any other compiler +that interprets calls to standard I/O functions according to the rules +of the language standard it is necessary to disable such handling by +the appropriate compiler option. Otherwise the behavior of a program +that relies on the extension is undefined. @node Registering New Conversions @subsection Registering New Conversions