Sizeof is surprisingly difficult to parse in C
1–10 of 15 posts
Re: Sizeof is surprisingly difficult to parse in C
#2> (everything here also applies to c2y's newly introduced _Countof)
Stop the press, they're adding what? So I don't have to keep adding #define count_of(arr) (sizeof(arr) / sizeof(*arr)) to every codebase and living with its failure modes?
I'm really loving C's character arc at the moment, where they keep going back to fix old problems instead of piling everything and the kitchen sink into the language.
Re: Sizeof is surprisingly difficult to parse in C
#3Wait, they added a new operator and didn't fix that parsing stupidity by always requiring parentheses?
Re: Sizeof is surprisingly difficult to parse in C
#4I feel like what you struggle with is expression parsing, not sizeof itself?
Re: Sizeof is surprisingly difficult to parse in C
#5> (everything here also applies to c2y's newly introduced _Countof) Stop the press, they're adding what ? So I don't have to keep adding #define count_of(arr) (sizeof(arr) / sizeof(*arr)) to every codebase and living with its failure modes? I'm really loving C's character arc at the moment, where they keep going back to fix old problems instead of piling everything and the kitchen sink into the language.
Yeah, despite puritanical hand-wringing over C23, I do like both the discipline and the selectivity with WG14 has shows (and I say this as a card-carrying C++ hater).
I do wish they will start looking into proper arrays since there is already a syntax for this can can be augmented semantically:
int func (int arg[static 5])Re: Sizeof is surprisingly difficult to parse in C
#6It's a unary operator, kind of like ~ or !, which can apply to parenthesis (), until it meets a type, then the parenthesis are mandatory:
int x;
sizeof x; // okay
sizeof (x); // okay
sizeof int; // not okay
sizeof (int); // okay
read_prefix():
is peak() '!': ...
is peak() '~": ...
is alpha(peak())
maybe alpha is sizeof?
wait, it wasn't sizeof? it was an identifier? long rewind
is peak() '+': ...
\ramble on
(actually, better yet, it should've been used instead of & for taking the address). Imagine:
int x;
int* p = @x;
Re: Sizeof is surprisingly difficult to parse in C
#7Wait, they added a new operator and didn't fix that parsing stupidity by always requiring parentheses?
I assume that there would be a zillion of legacy C source files that would be broken by such a change.
Re: Sizeof is surprisingly difficult to parse in C
#8> (everything here also applies to c2y's newly introduced _Countof) Stop the press, they're adding what ? So I don't have to keep adding #define count_of(arr) (sizeof(arr) / sizeof(*arr)) to every codebase and living with its failure modes? I'm really loving C's character arc at the moment, where they keep going back to fix old problems instead of piling everything and the kitchen sink into the language.
> I'm really loving C's character arc at the moment, where they keep going back to fix old problems
Valid, but it does seem a bit Stockholm Syndrome to have this much rejoicing that your language added a builtin for getting the length of an array in 2026.
Re: Sizeof is surprisingly difficult to parse in C
#9Re: Sizeof is surprisingly difficult to parse in C
#10Earlier quoted context omitted.
I assume that there would be a zillion of legacy C source files that would be broken by such a change.
There are no legacy C source files using _Countof.
That was discussed, but consistency with sizeof was considered more important. And if you figured out how to parse sizeof, parsing countof is not an additional burden.