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

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR lib/58913; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: lib/58913: ctype(3) macros fail on (unsigned)EOF
Date: Thu, 19 Dec 2024 08:08:38 +0700

     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