Live data from Hacker News

C Gibberish to English

cdecl.org

21–30 of 54 posts

Re: C Gibberish to English

#22
post #18

Is there a language that's substantially free of gibberish?

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.

Compare

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

   var x: pointer to func() pointer to array[5] of pointer to func() char;
or if you wish to replace some keywords with glyphs:

   var x: ^func() ^[5] ^func() char;
And it's always a nice puzzle for the reader to explain why there are three "pointer" in cdecl output and three carets in the ALGOL-like declaration, but only two asterisks in the C declaration.

Re: C Gibberish to English

#24
post #18

Earlier quoted context omitted.

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.

Compare char (*(*x())[5])(); and var x: pointer to func() pointer to array[5] of pointer to func() char; or if you wish to replace some keywords with glyphs: var x: ^func() ^[5] ^func() char; And it's always a nice puzzle for the reader to explain why there are three "pointer" in cdecl output and three carets in the ALGOL-like declaration, but only two asterisks in the C declaration.

In this case, the C declaration doesn't match the other two. The variable x is a function that returns a pointer to an array of 5 pointers to functions returning char. Indeed, that's what cdecl.org says:

  declare x as function returning pointer to array 5 of pointer to function returning char
Using the notation you did, that would be:

  var x: func() ^[5] ^func() char
There are only two arrows there now.

If you wanted a pointer to a function like this, you would need a third asterisk in the declaration:

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

Re: C Gibberish to English

#25

   char (*(*x[3])())[5]
I'm more of the mindset that writing something like this is probably a code smell to begin with. Is there any reason I'm not thinking of right now, that this couldn't be typedef'd and refactored into something far more readable?

C gets a lot of blame for pointer gibberish like this but quite honestly you can write gibberish in any language. I don't see any fundamental or technical reason you couldn't write clean, readable C.

Re: C Gibberish to English

#26

Earlier quoted context omitted.

Compare char (*(*x())[5])(); and var x: pointer to func() pointer to array[5] of pointer to func() char; or if you wish to replace some keywords with glyphs: var x: ^func() ^[5] ^func() char; And it's always a nice puzzle for the reader to explain why there are three "pointer" in cdecl output and three carets in the ALGOL-like declaration, but only two asterisks in the C declaration.

In this case, the C declaration doesn't match the other two. The variable x is a function that returns a pointer to an array of 5 pointers to functions returning char. Indeed, that's what cdecl.org says: declare x as function returning pointer to array 5 of pointer to function returning char Using the notation you did, that would be: var x: func() ^[5] ^func() char There are only two arrows there now. If you wanted a…

Oh, good catch, thank you! But I remember an example with some other tricky C expression/type declarator where the number of actual dereferences differed from the amount of asterisks in the code.

> Using the notation you did, that would be:

Well, it'd be

    func x() ^[5] ^func() char; ...
because it's a function declaration, after all, not a variable.

Re: C Gibberish to English

#27
post #3

Use typedef? Granted, the function pointer syntax is forever confusing (to me anyway). The rest is easily tackled by naming things. Even for function pointers, it’s just one lookup and then you can copy-paste the typedef for any other function pointer types in the project.

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);
https://github.com/torvalds/linux/blob/0a9b9d17f3a781dea03ba...

Re: C Gibberish to English

#28
post #17

Earlier quoted context omitted.

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.

Because if you don't do things exactly the way cdecl wants you get a Syntax Error

Wouldn't any explanation given, apart from syntax error, be wrong in the case you provide it with an invalid syntax?

Re: C Gibberish to English

#30

Handy site! Next I want one to explain some of Rust’s more cryptic pointer gibberish. Usually I just hit “use suggested fix X” until the compiler’s happy.

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.
Post reply on HN