Hi Steffen, On 2026-04-18T00:18:38+0200, Steffen Nurpmeso wrote: > Matthias Andree via Mutt-dev wrote in > <[email protected]>: > |Am 17.04.26 um 05:26 schrieb Kevin J. McCarthy: > |> On Fri, Apr 17, 2026 at 02:31:19AM +0200, Alejandro Colomar via > |> Mutt-dev wrote: > |>> Yup, I meant how it can be done, not really an explanation of how the > |>> magic works. I guess I should have explained it, as it's really not > |>> obvious. > |> > |> I know that explanation was for Steffen, but thank you. I read your > |> code and explanation and links for a long while, before it started to > |> sink in. > |> > |> Steffen is right, it's really cool, but without your explanation I > |> never would have understood! > | > |The skills required to write library code and skills required to write > |application code differ by a large stretch. ;-) > > Well i mean .. i am just a Boche. (But with a refrigerator > not from Bosch, and unfortunately also not from Foron, but that > aside.) > > I live in ISO C89 (or C99), and before, and overall mostly even in
C89 is too difficult to write correctly. I bet you're mostly living in C99, maybe avoiding a few features of it sometimes. Also, I suspect you're only really dealing with POSIX (and maybe some other relatively civilized) systems. Portable ISO C is really painful (one's complement allowed until C23, etc.). You probably also take advantage of a few common extensions. -pedantic C89 is really a PITA. BTW, the C Committee that standardized C89 was just as inventive and bad as more recent ones. They broke malloc(3) et al. by permitting implementations to return NULL on success, which was a terrible mistake that we're dealing with now. I don't have much sympathy for C89 compared to K&R C or C99, TBH. <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3752.txt> > C++ '98, and my skills therein are so: i am alive and well. (Even > if Coverity now gives me some minor defect numbers instead of the > 0.00 that i had once i actually uploaded a build last, and without > giving me the defects that cause them.) This includes compiling > C with C++, just like with your project(s), as i see it; for me, > at least those i wrote from scratch. > > No, skills is such a thing. I am totally fine with brilliant > young men sailing the edge of the stormy waves, they are > experts, are they. The problem likely are those nitpickers > on expenses in the standard comittees, and the entire society [...] > So i am not actually interested in being skilled in almost > anything after ISO C99/C++98, how unprofessional that may be. > But i tell you one thing. I *loved* the wonderful and more than > only respected Ken Thompson talking in the "Oral History" of the > Computer Museum series, and regarding this thread in particular > this short five minute snippet that is well worth watching or > hearing: > > alias ytls-='yt-dlp --js-runtimes quickjs --list-formats' > alias ytdlf-='yt-dlp --js-runtimes quickjs -f' > ... > 91 mp4 256x144 30 │ ~ 4.64MiB 124k m3u8 │ avc1.4D400C > mp4a.40.5 [en] > ... > $ ytdlf- 91 'https://www.youtube.com/watch?v=NTrAISNdf70' I never liked the Go language, FWIW. I very much stay with C and the shell. That's as much as I need for anything. > In my opinion the best C would be the one from Plan9. I have mixed opinions about Plan9 C. The lack of 'const' is really bad. And there are some extensions that are dangerous. But they have other extensions that are useful, and which I want to standardize in C2y. And the string library has some really good designs but riddled with bugs: strecpy(2) and seprint(2). > I do not > need more, but what i need, that we do not have from ISO. I'm working on several things that might be quite interesting. There's the _Countof() operator which I added recently. Now I want to extend it to array parameters. int func(int n, int a[n]) { return _Countof(a); // equivalent to 'return n;' } And there are a few other interesting features that will come in future language revisions. But I agree there's a lot of unnecessary stuff in recent standards. Things I find essential from modern dialects include static_assert(3), _Generic(3), and a few others. They allow writing const-preserving string APIs, for example, as we've seen in this thread. That's an important improvement over C99. You may also be interested in the magic from this macro: #define typeas(T) typeof((T){0}) #define mallocarray(...) reallocarray(NULL, __VA_ARGS__) #define malloc_T(n, T) malloc_T_(n, typeas(T)) #define malloc_T_(n, T) ( \ (void)0, \ (T *){mallocarray(n, sizeof(T))} \ ) which is used as: int *p; p = malloc_T(42, int); if (p == NULL) goto fail; This vastly improves the safety of malloc(3) calls compared to anything you can do with the raw function. I'll paste here some links to commits that added those macros in the shadow project, which explain some of the reasons for them: - <https://github.com/shadow-maint/shadow/commit/97d3c09a3d357bf4ade04b24afeb8d2e5ec6bf73> - <https://github.com/shadow-maint/shadow/commit/6e58c1275252f3314d1aa5cc4d7e7f9068e3a902> - <https://github.com/shadow-maint/shadow/commit/09775d3718df216c75b62d73bbcc5aa060e0fc94> - <https://github.com/shadow-maint/shadow/commit/0afe2169537de5459f5129d2f7af68f675c6b27a> - <https://github.com/shadow-maint/shadow/commit/9705effba5a0af3d87848bee0a434ff4c2520aef> To be fair, the malloc_T() macro from above only needs C99 compound literals, plus typeof. However, there's realloc_T(), which comes with even more magic, and needs C11. #define reallocarray_(p, n, z) reallocarray(p, (n)?:1, (z)?:1) #define realloc_T(p, n, T) realloc_T_(p, n, typeas(T)) #define realloc_T_(p, n, T) \ ( \ _Generic(p, T *: (void)0), \ (T *){reallocarray_(p, n, sizeof(T))} \ ) This guarantees that the type of the input pointer is the same as the type used for the allocation and is also the same type as the type used for the assignment of the return value. This prevents an entire class of stupid mistakes, and makes realloc_T() quite fool-proof. - <https://github.com/shadow-maint/shadow/commit/afc4b574b7372e72cffb695214bc08e1a6a86a75> - <https://github.com/shadow-maint/shadow/commit/26c9dd37157353092e8709255a6a601915057c05> > (In C++ > maybe, but then i never liked most aspects of this, there.) > > http://www.rundkuehlschrank.de/ > > https://www.mdr.de/geschichte/ddr/wirtschaft/ddr-elektrogeraete-funktionieren-laenger-langlebig-garantie-gesetzliche-zuverlaessigkeit-100.html > > Btw i already saw Alejandro's message (i am still digesting), and > now that we talk compiling C with C++, as you do (if i recall > correctly) I don't. I used C++ in the past because I needed to interact with some library written only in C++, but I hate that language, find it terrible, and don't need that library anymore, so I don't use any C++ anymore. Compiling C as C++ is usually a bad idea, IMO. > and i do, too, and then, there was a {0} "pointer", was > it. Yeah, that's a compound literal, which doesn't exist in C++, so this can't be used in C++ mode. (This reminds me that I need to wrap the musl code in !defined(__cplusplus).) That's a bad language; I recommend not using it: if you want the good things from C++, you need to use modern C++, which strays away from C too much. If you stay with the old C++, what you get is some terrible dialect that doesn't get the benefits of modern C nor of modern C++. Have a lovely night! 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
