Why do people continue to use this term "code smell", instead of "hard to read code" or something similar, more equivalent??? First seem almost offensive to an author.

I'm not a C programmer but your comment reminds me of all the lame jokes people make about the German language.

the function signature certainly should be type def-ed. i.e.

    typedef char (*fn())[5];

    fn x [3];

Function typedefs make this less confusing by removing awkward parentheses. e.g.

  typedef int read_block_fn(void *context, u8 *buf, unsigned int block, size_t len);

Reading C Type Declarations: http://unixwiz.net/techtips/reading-cdecl.html

(NOT the author. It simply helped me.)

>Use typedef?

What if you're given somebody else's code and you need to understand it to put a typedef there

Rust isn't so bad, is it? The example of `char ((x[3])())[5]` would translate to `[fn() -> [fn() -> u8; 5]; 3]`. It's inherently an ugly type, but I think it's easier to read than the C version.

I disagree. The conventions for declaring arrays, pointers, and function pointers are all idiosyncratic. In C, the type is always to the left of the variable being declared. Except for arrays, which have part of the declaration to the right. And except for pointers, which need to be affixed to every item if there are multiple declarations. And except for function pointers where you need to wrap the variable name like (*name). Individually I can wrap my head around these exceptions, but putting all of them together, it's just hard to read.

It takes a pretty smart person to do that. Which is pretty confusing.

How can such a smart person not not understand how all things that are possible are not all equally good?

The fact that both the compiler and you can parse that doesn't make it a good way to document or convey meaning or intent.

C is chock full of inconsistencies and ambiguities that are only disambiguated by essentially being a human compiler and maintaining the same parsing state-machine manually in your head to know what any given "(" actually means or does. As a self-proclaimed fluent C linguist, you know this better than most.

All coding involves that of course but all implimentations are not equally unhelpful.

The cpu and some people can read the binary itself. They just need to know the cpu's opcodes, documented right in the datasheet that anyone can read.

Racket Beginning Student [1] language.

[1] https://docs.racket-lang.org/htdp-langs/beginner.html

Those of Algol/Wirth linage, or influenced by then.

Then again people complain that they are too verbose, and they rather write in hieroglyph friendly languages.

for declaring function pointer?

Any language with type after name :

    // c
    char (*(*x[3])())[5];
    // golang
    var x [3]func() *[5]byte

Depends on the features you want.

forth will contain as much gibberish as you put into it

Yeah sure, COBOL is great in that regard. Basically reads as English.

nope

The difference is I trust this website, and wouldn't trust an LLM.

LLMs are mostly correct with regards to this stuff.

cdecl is always correct with regards to this stuff.

I don't know why you'd choose the former.

Probably.

Output for the example I got on opening the website:

  char (*(*x())[5])()

ChatGPT: x is a function that, when called, gives us access to 5 functions that each return a character. (TL;DR, it gave a full explanation too)

Like mentioned before the error rate of LLMs is probably much higher on complex expressions.

Looking at the project issues, it seems it supports only 1989-era C, and some Apple stuff, before you even get to attributes.

This failed because it doesn't do math: int *x[10/2]