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 :-)