Re: Word For Today: “Uglification”

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.