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
Description: PGP signature
