Re: ISO C 23 ahead

[Paul Eggert]

On 8/10/22 06:58, Bruno Haible wrote:

> But you haven't pushed the patches yet.

Oops. Pushed.

> And in patch 0004, I think the module 'stdckdint' should depend on 'stdbool'
> (since <stdckdint.h> includes <stdbool.h>).

Thanks, I fixed that.

I also sent the following email to people who I hope can fix the 
problems in the draft C standard (unfortunately they don't seem to make 
it easy to file bug reports...):

------

As one of the maintainers for the GNU Portability Library[1] I recently 
implemented stdckdint.h there[2] and modified some other parts of Gnulib 
to use stdckdint.h[3]. The GNU project has had extensive experience with 
stdckdint.h's behavior, as we implemented nearly-identical macros 
INT_ADD_WRAPV etc. in 2015 and have been using them to catch 
integer-overflow issues since then.

In the process of implementing and using stdckdint.h I found the 
following problems in the draft standard N3047, which I hope can be 
fixed before the standard becomes final:

A. The current wording prohibits this use:

    bool check_2_overflow (unsigned hi, unsigned lo) {
      return ckd_add (&hi, hi, ckd_add (&lo, lo, 1));
    }

because it says arguments to ckd_add cannot be of type 'bool'. There is 
no reason for this restriction in ckd_add's last two arguments, as these 
arguments are promoted to 'int'. This sort of restriction is needed only 
for ckd_add's first argument. Similarly for 'char', enumeration types, 
and bit-precise integers.

B. The current wording says that this usage is not portable:

  bool check_size_overflow (size_t s) {
    return ckd_add (&s, s, 1);
  }

because size_t might be a bit-precise integer, or 'char', or an 
enumeration type. This means that portable programs cannot use 
stdckdint.h when doing address arithmetic with size_t and ptrdiff_t, and 
similarly for other standard types, because these types might 
conceivably be implemented via a bit-precise integer etc.

C. Although freestanding programs are allowed to use the new <stdbit.h> 
header, they are not allowed to use <stdckdint.h>. This is puzzling, as 
the two headers fall roughly into the same category: they typically 
affect only how the compiler generates code and do not require library 
support.


I ignored these problems in Gnulib, in the hopes that they're glitches 
in the standard and that we won't run into any practical implementations 
that exploit the glitches. However, it'd be nicer if they were fixed. 
Here is some proposed wording to do that.

a. In section 4 paragraph 6, add <stdckdint.h> to the list of standard 
headers required of freestanding implementations.

b. In section 7.1.2 insert the following paragraph after paragraph 8: 
"Any declaration of an integer type shall not declare it to be 'bool', 
nor 'char', nor an enumeration type, nor a bit-precise integer type." 
with a footnote "This allows expressions of standard types like 'size_t' 
to be used in calls to macros like 'ckd_add'; see section 7.20."

c. In section 7.20.1 paragraph 3 change this:

"Both 'type2' and 'type3' shall be any integer type other than plain 
'char', 'bool', a bit-precise integer type, or an enumeration type, and 
they need not be the same."

to this:

"Both 'type2' and 'type3' shall be any integer type, and they need not 
be the same."

and append the following footnote to paragraph 3: "Because standard 
types like 'size_t' cannot be plain 'char', 'bool', a bit-precise 
integer type, or an enumeration type (section 7.1.2), *result can be of 
a standard type like 'size_t'."


[1] https://www.gnu.org/software/gnulib/
[2] 
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=2eb92c362ecfb2dae9c9cb37cb9246df6989181c
[3] 
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=ef5a4088d9236a55283d1eb576f560aa39c09e6f