Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Word For Today: =?utf-8?Q?=E2=80=9CUglification=E2=80=9D?=
Date: Thu, 14 Mar 2024 19:49:07 -0700
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <86il1op5uk.fsf@linuxsc.com>
References: <uso6or$3t3jn$3@dont-email.me> <20240311202758.193@kylheku.com> <86v85opw22.fsf@linuxsc.com> <87v85o4i1v.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="ebc16c50d4d7433bc8cd997a3211d402";
	logging-data="2194720"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX181xKP+RL6IUv/swoLc3oacJVYV5E78Q5k="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:7PgPLu0FgbTTCQMBadoKP3Y8xHM=
	sha1:BXvFUeWaw4gmr5V4MpnbEiX4dMs=
Bytes: 3820

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.