Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:
>
>> Third party libraries are allowed to use any mechanism they like to
>> minimize name conflicts other than prefixing with two underscores.
>
>But there is no other such mechanism available.

Of course there is. The most simple is to prefix
any external symbols with a library specific
prefix.

Or to suffix any symbol with two underscore characters
and a library-specific string.

Or obfuscate the extern symbols in the library and use #define
macros to map a readable name to the obfuscated symbol
in the corresponding header file(s).

As has been pointed out, extending the double-leading
underscore mechanism outside the implementation requires
some central authority to manage names across all
third-party libraries. (which is generally true for any prefix
mechanism, whether it is __ or fubar_).

We seem to have survived just fine without any such
disambiguation mechanism to date.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:
>>> Third party libraries are allowed to use any mechanism they like to
>>> minimize name conflicts other than prefixing with two underscores.
>>
>> But there is no other such mechanism available.
>
> Are you aware that working third party libraries exist, and name
> collisions are fairly rare? How do you think that's possible?
>
> There are no 100% reliable mechanisms. There are mechanisms that work
> well enough in practice, including using library-specific prefixes.

The collisions I recall running into are library headers defining things
like MIN, MAX, TRUE, FALSE - useful in isolation, but a nuisance when
more than one library does it.

Actually the offending headers that spring are mind are supplied by the
implementor of the platform they support, albeit that the headers
involved are not ones specified in standard C.

--
https://www.greenend.org.uk/rjk/

On 2024-03-13, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Wed, 13 Mar 2024 22:33:02 GMT, Scott Lurndal wrote:
>>> Third party libraries are allowed to use any mechanism they like to
>>> minimize name conflicts other than prefixing with two underscores.
>>
>> But there is no other such mechanism available.
>
> Are you aware that working third party libraries exist, and name
> collisions are fairly rare? How do you think that's possible?

It's possible because firstly, even if there are collisions latent
in the library mixture, not all libraries are used together in one
application. E.g. in an OS distro installation there might be a thousand
libraries, but no application uses all thousand.

Secondly, even if two libraries are used in the same application, where
those libraries have a header-file-level clash, the clash only occurs if
their headers are included in the same translation unit in that program.

Thirdly, mere linkage of two libraries into the same program can only
cause a clash if it involves an external name.

Fourth, even if two libraries have a clashing external name, I think
that under certain dynamic linking paradigms, this is only a problem if
that name is used. If the same name refers to multiple entities, there
is an ambiguity, but if the program doesn't use that name, then the
ambiguity doesn't matter.

Fifth, if we are talking specifically about names used by macros for
naming local symbols inserted into the program, libraries not in the C
implementation in fact can get away with using the __ space. If these
identifiers don't land on a compiler keyword, there is no actual
problem. Now a third party library could choose such a name inside its
macro such that the C library has also used the same name inside its
macro. But for that to cause a clash, the macros have to be nested
together.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 3/13/24 17:52, Lawrence D'Oliveiro wrote:
> On Wed, 13 Mar 2024 03:36:11 -0400, James Kuyper wrote:
>
>> Yes, I do, and so do implementors. Avoiding those clashes is their
>> responsibility.
>
> Implementors of the C standard? What about providers of other libraries?

Avoiding conflicts is their responsibility, obviously. As a general
rule, they do so by choosing a library-specific prefix to use on all
identifiers that might otherwise cause problems.

Kaz Kylheku <433-929-6894@kylheku.com> writes:

[some editing of white space done]

> On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> From /usr/include/<<arch>>/bits/select.h on my Debian system:
>>
>> #define __FD_ZERO(s) \
>> do { \
>> unsigned int __i; \
>> fd_set *__arr = (s); \
>
> This assignment has value; it checks that, loosely speaking,
> s is an "assignment compatible" pointer with a fd_set *,
> so that there is a diagnostic if the macro is applied to
> an object of the wrong type.

More to the point, if the macro is applied to a value of the wrong
type.

>> for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
>> __FDS_BITS (__arr)[__i] = 0; \
>
> Here, I would have done memset(__arr, 0, sizeof *__arr).

That assumes that it is the entire fd_set that needs to be zeroed,
which may not be right. Note the call to the __FDS_BITS() macro.

Better:

#define __FD_ZERO(s) ( \
(void) memset( \
__FDS_BITS( (fd_set*){(s)} ), 0, sizeof __FDS_BITS( (fd_set*){0} ) \
) \
)

This definition: avoids introducing any new identifiers; checks
that the argument s yields an assignment compatible pointer; and
provides a macro that can be used as a void expression (unlike the
original macro definition, which can be used only as a statement).

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>
> [some editing of white space done]
>
>> On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>
>>> From /usr/include/<<arch>>/bits/select.h on my Debian system:
>>>
>>> #define __FD_ZERO(s) \
>>> do { \
>>> unsigned int __i; \
>>> fd_set *__arr = (s); \
>>
>> This assignment has value; it checks that, loosely speaking,
>> s is an "assignment compatible" pointer with a fd_set *,
>> so that there is a diagnostic if the macro is applied to
>> an object of the wrong type.
>
> More to the point, if the macro is applied to a value of the wrong
> type.
>
>>> for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
>>> __FDS_BITS (__arr)[__i] = 0; \
>>
>> Here, I would have done memset(__arr, 0, sizeof *__arr).
>
> That assumes that it is the entire fd_set that needs to be zeroed,
> which may not be right. Note the call to the __FDS_BITS() macro.
>
> Better:
>
> #define __FD_ZERO(s) ( \
> (void) memset( \
> __FDS_BITS( (fd_set*){(s)} ), 0, sizeof __FDS_BITS( (fd_set*){0} ) \
> ) \
> )
>
> This definition: avoids introducing any new identifiers; checks
> that the argument s yields an assignment compatible pointer; and
> provides a macro that can be used as a void expression (unlike the
> original macro definition, which can be used only as a statement).

For context, here's the entire file from my system (Ubuntu 24.0.4,
package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
author(s) decided not to use memset to avoid the required #include,
which might increase compilation times for code that indirectly includes
this header. (I offer no opinion on whether that's a good tradeoff.)

Note that __FD_ZERO is very clearly *not* intended to be invoked by
arbitrary code.

```
/* Copyright (C) 1997-2022 Free Software Foundation, Inc.
This file is part of the GNU C Library.

The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.

The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<https://www.gnu.org/licenses/>. */

#ifndef _SYS_SELECT_H
# error "Never use <bits/select.h> directly; include <sys/select.h> instead."
#endif

/* We don't use `memset' because this would require a prototype and
the array isn't too big. */
#define __FD_ZERO(s) \
do { \
unsigned int __i; \
fd_set *__arr = (s); \
for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
__FDS_BITS (__arr)[__i] = 0; \
} while (0)
#define __FD_SET(d, s) \
((void) (__FDS_BITS (s)[__FD_ELT(d)] |= __FD_MASK(d)))
#define __FD_CLR(d, s) \
((void) (__FDS_BITS (s)[__FD_ELT(d)] &= ~__FD_MASK(d)))
#define __FD_ISSET(d, s) \
((__FDS_BITS (s)[__FD_ELT (d)] & __FD_MASK (d)) != 0)

```

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>> [some editing of white space done]
>>
>>> On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> From /usr/include/<<arch>>/bits/select.h on my Debian system:
>>>>
>>>> #define __FD_ZERO(s) \
>>>> do { \
>>>> unsigned int __i; \
>>>> fd_set *__arr = (s); \
>>>
>>> This assignment has value; it checks that, loosely speaking,
>>> s is an "assignment compatible" pointer with a fd_set *,
>>> so that there is a diagnostic if the macro is applied to
>>> an object of the wrong type.
>>
>> More to the point, if the macro is applied to a value of the wrong
>> type.
>>
>>>> for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
>>>> __FDS_BITS (__arr)[__i] = 0; \
>>>
>>> Here, I would have done memset(__arr, 0, sizeof *__arr).
>>
>> That assumes that it is the entire fd_set that needs to be zeroed,
>> which may not be right. Note the call to the __FDS_BITS() macro.
>>
>> Better:
>>
>> #define __FD_ZERO(s) ( \
>> (void) memset( \
>> __FDS_BITS( (fd_set*){(s)} ), 0, sizeof __FDS_BITS( (fd_set*){0} ) \
>> ) \
>> )
>>
>> This definition: avoids introducing any new identifiers; checks
>> that the argument s yields an assignment compatible pointer; and
>> provides a macro that can be used as a void expression (unlike the
>> original macro definition, which can be used only as a statement).
>
>For context, here's the entire file from my system (Ubuntu 24.0.4,
>package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
>author(s) decided not to use memset to avoid the required #include,
>which might increase compilation times for code that indirectly includes
>this header. (I offer no opinion on whether that's a good tradeoff.)
>
>Note that __FD_ZERO is very clearly *not* intended to be invoked by
>arbitrary code.
>
>```
>/* Copyright (C) 1997-2022 Free Software Foundation, Inc.
> This file is part of the GNU C Library.
>
> The GNU C Library is free software; you can redistribute it and/or
> modify it under the terms of the GNU Lesser General Public
> License as published by the Free Software Foundation; either
> version 2.1 of the License, or (at your option) any later version.
>
> The GNU C Library is distributed in the hope that it will be useful,
> but WITHOUT ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> Lesser General Public License for more details.
>
> You should have received a copy of the GNU Lesser General Public
> License along with the GNU C Library; if not, see
> <https://www.gnu.org/licenses/>. */
>
>#ifndef _SYS_SELECT_H
># error "Never use <bits/select.h> directly; include <sys/select.h> instead."
>#endif
>
>
>/* We don't use `memset' because this would require a prototype and
> the array isn't too big. */
>#define __FD_ZERO(s) \
> do { \
> unsigned int __i; \
> fd_set *__arr = (s); \
> for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
> __FDS_BITS (__arr)[__i] = 0; \
> } while (0)
>#define __FD_SET(d, s) \
> ((void) (__FDS_BITS (s)[__FD_ELT(d)] |= __FD_MASK(d)))
>#define __FD_CLR(d, s) \
> ((void) (__FDS_BITS (s)[__FD_ELT(d)] &= ~__FD_MASK(d)))
>#define __FD_ISSET(d, s) \
> ((__FDS_BITS (s)[__FD_ELT (d)] & __FD_MASK (d)) != 0)
>
>```
>

That code is only selected if it is not compiled with
gcc. If it is gcc 2 or later, the header file uses

# define __FD_ZERO(fdsp) \
do { \
int __d0, __d1; \
__asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS \
: "=c" (__d0), "=D" (__d1) \
: "a" (0), "0" (sizeof (fd_set) \
/ sizeof (__fd_mask)), \
"1" (&__FDS_BITS (fdsp)[0]) \
: "memory"); \
} while (0)

scott@slp53.sl.home (Scott Lurndal) writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>>
>>> [some editing of white space done]
>>>
>>>> On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>
>>>>> From /usr/include/<<arch>>/bits/select.h on my Debian system:
>>>>>
>>>>> #define __FD_ZERO(s) \
>>>>> do { \
>>>>> unsigned int __i; \
>>>>> fd_set *__arr = (s); \
>>>>
>>>> This assignment has value; it checks that, loosely speaking,
>>>> s is an "assignment compatible" pointer with a fd_set *,
>>>> so that there is a diagnostic if the macro is applied to
>>>> an object of the wrong type.
>>>
>>> More to the point, if the macro is applied to a value of the wrong
>>> type.
>>>
>>>>> for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
>>>>> __FDS_BITS (__arr)[__i] = 0; \
>>>>
>>>> Here, I would have done memset(__arr, 0, sizeof *__arr).
>>>
>>> That assumes that it is the entire fd_set that needs to be zeroed,
>>> which may not be right. Note the call to the __FDS_BITS() macro.
>>>
>>> Better:
>>>
>>> #define __FD_ZERO(s) ( \
>>> (void) memset( \
>>> __FDS_BITS( (fd_set*){(s)} ), 0, sizeof __FDS_BITS( (fd_set*){0} ) \
>>> ) \
>>> )
>>>
>>> This definition: avoids introducing any new identifiers; checks
>>> that the argument s yields an assignment compatible pointer; and
>>> provides a macro that can be used as a void expression (unlike the
>>> original macro definition, which can be used only as a statement).
>>
>>For context, here's the entire file from my system (Ubuntu 24.0.4,
>>package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
>>author(s) decided not to use memset to avoid the required #include,
>>which might increase compilation times for code that indirectly includes
>>this header. (I offer no opinion on whether that's a good tradeoff.)
>>
>>Note that __FD_ZERO is very clearly *not* intended to be invoked by
>>arbitrary code.
>>
>>```
>>/* Copyright (C) 1997-2022 Free Software Foundation, Inc.
>> This file is part of the GNU C Library.
>>
>> The GNU C Library is free software; you can redistribute it and/or
>> modify it under the terms of the GNU Lesser General Public
>> License as published by the Free Software Foundation; either
>> version 2.1 of the License, or (at your option) any later version.
>>
>> The GNU C Library is distributed in the hope that it will be useful,
>> but WITHOUT ANY WARRANTY; without even the implied warranty of
>> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> Lesser General Public License for more details.
>>
>> You should have received a copy of the GNU Lesser General Public
>> License along with the GNU C Library; if not, see
>> <https://www.gnu.org/licenses/>. */
>>
>>#ifndef _SYS_SELECT_H
>># error "Never use <bits/select.h> directly; include <sys/select.h> instead."
>>#endif
>>
>>
>>/* We don't use `memset' because this would require a prototype and
>> the array isn't too big. */
>>#define __FD_ZERO(s) \
>> do { \
>> unsigned int __i; \
>> fd_set *__arr = (s); \
>> for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
>> __FDS_BITS (__arr)[__i] = 0; \
>> } while (0)
>>#define __FD_SET(d, s) \
>> ((void) (__FDS_BITS (s)[__FD_ELT(d)] |= __FD_MASK(d)))
>>#define __FD_CLR(d, s) \
>> ((void) (__FDS_BITS (s)[__FD_ELT(d)] &= ~__FD_MASK(d)))
>>#define __FD_ISSET(d, s) \
>> ((__FDS_BITS (s)[__FD_ELT (d)] & __FD_MASK (d)) != 0)
>>
>>```
>>
>
>That code is only selected if it is not compiled with
>gcc. If it is gcc 2 or later, the header file uses
>
># define __FD_ZERO(fdsp) \
> do { \
> int __d0, __d1; \
> __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS \
> : "=c" (__d0), "=D" (__d1) \
> : "a" (0), "0" (sizeof (fd_set) \
> / sizeof (__fd_mask)), \
> "1" (&__FDS_BITS (fdsp)[0]) \
> : "memory"); \
> } while (0)
>

(Fedora Core 20).

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>For context, here's the entire file from my system (Ubuntu 24.0.4,
>>package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
>>author(s) decided not to use memset to avoid the required #include,
>>which might increase compilation times for code that indirectly includes
>>this header. (I offer no opinion on whether that's a good tradeoff.)
>>
>>Note that __FD_ZERO is very clearly *not* intended to be invoked by
>>arbitrary code.
>>
>>```
[code snipped]
>>```
>>
>
> That code is only selected if it is not compiled with
> gcc. If it is gcc 2 or later, the header file uses
>
> # define __FD_ZERO(fdsp) \
> do { \
> int __d0, __d1; \
> __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS \
> : "=c" (__d0), "=D" (__d1) \
> : "a" (0), "0" (sizeof (fd_set) \
> / sizeof (__fd_mask)), \
> "1" (&__FDS_BITS (fdsp)[0]) \
> : "memory"); \
> } while (0)

Oh? I don't see that code anywhere in the current glibc sources, in any
older version of bits/select.h, or anywhere under /usr/include on my
system.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> For context, here's the entire file from my system (Ubuntu 24.0.4,
> package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
> author(s) decided not to use memset to avoid the required #include,
> which might increase compilation times for code that indirectly includes
> this header. (I offer no opinion on whether that's a good tradeoff.)
[...]

An older version did use memset(). It was changed to use a loop in
1997, with a commit message that included:
"Don't use memset to prevent prototype trouble, use simple loop."
It may have been to avoid problems with pre-ANSI C compilers that didn't
support prototypes. That's still speculation on my part.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>For context, here's the entire file from my system (Ubuntu 24.0.4,
>>>package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
>>>author(s) decided not to use memset to avoid the required #include,
>>>which might increase compilation times for code that indirectly includes
>>>this header. (I offer no opinion on whether that's a good tradeoff.)
>>>
>>>Note that __FD_ZERO is very clearly *not* intended to be invoked by
>>>arbitrary code.
>>>
>>>```
>[code snipped]
>>>```
>>>
>>
>> That code is only selected if it is not compiled with
>> gcc. If it is gcc 2 or later, the header file uses
>>
>> # define __FD_ZERO(fdsp) \
>> do { \
>> int __d0, __d1; \
>> __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS \
>> : "=c" (__d0), "=D" (__d1) \
>> : "a" (0), "0" (sizeof (fd_set) \
>> / sizeof (__fd_mask)), \
>> "1" (&__FDS_BITS (fdsp)[0]) \
>> : "memory"); \
>> } while (0)
>
>Oh? I don't see that code anywhere in the current glibc sources, in any
>older version of bits/select.h, or anywhere under /usr/include on my
>system.

I'm using Fedora Core 20. Should have noted that directly in the reply,
sorry about that. It had surprised me when I looked at the generated
code, thinking that perhaps the optimizer generated the rep stos
when optimizing the loop.

$ rpm -q -f /usr/include/bits/select.h
glibc-headers-2.18-19.fc20.x86_64
$ gcc --version
gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)

Yes, I should probably update to a newer Fedora release, but this
has been rock solid for almost a decade (until last week when
an automatic firefox update started requiring wayland libraries).

We do use gcc11+ and recent Ubuntu/Fedora/Redhat release at the office.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>[...]
>> For context, here's the entire file from my system (Ubuntu 24.0.4,
>> package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
>> author(s) decided not to use memset to avoid the required #include,
>> which might increase compilation times for code that indirectly includes
>> this header. (I offer no opinion on whether that's a good tradeoff.)
>[...]
>
>An older version did use memset(). It was changed to use a loop in
>1997, with a commit message that included:
> "Don't use memset to prevent prototype trouble, use simple loop."
>It may have been to avoid problems with pre-ANSI C compilers that didn't
>support prototypes. That's still speculation on my part.

Here's the full fc20 version:
$ rpm -q -f /usr/include/bits/select.h
glibc-headers-2.18-19.fc20.x86_64

/* Copyright (C) 1997-2013 Free Software Foundation, Inc.
This file is part of the GNU C Library.

The GNU C Library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.

The GNU C Library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public
License along with the GNU C Library; if not, see
<http://www.gnu.org/licenses/>. */

#ifndef _SYS_SELECT_H
# error "Never use <bits/select.h> directly; include <sys/select.h> instead."
#endif

#include <bits/wordsize.h>

#if defined __GNUC__ && __GNUC__ >= 2

# if __WORDSIZE == 64
# define __FD_ZERO_STOS "stosq"
# else
# define __FD_ZERO_STOS "stosl"
# endif

# define __FD_ZERO(fdsp) \
do { \
int __d0, __d1; \
__asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS \
: "=c" (__d0), "=D" (__d1) \
: "a" (0), "0" (sizeof (fd_set) \
/ sizeof (__fd_mask)), \
"1" (&__FDS_BITS (fdsp)[0]) \
: "memory"); \
} while (0)

#else /* ! GNU CC */

/* We don't use `memset' because this would require a prototype and
the array isn't too big. */
# define __FD_ZERO(set) \
do { \
unsigned int __i; \
fd_set *__arr = (set); \
for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
__FDS_BITS (__arr)[__i] = 0; \
} while (0)

#endif /* GNU CC */

#define __FD_SET(d, set) \
((void) (__FDS_BITS (set)[__FD_ELT (d)] |= __FD_MASK (d)))
#define __FD_CLR(d, set) \
((void) (__FDS_BITS (set)[__FD_ELT (d)] &= ~__FD_MASK (d)))
#define __FD_ISSET(d, set) \
((__FDS_BITS (set)[__FD_ELT (d)] & __FD_MASK (d)) != 0)

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>[...]
>>> For context, here's the entire file from my system (Ubuntu 24.0.4,
>>> package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
>>> author(s) decided not to use memset to avoid the required #include,
>>> which might increase compilation times for code that indirectly includes
>>> this header. (I offer no opinion on whether that's a good tradeoff.)
>>[...]
>>
>>An older version did use memset(). It was changed to use a loop in
>>1997, with a commit message that included:
>> "Don't use memset to prevent prototype trouble, use simple loop."
>>It may have been to avoid problems with pre-ANSI C compilers that didn't
>>support prototypes. That's still speculation on my part.
>
> Here's the full fc20 version:
> $ rpm -q -f /usr/include/bits/select.h
> glibc-headers-2.18-19.fc20.x86_64
>
>
[...]
> #if defined __GNUC__ && __GNUC__ >= 2
[...]
> #else /* ! GNU CC */
[...]
> #endif /* GNU CC */
[...]

I don't see that in the GNU glibc git repo, even on branches with
"fedora" in their names. Perhaps it's a change applied by Red Hat and
not propagated upstream. (Though I'm not sure why Red Hat would need to
allow for glibc not being compiled by gcc.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>> [some editing of white space done]
>>
>>> On 2024-03-12, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>
>>>> From /usr/include/<<arch>>/bits/select.h on my Debian system:
>>>>
>>>> #define __FD_ZERO(s) \
>>>> do { \
>>>> unsigned int __i; \
>>>> fd_set *__arr = (s); \
>>>
>>> This assignment has value; it checks that, loosely speaking,
>>> s is an "assignment compatible" pointer with a fd_set *,
>>> so that there is a diagnostic if the macro is applied to
>>> an object of the wrong type.
>>
>> More to the point, if the macro is applied to a value of the wrong
>> type.
>>
>>>> for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i) \
>>>> __FDS_BITS (__arr)[__i] = 0; \
>>>
>>> Here, I would have done memset(__arr, 0, sizeof *__arr).
>>
>> That assumes that it is the entire fd_set that needs to be zeroed,
>> which may not be right. Note the call to the __FDS_BITS() macro.
>>
>> Better:
>>
>> #define __FD_ZERO(s) ( \
>> (void) memset( \
>> __FDS_BITS( (fd_set*){(s)} ), 0, sizeof __FDS_BITS( (fd_set*){0} ) \
>> ) \
>> )
>>
>> This definition: avoids introducing any new identifiers; checks
>> that the argument s yields an assignment compatible pointer; and
>> provides a macro that can be used as a void expression (unlike the
>> original macro definition, which can be used only as a statement).
>
> For context, here's the entire file from my system (Ubuntu 24.0.4,
> package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
> author(s) decided not to use memset to avoid the required #include,
> which might increase compilation times for code that indirectly includes
> this header. [...]

Yes, it seems clear from the (snipped) source that the authors
deliberately avoided using memset(), perhaps so as not to have
an unwanted dependency.

My comments were meant in the sense of comparing one revision to
another, and about macro definitions generally. They were not
meant to say anything specific about the context in which the
original macro was defined, both because it is not one I have
easy access to and because it doesn't affect the general nature
of my comments.

On 2024-03-15, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>[...]
>>>> For context, here's the entire file from my system (Ubuntu 24.0.4,
>>>> package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
>>>> author(s) decided not to use memset to avoid the required #include,
>>>> which might increase compilation times for code that indirectly includes
>>>> this header. (I offer no opinion on whether that's a good tradeoff.)
>>>[...]
>>>
>>>An older version did use memset(). It was changed to use a loop in
>>>1997, with a commit message that included:
>>> "Don't use memset to prevent prototype trouble, use simple loop."
>>>It may have been to avoid problems with pre-ANSI C compilers that didn't
>>>support prototypes. That's still speculation on my part.
>>
>> Here's the full fc20 version:
>> $ rpm -q -f /usr/include/bits/select.h
>> glibc-headers-2.18-19.fc20.x86_64
>>
>>
> [...]
>> #if defined __GNUC__ && __GNUC__ >= 2

Whoever wrote this didn't know that if __GNUC__ doesn't exist, it will
expand as 0, which is false, so this is equivalent to just

#if __GNUC__ >= 2

> [...]
>> #else /* ! GNU CC */
> [...]
>> #endif /* GNU CC */
> [...]
>
> I don't see that in the GNU glibc git repo, even on branches with
> "fedora" in their names. Perhaps it's a change applied by Red Hat and
> not propagated upstream. (Though I'm not sure why Red Hat would need to
> allow for glibc not being compiled by gcc.)

That it's checking for GNU C at least 2 suggests it is an old
patch.

If you look at the source directory for Fedora's package, you see
there are a bunch of patches that get applied:

https://src.fedoraproject.org/rpms/glibc/tree/rawhide

Now if we go to "f20", a heck of lot more patches were applied:

https://src.fedoraproject.org/rpms/glibc/tree/f20

Now, don't waste your time; it's not in any of those patches (I looked).

f20 references glibc-2.18.tar.gz, and that's where that code is found,
in this file:

./glibc-2.18/sysdeps/x86/bits/select.h

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <433-929-6894@kylheku.com> writes:
[...]
>>> #if defined __GNUC__ && __GNUC__ >= 2
>
> Whoever wrote this didn't know that if __GNUC__ doesn't exist, it will
> expand as 0, which is false, so this is equivalent to just
>
> #if __GNUC__ >= 2

Or they did know that and decided that the longer version would be clearer.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 15/03/2024 01:11, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> For context, here's the entire file from my system (Ubuntu 24.0.4,
>>> package libc6-dev:amd64 2.35-0ubuntu3.6). I get the impression that the
>>> author(s) decided not to use memset to avoid the required #include,
>>> which might increase compilation times for code that indirectly includes
>>> this header. (I offer no opinion on whether that's a good tradeoff.)
>>>
>>> Note that __FD_ZERO is very clearly *not* intended to be invoked by
>>> arbitrary code.
>>>
>>> ```
> [code snipped]
>>> ```
>>>
>>
>> That code is only selected if it is not compiled with
>> gcc. If it is gcc 2 or later, the header file uses
>>
>> # define __FD_ZERO(fdsp) \
>> do { \
>> int __d0, __d1; \
>> __asm__ __volatile__ ("cld; rep; " __FD_ZERO_STOS \
>> : "=c" (__d0), "=D" (__d1) \
>> : "a" (0), "0" (sizeof (fd_set) \
>> / sizeof (__fd_mask)), \
>> "1" (&__FDS_BITS (fdsp)[0]) \
>> : "memory"); \
>> } while (0)
>
> Oh? I don't see that code anywhere in the current glibc sources, in any
> older version of bits/select.h, or anywhere under /usr/include on my
> system.
>

I see it in my older Mint system (based on Ubuntu bionic 18.04 LTS), but
not my newer one (based on Ubuntu jammy 22.04 LTS). So it looks like
was an optimisation that was useful in the past, but newer gcc gives the
same or better code from the pure C code. Keeping it in C rather than
inline assembly gives the compiler more information, even if the
generated object code is still the same, so that's always a good thing.

(And full memory clobbers are undesirable in performance code because it
can mean the compiler loses useful knowledge or has to re-load other
data from memory.)

On 15/03/2024 04:44, Keith Thompson wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
> [...]
>>>> #if defined __GNUC__ && __GNUC__ >= 2
>>
>> Whoever wrote this didn't know that if __GNUC__ doesn't exist, it will
>> expand as 0, which is false, so this is equivalent to just
>>
>> #if __GNUC__ >= 2
>
> Or they did know that and decided that the longer version would be clearer.
>

Or they did know, and decided they did not want a spurious warning when
compiling with "-Wundef" that generates a warning before replacing
undefined identifiers with 0 in #if directives. Personally, I always
use -Wundef in my own code, because I think the "default to 0" treatment
makes it far too easy for typos to go unnoticed. I have no idea if the
glibc folk agree with that and like to use -Wundef themselves, or if
they just like to make their code as "warning-proof" as possible.