Hello Alejandro.
Alejandro Colomar via Mutt-dev wrote in
<aeaRQpwhV9OT1HUb@devuan>:
|On 2026-04-20T18:15:01+0200, Steffen Nurpmeso wrote:
|[...]
|>|Hmmm, then yes, that would count as C89. It's quite rare, as these days
|>|almost every program uses POSIX or C99 library stuff, such as
|>|snprintf(3).
|>
|> Libraries seem to have detoriated thus, in that, i think compiling
|> on a twenty year old system will currently really fail, also
|> because of snprintf for example.
|
|The alternative is risking buffer overflows. I think not compiling on
|a twenty year old system is acceptable.
|
|If one is porting new software to such an old system, it would be
|reasonable to first port a modern compiler and libc.
(What i meant was that libraries, at least on Linux where
i develop day-by-day, and where the -std= setting is tested
"randomly", i get no compile error with -std=c89 even though the
codebase of the MUA uses snprintf(). Ie the guard seems missing.
Well actually it does not, but i define _GNU_SOURCE there because
otherwise "hell breaks loose" i guess is the term; i should test
more on FreeBSD it seems.)
|[...]
|>|>|Things I find essential from modern dialects include static_assert(3),
|>|>
|>|> And that was just unusable from ISO C when it came, for example.
|>|> It was a brainfart. They should simply have taken the exact
|>|> variant that C++ had introduced, at first.
...
|>|How was it unusable?
...
|> Sorry but this is all i know. I tried it, and it bailed.
|
|Did you forget to include <assert.h>?
No no, it was broken. It could not evaluate the same expressions
as the C++ variant could. Maybe it was a compiler error, then.
Note the IANA TZ project also did it like so:
* private.h (static_assert): New macro, defined for pre-C23 compilers.
(SIGNED_PADDING_CHECK_NEEDED): New constant.
Try to check that TIME_T_MIN and TIME_T_MAX are actually the min and
max time_t values.
..
+#if __STDC_VERSION__ < 202311
+# define static_assert(cond) extern int static_assert_check[(cond) ? 1 : -1]
+#endif
(I am now not reading exact ISO C definitions to find reasons why
the C11 variant was borked. But it was once i tested.)
|> Ah wait, i meant _Static_assert(), which was ISO C in 2011, and
|> that was completely unusable.
|
|Apart from the name, it's functionally identical to static_assert(3).
|
|_Static_assert(3) is a keyword, and static_assert(3) was a macro in C11,
|provided by <assert.h>. In C23, static_assert(3) became a keyword too.
|
|> They should have used the C++
|> static_assert() right away.
|
|You mean the name? You could include <assert.h> and get the C++ name.
|Here are the relevant contents of the manual page. I'm really surprised
|to hear that you can't use it until C23.
So it was/is. But i cannot reiterate which compiler(s) i used
when i tried it out.
commit b1c9e48b5501cd22a35083137235bad65b9ccd11
AuthorDate: 2019-03-08 13:57:54 +0100
...
ISO C 2011 _Static_assert() is unusable! (Johannes Schöpfer, Jürgen
Daubert)
But assert.h is no good either.
| $ man -w static_assert \
|| MANWIDTH=64 xargs mansectf '(SYNOPSIS|DESCRIPTION|HISTORY)' \
|| cat;
| static_assert(3) Library Functions Manual static_assert(3)
...
|> #define su_MEM_TALLOC(T,NO) su_S(T *,su_MEM_ALLOC_N(sizeof(T), NO))
|
|This looks like an older version of my malloc_T() macro, which was:
:-) Nah, it really looks more like some macro i wrote 25+ years ago.
| #define mallocarray(...) reallocarray(NULL, __VA_ARGS__)
| #define malloc_T(n, T) \
| ( \
| (void)0, \
| (T *){mallocarray(n, sizeof(T))} \
| )
|
|The reason I added typeas() is to support allocating arrays of arrays.
|That is, the above will not work for the following code:
|
| int (*p)[4];
|
| p = malloc_T(42, int[4]);
|
|But with the version that uses typeof(), it works fine. The reason is
|that the macro expands internally T*, which would expand as int[4]*,
|which is a syntax error. But with typeof(), you have typeof(int[4])*,
|which is correct.
I btw still prefer typedef for for example the handler (and
anything prototype-ish) of signal(3) and such. I just seem to be
incapable to perform proper views at this otherwise (like the
prototype shown in "man 3 signal" on Linux).
|[...]
|> I guess the Linux kernel (which seem to have followed you --
|> i bet it was you -- in that malloc typeof() thing),
|
|I suspect they learnt from seeing some of my code, as I had shown my
|work to them before they did it. But they ddeveloped it independently.
|And in fact, they goofed it importantly. So much that their supposedly
|safe macros are in fact massive foot-guns. The original macros they
|wrote were slightly dangerous, and Torvalds patched them with an
|overload that made them the massive foot-guns they are now:
|<https://lore.kernel.org/lkml/abhGS0n_RsUG97Ni@devuan/>.
I see, where you come from.
|[...]
|>|(With older compiler versions, you may need to pass
|>| -Werror=incompatible-pointer-types explicitly. For example, in gcc-11,
|>| I get a warning by default, but it's not a hard error by default.)
|>
|> ..but you do see it as a developer when you compile?
|
|If the project is clean from warnings, you may see it. But I certainly
|prefer enabling it as a hard error, which makes me see it. My makefiles
|often have a lot of compiler flags for enabling as many errors as
|possible.
|
|If it's an error (as it is now), I certainly see it, of course.
|
|> I do not run CI, so errors i actually hate, since i get that
|> fix+build, fix more-build thing, which is total horror.
|
|What alternative exists? If some code is bogus, I prefer a hard error,
|and then fix stuff until it works.
I meant "warnings yes, but no errors". It is sometimes at least
hard enough to see the "xy is reported only once" for some
warnings. I let the compilation go one, and then crawl the (tmux;
or output redirection, or what) history along.
I mean sure, if you have a plethora of builds and only get
a notification email, having hard errors seems the better way.
But i only develop locally, and have some (by far not enough, and
most younger than 2022) VMs.
|>|If you write this malloc_T() in a library once, and then use it
|>|everywhere, you shouldn't worry too much about it having too much
|>|typeof magic.
|>
|> Yes. Kernel, too, and i had just seen the commit that made it
|> simpler to use for the generic "bin". (By sheer chance.)
|
|That commit from Torvalds was horrible.
|That macro is a massive foot-gun.
|<https://lore.kernel.org/lkml/abhGS0n_RsUG97Ni@devuan/>.
I remembered now that i came via
https://lwn.net/Articles/1057769/
to
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc5071d7f7b
and especially
https://lwn.net/Articles/1058664/
pointed to several fixes of that, like
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e19e1b480ac7
In this hindsight it seems hard to understand that making it
"completely cool" aka "fool proof" was not an option.
(*But*, then again, i remember compiler errors with MACRO(x,y,)
syntax, and i even remember being surprised a couple of years ago
that MACRO(x,y, ), ie with space, worked! I would *not* have
dared to use this syntax in any life-expense-ensuring context in
the past. Maybe times have changed. Ie, i remember reporting
a lighttpd error that turned out to be a cgit problem that in turn
was actually a kernel version problem, iirc it was about splice()
and filesystems?, and Donenfeld simply rejected to fix cgit, which
was wrong as Strauss of lighttpd demonstrated using Linux manuals,
because he (Donenfeld) simply waited for the kernel to be fixed!
That you cannot do if you make a living from *that*!)
Ciao and greetings Espana!!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
