Re: On C99, C11, and other dialects

Alejandro Colomar via Mutt-dev <[email protected]> Tue, 21 Apr 2026 23:35:38 +0200
Newsgroups	gmane.mail.mutt.devel
Message-ID	<aefqanH_-tiRgHxI@devuan>
Hi Steffen,

On 2026-04-21T16:55:51+0200, Steffen Nurpmeso wrote:
[...]
> 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.)

Ahhh, now I see what your problem was.  The problem wasn't
static_assert(3) in C.  The problem was that integer constant
expressions were significantly more strict in C11, and C23 has allowed
compilers to turn some code into constant expressions in certain cases.

I guess this is another good reason to use C23.

[...]
>  | $ 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).

There's signal(3posix) and signal(2).  There's no signal(3) --although
if you run `man 3 signal`, you'll get signal(3posix)--.

Here's the SYNOPSIS from POSIX:

	SYNOPSIS
	     #include <signal.h>

	     void (*signal(int sig, void (*func)(int)))(int);

And here's the one from the Linux man-pages project:

	SYNOPSIS
	     #include <signal.h>

	     typedef typeof(void (int))  *sighandler_t;

	     sighandler_t signal(int signum, sighandler_t handler);

The latter still uses typeof() --even if it also uses typedef-- for
reasons similar to malloc_T().  If we didn't use typeof() in that
typedef definition, it would become quite unreadable.

[...]
> 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.

Since make(1) builds step by step, I don't see a problem in building
until the first error, fix a few things, and then continue the build,
until everything works.  I don't like navigating a sea of warnings.

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

I think it's a combination of

-  They didn't realize it would be so dangerous.
-  Lack of communication.

I'm more concerned about the fact that it hasn't been fixed.  And I'm
even more worried by the fact that the kernel-hardening maintainer is
worried of annoying Torvalds with a fix, so they prefer not fixing it at
all.  That doesn't seem healthy.

> (*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!

Could you please point to those?  I'd be interested in investigating
that.  I don't see reasons why that should be any different.  I'd like
to see a small reproducer piece of code.

>  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!!


Cheers!  :)
Alex

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

-- 
<https://www.alejandro-colomar.es>
signature.asc (application/pgp-signature, 833 B)