Re: lib/58913: ctype(3) macros fail on (unsigned)EOF

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Wed, 18 Dec 2024 14:04:31 +0000
    From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
    Message-ID:  <20241218140437.7F61D85573%mail.netbsd.org@localhost>

  | I can't find any language allowing the function-like macro to have
  | different evaluation rules from a function, here or in 7.4, except in
  | sequence points.

No, but nor is there any language requiring macros and functions to
execute the same way, or when a failure is to occur, particularly
undefined behaviour, to fail in the same way.

If you look back at section 6.10.4 point 10, the way that macros
are processed is specified, and it all results in token replacement.

[There's no need to actually go look, we all know how the expansion happens,
there's nothing particularly illuminating in the language there.]

There are no default promotion rules for macro arguments, as there
is no actual argument by the time the code is eventually compiled.
Instead, the relevant integer promotion rules will apply in whatever
place the argument is used in the replacement text.

  | If there is an expression E for which the function call (isspace)(E)
  | has different semantics, except for the sequence points, from the
  | macro expansion of isspace(E), that looks like a bug to me.

In cases where undefined behaviour isn't occurring, I'd agree, generally,
though I see no requirement that isspace(E) and (isspace)(E) actually
return the same non-zero result to indicate true - the function might
easily always return 1 (and 0 for the false case of course), whereas
the macro typically returns some semi-random non-zero value (array[c] & MASK)
for some value of MASK.

All of this is really required to retain the original properties of the
<ctype.h> macros, which were all macros long before anyone ever thought
that it would be a good idea to force functions with the same names to
exist.

kre