From: Keith.S.Thompson+u@gmail.com

bart  writes:
> On 23/10/2025 02:19, Thiago Adams wrote:
>> Em 22/10/2025 18:39, Keith Thompson escreveu:
>>> This is cross-posted to comp.lang.c and comp.lang.c++.
>>> Consider redirecting followups as appropriate.
>>>
>>> cdecl, along with c++decl, is a tool that translates C or C++
>>> declaration syntax into English, and vice versa.  For example :
>>>
>>>      $ cdecl
>>>      Type `help' or `?' for help
>>>      cdecl> explain const char *foo[42]
>>>      declare foo as array 42 of pointer to const char
>>>      cdecl> declare bar as pointer to function (void) returning int
>>>      int (*bar)(void )
>>>
>>> It's also available via the web site .
>> This one does not work:
>> void (*f(int i))(void)
>
> KT said the newer version is only available by building from source
> code, which must be done under some Linux-compatible system.

As far as I know, it should build on just about any Unix-like system,
not just ones that happen to use the Linux kernel.  Perhaps that's what
you mean by "Linux-compatible"?  If so, I suggest "Unix-like" would be
clearer.  (I'm building it under Cygwin as I write this.)

> I've had a look: it comprises 32Kloc of configure script, and 68Kloc
> of C sources, so 100Kloc just to decode declarations! (A bit longer
> than the 2-page version in K&R2.)

Yes, and neither you nor I had to write any of it.  I cloned the repo,
ran one command (my wrapper script for builds like this), and it works.

I wonder how many lines of code are required for the specification of
the x86_64 CPU in the computer I'm using to write this.  But really,
it doesn't matter to me, since that work has been done, and all I
have to do is use it.

The configure script is automatically generated (I mentioned the
"bootstrap" script that generates it if you build from the git repo).

I suppose building it under Windows (without some Unix-like layer
like MinGW or Cygwin) would be more difficult.  That's true of
a lot of tools that are primarily used on Unix-like systems.
It's likely that the author of the code doesn't care about Windows.

I agree that it can be a problem that a lot of code developed for
Unix-like systems is difficult to build on Windows.  For a lot
of users, an emulation layer like Cygwin, MinGW, or WSL is a good
enough solution.  If it isn't for you, perhaps you could help solve
the problem.  Perhaps the GNU autotools could be updated with better
Windows support.  I wouldn't know how to do that; perhaps you would.

"Don't use autotools" is not a good solution, since there are so
many software packages that depend on it, often maintained by people
who don't care about Windows.

> (There's a further 30Kloc of what looks like C library code. So is
> this a complete C compiler, or does it still only do declarations?)

I haven't looked at the source code (I haven't needed to), but the man
page indicates that this version of cdecl recognizes a number of types
defined in the standard library, such as FILE, clock_t, and
std::partial_ordering (remember that it includes C++ support).

I don't know whether all this could be done in fewer lines of code, and
frankly I don't much care.  The tool works and is useful, and I didn't
have to write it.

Have you tried using it?  I'm sure you have some system where you could
build it.

> Regarding your example, my old C compiler (which is a fraction the
> size of this new Cdecl) 'explains' it as:
>
>   'ref proc(int)ref proc()void'
>
> (Not quite English, more Algol68-ish.)

Can I run your old C compiler on my Ubuntu system?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)