tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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.

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

* 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.

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

* 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.

Roland


Home | Main Index | Thread Index | Old Index