Path: csiph.com!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: New and improved version of cdecl Date: Fri, 24 Oct 2025 13:01:55 -0700 Organization: None to speak of Lines: 104 Message-ID: <87plac132k.fsf@example.invalid> References: <87bjlyobts.fsf@example.invalid> <10dbvqs$12d0f$1@dont-email.me> <10dd0fj$1jbcv$1@dont-email.me> <87jz0l2pal.fsf@example.invalid> <10dei5s$28h93$1@dont-email.me> <8734792h4y.fsf@example.invalid> <10dfusd$2k0q4$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Fri, 24 Oct 2025 20:02:00 +0000 (UTC) Injection-Info: dont-email.me; posting-host="69089273d8ad8cb61d3f6cd6f642af28"; logging-data="2996088"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19xPfXXErkIPK2yPbqTpXj5" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:KUQFbv+92CtMPXHSvmvy5slFbtk= sha1:cTkI7qvczC+P6Wyi4uhEWhW7TP4= Xref: csiph.com comp.lang.c:394716 bart writes: > On 24/10/2025 03:00, Keith Thompson wrote: >> bart writes: >>> On 24/10/2025 00:04, Keith Thompson wrote: >>>> bart writes: >> [...] >> I note that you've ignored the vast majority of my previous article. > > I've noted it, but chose not to reply. You have a point of view and > attitude which I don't share. > > Mainly that you don't care how complicated a program for even a simple > task is, and how laborious and OS-dependent its build process is, so > long as it (eventually) works. Eventually? Once I cloned the repository, it took about 45 seconds to build and install from source on my system, and I was able to run it immediately. I happen to have a script that automates much of the process that could otherwise be done with about 3 commands. Writing that script was worthwhile *for me* because I happen to build a lot of autotools-based packages from source. Without that, it might have taken me several minutes. > That it favours your own OS, leaving users of other to have to jump > through extra hoops, doesn't appear to bother you. Why should it bother me? I can certainly see that an easier way to build cdecl on Windows would be a good thing, but it doesn't affect me. [...] > Well I built cdecl too, under WSL. Jesus, that looked a lot of work! Really? I built it under WSL myself, using exactly the same method I used on my Ubuntu system. Cygwin too. The latter was a bit slow, but I did other things while it was building. Are you at all interested in learning how to build this kind of software package more easily? If so, email me. This isn't really about C, so I'd rather not dive into it too deeply here. There are certainly things to dislike about autotools, but there are thousands of software packages that use it. Once you learn how to build one such package, you can build most of them (at least in a Unix-like environment). No, it doesn't work well for Windows without a Unix-like emulation layer. Maybe it could be enhanced to work better on Windows. Maybe you could contribute to making that happen. > However, it took me a while to find where it put the executable, as > the make process doesn't directly tell you that. It seems it puts it > inside the src directory, which is unusual. It further appears that > you have to do 'make install' to be able to run it without a path. That's not unusual -- and the "make install" step is common to hundreds of software packages. I usually don't notice where the executable initially appears; "make install" puts it where I want it. > (Yes, I did glance at the readme, but it is a .md file which I didn't > notice, and in plain text it looked unreadable.) Sure, it would be nice if the README.md were more legible. Most of them are. Apparently the author was more interested in it being readable using a markdown viewer. But if you view the project's site on GitHub, the README.md is formatted for you. > When I did run it, then while it had a fair number of options, it > didn't appear to do much beyond converting C declarations to and from > an English description. > > That program is 2.8 MB (10 times the size of my C compiler). As mentioned later in this thread, you didn't strip the executable. It might be nice if stripping the executable were the default. > I guess you don't care about that either. But surely, you must be > curious about WHY it is so big? You must surely know, with your > decades of experience, that this is 100 times bigger than necessary > for such a task? How many lines of assembly language were generated and discarded during compilation? I'm guessing you don't know or care. Why do you care so much about other things that you don't need? > I decided to make my own mini-cdecl. It took 20 minutes and works like this: > > c:\cx>qq cdecl > Mycdecl> explain void (*f(int i))(void); > f = proc(i32)ref proc()void > Mycdecl> q I doubt that that obscure syntax would be of interest to most people, though I'm sure it works for you. If you wanted to generate something more readable by more users, you might have an interesting competitor to cdecl. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */