From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105175 invoked by alias); 27 Jun 2018 15:50:00 -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 104294 invoked by uid 89); 27 Jun 2018 15:49:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=practical X-HELO: mx1.redhat.com Subject: Re: [PATCH 0/9] Use more flags parameters instead of global bits in stdio To: Zack Weinberg , libc-alpha@sourceware.org, "Gabriel F. T. Gomes" References: <20180307193205.4751-1-zackw@panix.com> From: Florian Weimer Message-ID: <02d8eb49-00da-196a-66b2-66e376b3f66d@redhat.com> Date: Wed, 27 Jun 2018 15:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180307193205.4751-1-zackw@panix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-06/txt/msg00853.txt.bz2 On 03/07/2018 08:31 PM, Zack Weinberg wrote: > I got stuck on the patch to use C99-compliant scanf in _GNU_SOURCE > mode because the interaction with ldbl-is-dbl was too confusing. The > reason it's too confusing is that C99 compliance in scanf, ldbl-is-dbl > mode in scanf, printf, and strfmon, and fortify mode in printf are > handled with mode bits on the FILE and thread-global flags that must > be set and reset at just the right times. Correct behavior is > invariably to set and then reset around just one call to a lower-level > function, and there's a better way to do that: flags parameters. I looked at how this change interacts with printf format specifier callbacks. There currently does not appear to be a way to determine in the callback if an L argument was of double or long double type. There is code to adjust the argument type for double mode: case PA_DOUBLE|PA_FLAG_LONG_DOUBLE: if (__ldbl_is_dbl) { args_value[cnt].pa_double = va_arg (*ap_savep, double); args_type[cnt] &= ~PA_FLAG_LONG_DOUBLE; } else args_value[cnt].pa_long_double = va_arg (*ap_savep, long double); break; But I don't think args_type is ever read back, and it's not really accessible to the second callback function afterwards. With the thread-local variable, you can run something like this to determine if you are in double double or binary64 mode because snprintf will not reset the __no_long_double internal TLS variable: static bool is_long_double_mode (void) { char buf[64]; extern __typeof__ (snprintf) snprintf_alias __asm__ ("snprintf"); snprintf_alias (buf, sizeof (buf), "%.30Lf", 1234.0000000000000000000001L); puts (buf); return strcmp (buf, "1234.000000000000000000000099999997") == 0; } There does not seem to be any other way to get at this variable, so I'm not sure this is something we need to support going forward. The flag is not copied into the FILE * struct, either. Considering that is_long_double_mode is so inefficient, I don't think this is anything to worry about for real code. For the _IO_FLAGS2_FORTIFY flag, things are a bit different. It is currently copied into the FILE * struct, so it is in theory accessible to the printf callbacks. But it's now in an internal header, and it seems unlikely that any code would use it given that it was underdocumented before. Again, this doesn't look a practical problem. This concern does not apply to _IO_FLAGS2_SCANF_STD because there are no scanf hooks, so there isn't any problem there. So I think this means that the change from thread-local variable and in-FILE flags to an argument is conceptually valid. I have only started to review the implementation, though. Thanks, Florian