| Message ID | 24683c8c-e21c-7b7f-8525-0cb847b6cd81@redhat.com |
|---|---|
| State | Committed |
| Headers |
Received: (qmail 113134 invoked by alias); 5 Oct 2017 09:50:35 -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 112721 invoked by uid 89); 5 Oct 2017 09:50:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RP_MATCHES_RCVD, SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=worried X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 70ECD7E42E Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer@redhat.com Subject: Re: Definition of __USE_MISC? To: Sebastian Huber <sebastian.huber@embedded-brains.de>, libc-alpha@sourceware.org References: <5421ae5a-3e23-bd54-4c8e-79997ae56906@embedded-brains.de> From: Florian Weimer <fweimer@redhat.com> Message-ID: <24683c8c-e21c-7b7f-8525-0cb847b6cd81@redhat.com> Date: Thu, 5 Oct 2017 11:50:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5421ae5a-3e23-bd54-4c8e-79997ae56906@embedded-brains.de> Content-Type: multipart/mixed; boundary="------------7E9D35EDA04BABFDD5764DEA" |
Commit Message
Florian Weimer
Oct. 5, 2017, 9:50 a.m. UTC
On 10/05/2017 08:07 AM, Sebastian Huber wrote: > Hello, > > according to the comment in features.h we have: > > __USE_MISC Define things from 4.3BSD or System V Unix. > > What about interfaces that are present on newer BSD systems by default, > e.g. we have in glibc strings.h: > > /* The following two functions are non-standard but necessary for non-32 > bit > platforms. */ > # ifdef __USE_GNU > extern int ffsl (long int __l) __THROW __attribute_const__; > __extension__ extern int ffsll (long long int __ll) > __THROW __attribute_const__; > # endif > > In FreeBSD strings.h we have: > > #if __BSD_VISIBLE > int ffsl(long) __pure2; > int ffsll(long long) __pure2; > int fls(int) __pure2; > int flsl(long) __pure2; > int flsll(long long) __pure2; > #endif > > Would it be possible to change the guard in glibc to __USE_MISC? Yes, it should be a simple change. I was worried about the long long part initially, but we have precedent for using long long under __USE_MISC (strtouq in <stdlib.h>). Patch attached. Thanks, Florian
Comments
On 05/10/17 11:50, Florian Weimer wrote: > On 10/05/2017 08:07 AM, Sebastian Huber wrote: >> Hello, >> >> according to the comment in features.h we have: >> >> __USE_MISC Define things from 4.3BSD or System V Unix. >> >> What about interfaces that are present on newer BSD systems by >> default, e.g. we have in glibc strings.h: >> >> /* The following two functions are non-standard but necessary for >> non-32 bit >> platforms. */ >> # ifdef __USE_GNU >> extern int ffsl (long int __l) __THROW __attribute_const__; >> __extension__ extern int ffsll (long long int __ll) >> __THROW __attribute_const__; >> # endif >> >> In FreeBSD strings.h we have: >> >> #if __BSD_VISIBLE >> int ffsl(long) __pure2; >> int ffsll(long long) __pure2; >> int fls(int) __pure2; >> int flsl(long) __pure2; >> int flsll(long long) __pure2; >> #endif >> >> Would it be possible to change the guard in glibc to __USE_MISC? > > Yes, it should be a simple change. I was worried about the long long > part initially, but we have precedent for using long long under > __USE_MISC (strtouq in <stdlib.h>). > > Patch attached. What are the opinions with respect to this patch? The ffsl() and ffsll() are BSD visible in FreeBSD, DragonFlyBSD, some Mac OS X and musl. They are not available in OpenBSD and NetBSD.
On 10/10/2017 07:41 AM, Sebastian Huber wrote: > On 05/10/17 11:50, Florian Weimer wrote: > >> On 10/05/2017 08:07 AM, Sebastian Huber wrote: >>> Hello, >>> >>> according to the comment in features.h we have: >>> >>> __USE_MISC Define things from 4.3BSD or System V Unix. >>> >>> What about interfaces that are present on newer BSD systems by >>> default, e.g. we have in glibc strings.h: >>> >>> /* The following two functions are non-standard but necessary for >>> non-32 bit >>> platforms. */ >>> # ifdef __USE_GNU >>> extern int ffsl (long int __l) __THROW __attribute_const__; >>> __extension__ extern int ffsll (long long int __ll) >>> __THROW __attribute_const__; >>> # endif >>> >>> In FreeBSD strings.h we have: >>> >>> #if __BSD_VISIBLE >>> int ffsl(long) __pure2; >>> int ffsll(long long) __pure2; >>> int fls(int) __pure2; >>> int flsl(long) __pure2; >>> int flsll(long long) __pure2; >>> #endif >>> >>> Would it be possible to change the guard in glibc to __USE_MISC? >> >> Yes, it should be a simple change. I was worried about the long long >> part initially, but we have precedent for using long long under >> __USE_MISC (strtouq in <stdlib.h>). >> >> Patch attached. > > What are the opinions with respect to this patch? The ffsl() and ffsll() > are BSD visible in FreeBSD, DragonFlyBSD, some Mac OS X and musl. They > are not available in OpenBSD and NetBSD. Unless there are objects, I'm going to check this in later this week. Thanks, Florian
On 17/10/17 14:01, Florian Weimer wrote: >>>> >>>> Would it be possible to change the guard in glibc to __USE_MISC? >>> >>> Yes, it should be a simple change. I was worried about the long >>> long part initially, but we have precedent for using long long under >>> __USE_MISC (strtouq in <stdlib.h>). >>> >>> Patch attached. >> >> What are the opinions with respect to this patch? The ffsl() and >> ffsll() are BSD visible in FreeBSD, DragonFlyBSD, some Mac OS X and >> musl. They are not available in OpenBSD and NetBSD. > > Unless there are objects, I'm going to check this in later this week. I think there were no objections. Which documentation parts need an update? Only the man page in https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man3/ffs.3 ?
On 10/26/2017 10:55 AM, Sebastian Huber wrote: > On 17/10/17 14:01, Florian Weimer wrote: >>>>> >>>>> Would it be possible to change the guard in glibc to __USE_MISC? >>>> >>>> Yes, it should be a simple change. I was worried about the long >>>> long part initially, but we have precedent for using long long under >>>> __USE_MISC (strtouq in <stdlib.h>). >>>> >>>> Patch attached. >>> >>> What are the opinions with respect to this patch? The ffsl() and >>> ffsll() are BSD visible in FreeBSD, DragonFlyBSD, some Mac OS X and >>> musl. They are not available in OpenBSD and NetBSD. >> >> Unless there are objects, I'm going to check this in later this week. > > I think there were no objections. Thanks for the reminder. I have now pushed the change. > Which documentation parts need an update? Only the man page in > > https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man3/ffs.3 > > ? Yes, the GNU manual does not document ffsl/ffsll at all, so no update is needed. Will you contact Michael about the change? Thanks, Florian
On Mon, Oct 30, 2017 at 2:01 PM, Florian Weimer <fweimer@redhat.com> wrote: > On 10/26/2017 10:55 AM, Sebastian Huber wrote: >> >> On 17/10/17 14:01, Florian Weimer wrote: >>>>>> >>>>>> >>>>>> Would it be possible to change the guard in glibc to __USE_MISC? >>>>> >>>>> >>>>> Yes, it should be a simple change. I was worried about the long long >>>>> part initially, but we have precedent for using long long under __USE_MISC >>>>> (strtouq in <stdlib.h>). >>>>> >>>>> Patch attached. >>>> >>>> >>>> What are the opinions with respect to this patch? The ffsl() and ffsll() >>>> are BSD visible in FreeBSD, DragonFlyBSD, some Mac OS X and musl. They are >>>> not available in OpenBSD and NetBSD. >>> >>> >>> Unless there are objects, I'm going to check this in later this week. >> >> >> I think there were no objections. > > > Thanks for the reminder. I have now pushed the change. > >> Which documentation parts need an update? Only the man page in >> >> >> https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/man3/ffs.3 >> >> ? > > > Yes, the GNU manual does not document ffsl/ffsll at all, so no update is > needed. Will you contact Michael about the change? No need (but thanks for thinking of it). I've just now updated the FTM requirements in the man page to say: ffsl(), ffsll(): Since glibc 2.27: _DEFAULT_SOURCE Before glibc 2.27: _GNU_SOURCE Cheers, Michael
Recent BSDs declare these functions, too. 2017-10-05 Florian Weimer <fweimer@redhat.com> * string/strings.h (ffsl, ffsll): Declare under __USE_MISC, not just __USE_GNU. diff --git a/string/strings.h b/string/strings.h index 630b3adc23..27508e31b8 100644 --- a/string/strings.h +++ b/string/strings.h @@ -106,7 +106,7 @@ extern int ffs (int __i) __THROW __attribute_const__; /* The following two functions are non-standard but necessary for non-32 bit platforms. */ -# ifdef __USE_GNU +# ifdef __USE_MISC extern int ffsl (long int __l) __THROW __attribute_const__; __extension__ extern int ffsll (long long int __ll) __THROW __attribute_const__;