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