Hello Alejandro.
Alejandro Colomar via Mutt-dev wrote in
<aefqanH_-tiRgHxI@devuan>:
|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\
...
|> +#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.
Or you use C89/C++98 with the simple pseudo typedef that i (and
many other people with similar ones) use for static assertions
for many many years, eg
# define su_CTA(T,M) su__CTA_1(T, su_FILE, __LINE__)
# define su_LCTA(T,M) su__LCTA_1(T, su_FILE, __LINE__)
# define su__CTA_1(T,F,L) su__CTA_2(T, F, L)
# define su__CTA_2(T,F,L) typedef char ASSERTION_failed_file_ ## F ## _line_
## L[(T) ? 1 : -1]
# define su__LCTA_1(T,F,L) su__LCTA_2(T, F, L)
# define su__LCTA_2(T,F,L) \
do{\
typedef char ASSERT_failed_file_ ## F ## _line_ ## L[(T) ? 1 : -1];\
ASSERT_failed_file_ ## F ## _line_ ## L su____i_am_unused__;\
su_UNUSED(su____i_am_unused__);\
}while(0)
Yes i use static_assert() in C23+. But i actually see no
improvement (there is actually none for me, the above "just works"
(tm)), *and* i am in doubt, because ISO C11 was unusable, C17
was unusable, but with C23 it now works. It should never have
entered the standard until it was usable. I am not sitting in
an almost 700 page standard (C-2011) with its "1000" undefined or
incompletely defined or so conditions, nor am i keen for this.
This is in parts where Mr. Ken Thompson picked me up.
...
|>|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:
...
| 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 have a hard time even understanding the above. void(int), that
is a nerd horror show. :-)
|[...]
|> 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.
Make step-by-step? How that? But i can hardly believe a big
project can do it like that, say a Linux kernel build?
|>|>|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/comm\
|> it/?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/comm\
|> it/?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.
Only just like i said. (Ie, some macro with (xy,) and one with
(xy, ).) But no, i cannot, other than that. I think we are, at
least in parts, talking times when there was not even __VA_ARGS__,
widely spread at least; we did not use such preprocessor things
until .. actually i am still very careful with that, my pam_xdg.c
(that is *mine*, not the other one(s)) for example still says
pam_xdg.c: *@ - Requires C preprocessor with __VA_ARGS__ support!
and that is hammer!, you know -- even va_list was not everywhere
at times, at least potentially!
--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)
