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

Andrew Cagney <[email protected]>
Newsgroups gmane.os.netbsd.devel.toolchain
Message-ID <CAJeAr6vY+dwLU5Fm06UsGHaPej_uEVnh7cjxGzbOCXOmXStcMw@mail.gmail.com>
On Mon, 31 Jan 2022 at 14:53, Roland Illig <[email protected]> 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 :-)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.