From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93136 invoked by alias); 13 Jun 2018 21:31:11 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 92768 invoked by uid 89); 13 Jun 2018 21:30:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-oi0-f67.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1l4+HhKfK7Vz/+FJvgEiCWbkXLfIqcvNKmOw/PW3GYs=; b=QXvYmi+Tm4IzOIRXgIopHjeQr+z2pEUF/Fnw9TTSxjl6D4k0UVd45Pb9kXxDeXw/Ho JOienonCNLD2NhzqX1MwBNgbZYvvzBw9xvfFTwiMU3zKkvw8gGXAENNgS+sZrKrHRCkk fh0UDPUmC8Rm2+UCMLYuGZ1wc8oszr3SgQkrC95N1VKB7T0BztsP0440eRdnUbdLVeYw eZCEy1Dvy5KpQctVy5OHmhjvlCYRMHeu8i/vURbcfEUxa891vYSr6WsQ6cpPvbGBYUqD zimKiHnkDlFy+7qek0dEtnnlkpDNz/ZkCv0bxsV86foQ2uBTjWXNkKjX/UKUlCeQfbEq JURw== X-Gm-Message-State: APt69E1f5pGmGCLA6IKiJy6bka19NaDoR5KCyPpnscOYjsFJug4v6ruB CpUoPZTfdYgA2b1t3CNrFd8wLw== X-Google-Smtp-Source: ADUXVKKzLoBAFlWX4Q7BJ8QU9j9nLW4ah0+9Xkwm57Xf1J+q4FZE0GcMRlKd2hA8Sz2uysK8BFHWTw== X-Received: by 2002:aca:6289:: with SMTP id w131-v6mr1677851oib.201.1528925433943; Wed, 13 Jun 2018 14:30:33 -0700 (PDT) Subject: Re: [PATCH] mention disabling GCC built-ins for customization To: Florian Weimer References: <2f2f96d3-5487-f791-8554-310beae0721b@gmail.com> <87vaam1l28.fsf@mid.deneb.enyo.de> <69516fec-ef30-232a-cb4b-a1cc6d32e577@gmail.com> <87vaamxuy1.fsf@mid.deneb.enyo.de> Cc: GNU C Library From: Martin Sebor Message-ID: Date: Wed, 13 Jun 2018 21:31:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87vaamxuy1.fsf@mid.deneb.enyo.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00364.txt.bz2 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