Date: Tue, 26 Dec 2017 23:35:41 -0700 From: Warner Losh <imp@bsdimp.com> To: Alan Somers <asomers@freebsd.org> Cc: Eitan Adler <lists@eitanadler.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, gwollman@freebsd.org, Benno Rice <benno@freebsd.org> Subject: Re: Parsing a comment in stdlib.h Message-ID: <CANCZdfoWYdsz9zDisCaitUo4UbtObU=QFRxuf1KxMc17c-yGjw@mail.gmail.com> In-Reply-To: <CAOtMX2g=FK9P0p60bkKeyq-G%2B6zyWcviF4RL84qkkaaD_Z9iRQ@mail.gmail.com> References: <CAF6rxg=BRGTNz8qFCuzFLxH0V5kTa6LpF8wi2JcEmHJxbJA9AQ@mail.gmail.com> <CAOtMX2g=FK9P0p60bkKeyq-G%2B6zyWcviF4RL84qkkaaD_Z9iRQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I find the proposed comment less clear. In fact, I'd go so far as to say its brevity makes it misleadingly wrong. It turns out that __LONG_LONG_SUPPORTED is switchable via compiler flags (in both gcc and clang), hence the need to have these #ifdefs in a standard file. gcc -ansi accepts long long with a warning, but does define __STRICT_ANSI__ so you can create warning free code. All of this happens far away from stdlib.h in sys/cdefs.h: #if (defined(__INTEL_COMPILER) || (defined(__GNUC__) && __GNUC__ >= 2)) && !defined(__STRICT_ANSI__) || __STDC_VERSION__ >= 199901 #define __LONG_LONG_SUPPORTED #endif clang defines __GNUC__ so that __LONG_LONG_SUPPORTED is identical to gcc in the brief testing I just did. One should really read "if the compiler supports 'long long'" as "if the compiler is invoked in a mode that supports long long without generating warnings" It's removal critically changes the meaning here, fatally so I'm afraid. The new text is of absolutely no help because in c89 mode, long long is supported and __LONG_LONG_SUPPORTED is defined. All this nuance is lost, and it's more than mere quibbles. I'd be tempted to leave it along because a full explanation would be quite verbose. Warner On Tue, Dec 26, 2017 at 9:05 PM, Alan Somers <asomers@freebsd.org> wrote: > I would say that your proposed change makes it less clear. For one thing, > it's not clear whether those three bullet points are meant to be ANDed or > ORed. For another, I'm not sure why you removed the part about "long > long". Finally, s/its/it's/. Frankly, I think the comment can just be > shortened to "C99 functions". GCC and Clang both support "long long". Are > there any external compilers that don't? > > On Tue, Dec 26, 2017 at 8:18 PM, Eitan Adler <lists@eitanadler.com> wrote: > > > Hi all, > > > > I'm trying to understand a visibility comment in stdlib.h. Is the > > following change technically correct? > > Can it be made more clear? > > > > Index: include/stdlib.h > > =================================================================== > > --- include/stdlib.h (revision 327228) > > +++ include/stdlib.h (working copy) > > @@ -120,8 +120,10 @@ int wctomb(char *, wchar_t); > > size_t wcstombs(char * __restrict, const wchar_t * __restrict, size_t); > > > > /* > > - * Functions added in C99 which we make conditionally available in the > > - * BSD^C89 namespace if the compiler supports `long long'. > > + * Functions added in C99 which we make available if > > + * - its C99 > > + * - BSD visible and not C89 > > + * - its C++ > > * The #if test is more complicated than it ought to be because > > * __BSD_VISIBLE implies __ISO_C_VISIBLE == 1999 *even if* `long long' > > * is not supported in the compilation environment (which therefore > means > > > > > > -- > > Eitan Adler > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@ > freebsd.org" > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfoWYdsz9zDisCaitUo4UbtObU=QFRxuf1KxMc17c-yGjw>