From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31370 invoked by alias); 30 Jul 2017 15:41: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 31347 invoked by uid 89); 30 Jul 2017 15:41:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-vk0-f48.google.com Received: from mail-vk0-f48.google.com (HELO mail-vk0-f48.google.com) (209.85.213.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 30 Jul 2017 15:41:50 +0000 Received: by mail-vk0-f48.google.com with SMTP id r199so19801944vke.4 for ; Sun, 30 Jul 2017 08:41:50 -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:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=iW4jgo8E7dwhRmcW7c5IRaH4h0BA1WynVX0zfbWVX3Y=; b=PQQj1n+hHEYnV+bONUyfSZP6pB5NGAV2FTru7DSJUfaeB4NxT8X14XCSOw5VH0b3PR jV5U3ZOUioDHUBlIVsKHCEGW5pnULwyqiS7ZIOgpD1OK34aI8oxUd0mmvKK5wmHzug3t b9+9A3vfbx9LFvdm2koAJ1RW/Q0vVKAj16boj25YtfzPMDpQltjhBCRpfZ4oHoSrZfDT 7X0zG9VvDdDTX5sUj6OySTrRFtf6a9tZaMGINhtFo65zeHbqsbwYuhwa1KfOxIFxkif8 n2cekdxxgaycJW50TbPQwkHS0XvqrFxjoFd2Jrt0Uvo+UiuBh2eGawq9iiDCLRYjutdK X/gg== X-Gm-Message-State: AIVw111m01Y+EfAU3iIJbLw3RqLKpdAKgCHs3rlLSCnkYUaHHqQReWk7 hhmtxWQF/8YijBFCLbtGtlv6H61utyQp X-Received: by 10.31.205.2 with SMTP id d2mr6931033vkg.77.1501429308326; Sun, 30 Jul 2017 08:41:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.59.29 with HTTP; Sun, 30 Jul 2017 08:41:47 -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: Gedare Bloom Date: Sun, 30 Jul 2017 15:41:00 -0000 Message-ID: Subject: Re: Importing inttypes methods To: Aditya Upadhyay Cc: "newlib@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00699.txt.bz2 On Sun, Jul 30, 2017 at 4:45 AM, Aditya Upadhyay wrote: > I have declared all *_l methods within __BSD_VISIBLE guard in > inttypes.h. I am attaching the patches for rest of the inttypes > methods. Please review the same. Also i have tried to make the line > length < 80 in inttypes.h file. > > Thanks & Regards, > Aditya > > On Sat, Jul 29, 2017 at 7:27 PM, Aditya Upadhyay wrote: >> 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 :} >>>> All, It looks like to me like the str*_l functions in stdlib.h currently are actually being guarded by __GNU_VISIBLE rather than __BSD_VISIBLE. You should see if these locale functions from BSD are in glibc, if so then I believe GNU_VISIBLE is the more appropriate guard? Someone more knowledgeable on the feature test macros might comment. Aditya, I think you have not quite followed this direction closely enough. You should have some function like _strtoimax_r as the exported re-entrant version without locale, and a static function _strtoimax_l for the private implementation. Again, see strtol.c for an example. Please rework each of your commits following that example as a pattern. If no one answers my question above, you should re-ask it as a separate email in a few days, or ping this. -Gedare >>>> 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