From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91616 invoked by alias); 29 Jul 2017 13:57:55 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 91173 invoked by uid 89); 29 Jul 2017 13:57:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_05,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=HTo:U*joel, H*Ad:U*joel, POSIX_SOURCE, strtol X-HELO: mail-io0-f169.google.com Received: from mail-io0-f169.google.com (HELO mail-io0-f169.google.com) (209.85.223.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 29 Jul 2017 13:57:52 +0000 Received: by mail-io0-f169.google.com with SMTP id g13so97867143ioj.5 for ; Sat, 29 Jul 2017 06:57:52 -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; bh=hkEcpQXiSDx6IxhwgZLYDfSSCmBRIj20vOg5yEJ5zos=; b=tk+7AVqPntPoj3U7ZiXnKE/AUR6f2heB5qb7ktaahMWv6T+CRPJTXsturOZsPoDvN7 mK2wGvQ5km7xDnfufVUHaPWBwgXIBRnPJCK2DJvyq55f8l7ZnGqAsWVBxvwT7fbGESJw ei8YaUyjLrqPUln3oIpExv0vGm9HHOyErYN1S7yKKOqAM6tfPMxRbbavpLgyImuEWgOY S1FVBMqw1tz1PQmLCYQcbtee4QYStByW1WrdtRq9QONs6UDaEuzLyAWwJrBNl6p21BLG jtuDWPGPRVhPugDUWgr0wpnbfUJ0sfHYsO3ZRV26yHjgRurpoh2j7GlSCQQBgvdYPrPF ZVmQ== X-Gm-Message-State: AIVw112cv1/HcAy7M0KBNxUbG009LcV0kPCsVLwj/ymmHIQzJ8FHrqBL pcyEEDNByXOgPkRIKKxvNRhaqNkTyg== X-Received: by 10.107.134.87 with SMTP id i84mr12934097iod.255.1501336670924; Sat, 29 Jul 2017 06:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.124.208 with HTTP; Sat, 29 Jul 2017 06:57:50 -0700 (PDT) In-Reply-To: References: <20170726110849.GG14419@calimero.vinschen.de> <20170727123207.GB27695@calimero.vinschen.de> <20170728104304.GA24013@calimero.vinschen.de> <20170728130803.GD24013@calimero.vinschen.de> <20170728182942.GE24013@calimero.vinschen.de> From: Aditya Upadhyay Date: Sat, 29 Jul 2017 13:57:00 -0000 Message-ID: Subject: Re: Importing inttypes methods To: Gedare Bloom , newlib@sourceware.org, joel@rtems.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00697.txt.bz2 Yes, I am following the direction. Regards. Aditya Upadhyay On Sat, Jul 29, 2017 at 6:10 PM, Gedare Bloom wrote: > On Fri, Jul 28, 2017 at 2:29 PM, Corinna Vinschen wrote: >> On Jul 28 10:28, Gedare Bloom wrote: >>> On Fri, Jul 28, 2017 at 9:08 AM, Corinna Vinschen wrote: >>> > On Jul 28 07:40, Gedare Bloom wrote: >>> >> Corinna, good catch. I mentioned this issue to Joel but it dropped out >>> >> the bottom some how. Is it only (for example) the strtoimax_l() that >>> >> needs to be guarded, or also the _strtoimax_l? (I suspect only the >>> >> strtoimax_l, but want to be clear before the next round of patches >>> >> lands here.) >>> > >>> > The reentrant prototypes use locale_t, so they depend on including >>> > xlocale.h, too. It's a bit uncommon but the simplest solution. >>> > >>> Since the non-reentrant version (e.g., strtoimax) wraps the re-entrant >>> one, then there is no support unless locale is available. Would it be >>> better to have a non-reentrant, nonolocale implementation in tandem >>> with the reentrant one, or do we not worry about it and don't support >>> these functions at all unless the POSIX_SOURCE is set properly and >>> BSD_VISIBLE? >> >> Good catch on your side, I really had to look it up now. Here's how it >> is in the other, similar cases like strtol: >> >> There are actually four functions: >> >> strtol >> strtol_l >> _strtol_r >> _strtol_l >> >> _strtol_l is the internal implementation and *static*. _strtol_r >> is the exported reentrant function and consequentially not having >> the locale_t parameter. >> >> So, why not just keep it at that for now with strtoimax, etc? It only >> requires minimal changes and nobody using the reentrant functions >> actually asked for a reentrant function with thread-local locale >> parameter yet :} >> >> As a result, the guards for the exported reentrant functions are not >> required. >> > OK. Aditya please pursue this direction for implementation. It will > take a bit more refactoring to get it right. > >> >> Corinna >> >> -- >> Corinna Vinschen >> Cygwin Maintainer >> Red Hat