C Gibberish to English
(cdecl.org)45 points by warkanlock 3 days ago | 30 comments
45 points by warkanlock 3 days ago | 30 comments
pavlov 5 hours ago | prev | next |
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.
khrbtxyz an hour ago | root | parent | next |
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...dapperdrake 4 hours ago | root | parent | prev | next |
Reading C Type Declarations: http://unixwiz.net/techtips/reading-cdecl.html
(NOT the author. It simply helped me.)
sebstefan 4 hours ago | root | parent | prev |
>Use typedef?
What if you're given somebody else's code and you need to understand it to put a typedef there
DaiPlusPlus 4 hours ago | root | parent |
Welp, if it’s that bad then shrug and use a #define
(Yes, this is a joke)
elcritch 2 hours ago | prev | next |
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.
Thiez 12 minutes ago | root | parent |
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.
card_zero 5 hours ago | prev | next |
Is there a language that's substantially free of gibberish?
chongli 2 hours ago | root | parent | next |
Racket Beginning Student [1] language.
unrealhoang 38 minutes ago | root | parent | prev | next |
for declaring function pointer?
Any language with type after name :
// c
char (*(*x[3])())[5];
// golang
var x [3]func() *[5]byte
pjmlp 3 hours ago | root | parent | prev | next |
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.
Joker_vD 2 hours ago | root | parent |
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.trealira 2 hours ago | root | parent |
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])();
Joker_vD an hour ago | root | parent |
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.marginalia_nu 3 hours ago | root | parent | prev | next |
Yeah sure, COBOL is great in that regard. Basically reads as English.
pwilson7 3 hours ago | root | parent | prev |
nope
djmips 4 hours ago | prev | next |
Is this largely supplanted by LLMs?
veltas 4 hours ago | root | parent | next |
The difference is I trust this website, and wouldn't trust an LLM.
marginalia_nu 3 hours ago | root | parent | prev | next |
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.
Y_Y 3 hours ago | root | parent |
Because if you don't do things exactly the way cdecl wants you get a Syntax Error
marginalia_nu 38 minutes ago | root | parent |
Wouldn't any explanation given, apart from syntax error, be wrong in the case you provide it with an invalid syntax?
andix 3 hours ago | root | parent | prev |
Probably.
Output for the example I got on opening the website:
char (*(*x())[5])()
cdecl.org: declare x as function returning pointer to array 5 of pointer to function returning charChatGPT: 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.
ngcc_hk 2 days ago | prev | next |
May need some bracket first then English.
makach 3 hours ago | prev | next |
I can read that.
I don't think it is gibberish. It's code and in order to read that code you need to understand the language, and to understand language you need learning and experience.
Maybe it can be useful for learning, but if you have to use such tool, I suspect you won't understand it anyway - so in a way it is more a gibberish-to-gibberish translator.
tuveson 12 minutes ago | root | parent |
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.
lynx23 4 hours ago | prev | next |
Why is it that the first thing I try tends to uncover shortcomings?
typedef uint64_t qbb_t __attribute__((vector_size(sizeof(uint64_t) * 4)))
Syntax error
OK, its an extension, meh.
veltas 4 hours ago | root | parent |
Looking at the project issues, it seems it supports only 1989-era C, and some Apple stuff, before you even get to attributes.
dangsux 5 hours ago | prev |
[dead]
ashleyn an hour ago | next |
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.