Re: Proposal: change requirement for tools from C89 to C99

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Mon, 31 Jan 2022 at 14:53, Roland Illig <roland.illig%gmx.de@localhost> wrote:
>
> Am 31.01.2022 um 11:14 schrieb Robert Elz:
> > I don't follow C standards.   What are the c99 features we'd
> > want to use in tools that don't work in c89?
>
> Here are some things I'd like to change, based on what I found in
> usr.bin/make/var.c and the change list from C99 Foreword paragraph 5:
>
> * Unconditionally use bool, without having to fall back to a custom
> typedef that would change the semantics of the type subtly (C99 6.3.1.2).
>
> * Reduce the scope of local variables by declaring them at the point
> where they are initialized, to remove dangling pointers while stepping
> through the code.
>
> * Move the declaration of i into the corresponding for loops.
>
> * Declare struct members as const if they are not modified after
> initialization, to make reasoning over the code easier.  I currently use
> a conditionally defined macro const_member for that, but it's ugly.
>
> * Use the function modifier 'inline' unconditionally.

Or not bother.  The compiler tends to have its own ideas, especially
when link-time-optimization is enabled.

> * Use the type 'long long' and the corresponding strtoull unconditionally.

size_t + %zu were pointed out earlier; much easier
intmax_t %jd strtoimax() are perhaps less obvious; and given how
standards have been going, more contraversial

> * Use snprintf unconditionally.
>
> * Use compound literals and designated initializers such as
> (PatternFlags){ .matched = false }, to avoid having to define an inline
> function for initializing a single variable.

The idiom:
   my_struct = {0};
is common, but older compilers tks-tsk when it's used.

Also, given:
    struct { char c, long l, } s = {0};
don't assume that the padding between c and l is zero.  This isn't
c99, just compilers taking advantage of the freedom being granted.

> * Use macros with a variable number of arguments, instead of the current
> DEBUG0, DEBUG1, DEBUG2, DEBUG3, DEBUG4, DEBUG5.

There's a got-ya here.  GCC/LLVM have the extension:
   DEBUG(FMT, ....) printf(FMT, ##__VA_ARGS__)
because c99 barfs with DEBUG("hi") (yea, __VA_OPT__(,) is now more
correct, but ## is more likely to work).

> * Use __func__ in low-level messages for debug logging.
>
> * Use va_copy in error handling and string formatting functions.
>
> * Initialize a struct from an initializer-list of non-constant expressions.
>
> While each of the above is a small change, together they make the code
> cleaner by using fewer macros and avoiding some boilerplate.

... and, of course, continue to not use variable length arrays (which
were booted out in c11 anyway).

Oh, and have a bunfight over // comments, and c11's anonymous unions :-)