[CC += Jon] Hi Bruno,
On Mon, Dec 15, 2025 at 12:17:30AM +0100, Bruno Haible wrote: > Alejandro Colomar wrote: > > Please don't use [static n] ever. I want to remove it from the > > standard, and I think I'm quite advanced in convincing the right people. > > If you start using it, that could be negative to my efforts. > > > > The right way to specify an array of at least n is [n]. That's what GCC > > implements. That's what we intend to standardize. > > OK, since you say that the ISO C commitee will possibly revise this aspect > of the language, I'll refrain from adding this to Gnulib (for now). > > > > [1] https://lwn.net/Articles/1046840/ > > I think this post did a great disservice to C programmers. > > A journalist is not supposed to consider whether they are doing a service > or disservice, before publishing an article. A journalist is only supposed > to report factually the events and discussions that have taken place, > and I have no indication that LWN's reporting was inaccurate. Yeah, I'm not accusing Jon. But it's propagating incomplete information. It says the kernel disables the GCC diagnostics for [n] due to false positives, but that's not the whole story. It has false positives because they use sanitizers, which have a high tendency of creating false positives. Also, even with the sanitizers on, I poked someone to look at those, and it seems they could probably re-enable them, as it's only one (or very few at most) line of code that they need to tweak to not trigger the false positive. So, the right thing to do would be to re-enable the GCC diagnostics and use [n], and ignore the existence of [static n]. Also, the post doesn't mention that [static n] implies [[gnu::nonnull()]], and more importantly, that it also implies n>0. This is something that definitely should have been noted. Suggesting people that [static n] is good and useful is telling them half the story, which will result in more UB around. Who would think this little program triggers UB? alx@devuan:~/tmp$ cat ub.c #include <stdlib.h> void zero(int n, char a[static n]) { for (int i = 0; i < n; i++) a[i] = 0; } int main(int, char *argv[]) { int n; char *p; n = atoi(argv[1]); p = malloc(n); if (p == NULL) return 1; zero(n, p); } alx@devuan:~/tmp$ gcc -Wall -Wextra ub.c alx@devuan:~/tmp$ ./a.out 0 alx@devuan:~/tmp$ In this simple program, the compiler didn't explote the UB, but you can never rely on that. If you remove 'static', the behavior is well defined, as one would expect. As said, [static n] is Plutionium, and one should be careful to make sure that that is disclaimed when talking about it. For anyone reading, do not ever use that language feature, or nasal demons will follow you. > Thanks for your work on these proposals, by the way: Thank you! :-) > - n3750, alx-0007r6 - add a malloc(3)-based sprintf(3) variant > (similar to gnulib's xasprintf() and xvasprintf() functions), I expect we'll vote this one in March, or maybe July. I think it might be accepted, but I'm not sure. > - n3749, alx-0004r4 - Adopt qualifier conversion rules from C++ > (will help for execv, iconv), I expect this will be voted in three months +/-. It's virtually already accepted, as we voted 23y/0n/6a in the last meeting, but I had to fix a few wording issues, so it needs to go through another vote officially. We'll vote it online asynchronously, as opposed to in a meeting. > - n3611, alx-0018r1 - add streq() We need glibc to collaborate, or this won't be standardized. If glibc and the BSDs get it, we might have a chance. The committee is opposed to this at the moment. On the other hand, the convenor has lowered the bar for adopting stuff, so I might take advantage of that. We'll see. > - n3524, alx-0003r3 - Add directives #def and #enddef > (because I would love to be able to single-step through a macro expansion > in gdb). This one will take some time; I need to research about some preprocessors that have implemented this in the past. Have a lovely night! Alex -- <https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
