How to read C type declarations (2003)
unixwiz.net
unixwiz.net
In B the only type is the machine word, which can perform arithmetic and be dereferenced. Arrays the only special kind of declaration and are declared like
auto foo[10]In that world, having declaration follow usage makes perfect sense. There's no "other" kinds of data to worry about, the operators you can apply to an expression describes its type exactly.
The "fix" would be to not have arrays decay. I believe C++ could probably get there if it had taken Epochs, I further believe taking Epochs (P1881) when it was proposed would have been extremely disruptive but perhaps possible and worth attempting. I do not believe it's still possible, the moment passed and with it, in my view, any hope of salvaging C++.
Without Epochs, any and every such change to C++ is similarly disruptive and that's too expensive so more or less nothing gets fixed, instead layers of kludges must be added. That's how Foonathan ends up with: class foo final trivially_relocatable namespace() { … };
As for the billion dollar mistake, a null pointer reference results in a seg fault. But the array decay results in buffer overflows, the #1 problem in shipped C code, and the buffer overflows result in memory corruption. Memory corruption is much, much, much worse than a seg fault. For example, buffer overflows are exploitable by malware. Seg faults are not.
Hence, the array decay is the worst mistake.
> semantics
Accessing a[i] means i gets checked against the array length, and it's a fatal error if it doesn't.
> ABI
Same as struct {size_t length; void* ptr;}
> size
sizeof(a)
> length
__length(a) or something like that
We invent new languages almost daily and none of them have ever resolved the problem. I mean, when you start with a pointer, it's uninitialized. Setting it to null is much better than having it point somewhere, where there might be incorrectly interpreted data.
So, null. We have Java, suffering the same problem, Golang suffering the same problem and Rust, where you have the same problem if you call unwrap, without checking that all code paths ensure you have the value populated.
Seems to me this is an inherent problem of using an uninitialized value... so, what is the mistake?
The mistake is that Nothing isn't a kind of thing. It's a categorical mistake, enshrined in many programming languages because it was easy and they didn't realise it was a bad idea, that's what Tony's talk is about - he's the one who made the mistake originally.
> I mean, when you start with a pointer, it's uninitialized
You're talking about a language implementation detail. Indeed I'd say plainly, a language defect, particularly notable in C (and so C++) where it continues to cause problems.
> We have Java, suffering the same problem
That's correct, all non-primitive Java objects can be null instead.
> Golang suffering the same problem
That's correct, Go chooses "make representable states legal" rather than "make illegal states unrepresentable" and so every type must have a legal "zero" state.
> and Rust, where you have the same problem if you call unwrap,
Nope. Try it. Call "unwrap" on a Vec, or a HashMap, or a File. You can't, there is no such method, it's a method on Option.
> Seems to me this is an inherent problem of using an uninitialized value... so, what is the mistake?
Goodness no. An actual uninitialized value by default would be a design mistake. They're currently trying to fix this mistake for C++ 26. If for performance reasons you need to delay initialization you need a trick like Rust's MaybeUninit<T> wrapper. You certainly can't paper over it with null.
Those operators are the same ones you would use in an expression to use your declared object. They are the unary dereferencing operator, the array subscription operator, the function call operator and the parentheses for overcoming default precedence.
This was the biggest mistake IMO. Go’s declaration syntax needs colons, it would have been 100x more readable.
Compare:
func foo(x int, y int) int {
var sum int = x + y
return sum
}
func foo(x: int, y: int): int {
var sum: int = x + y
return sum
}
func foo(x: int, y: int): int {
sum : int = x + y
return x + y
}
func foo(x: int, y: int): int {
sum := x + y
return x + y
}
return sumI can only assume he removed them, not for brevity, but as a compromise for the sake of C programmers to only ask them to learn one new thing rather than two.
It's especially terrible in C and C++, where you need to be on your guard for whether all the variables are being declared with the same type or whether some are pointers. Even in languages without this quirk though, I find it still slows my comprehension.
Unlike readability, conciseness of code isn't a virtue in and of itself. I see little upside to multiple-declarations, but clear downside.
Language trivia: the D language does not follow C's rule, instead it guarantees all variables in a multiple-declaration statement all have identical type:
int* x, y; // x and y are both pointers to ints
var x, y *int // both pointers to int int func foo(int x, int y) {
var sum = x + y
return sum
} foo :: proc(x : int, y : int) -> int {
sum : int = x + y
return sum
}
foo :: proc(x : int, y : int) -> int {
sum := x + y //
return sum
}So instead of this:
func foo(x: int, y: int): int {
var sum: int = x + y
return sum
}
func foo(x :int, y :int) :int {
var sum :int = x + y
return sum
}That makes as much sense as `int *i`, when `int* i` is obviously the correct (though heterodox) way.
int* i, j;
In my code I never use it. Every variable gets its own line. You might think this would blow up the declarations, but in practice it's not a problem, especially in modern C where you can move declarations down to where they're used instead of stuffing them all up at the top of the function.
People think that "int *x;" means "declare x as a pointer-to-int" but really it means "declare x such that *x (it's a code expression) is of type int." So it's a really roundabout way to say that x is a "pointer to x" while that concept of "pointer to" isn't even in the language syntax.
It's why I always cringe when I see
int* x;
int *x;
I get that this is a pretty fundamental disagreement between me and Knuth & Richie, but I think history has shown that this idea of splitting exactly one aspect of the type (if the variable is direct or a pointer) was a mistake. It's been the cause of a lot of bugs and the cases where you want to define both direct and indirect types on the same line basically don't exist. For clarity you should split those definitions up regardless of what the syntax allows.
There are basically no cases where you should be writing the following code even if it is technically correct:
int *pointer, direct;Also, a code such as:
int*x=y;
When I require more complicated types, I will generally use typedef (or typeof) instead of having to deal with the confusing syntax of types in C.
The rest of your post is perfect and objectively (subjectively) correct.
While I fortunately knew that `int* x, y` means `y` is not a pointer, I always assumed it was some kind of capricious oversight of the compiler. I had no idea the rationale was "the expression `*x` declares `x` to be a pointer to the type west of it". That strikes me as so weird! XD
As to your other concerns, it makes perfect sense.
int WHATEVER;
I've been looking a lot for a better more algebraic syntax too. All syntaxes I've found have lost on two axes _in the common and simple cases_
- low cognitive overhead
- terseness
Yes, the principle of declaration follows usage is already stretched to its limit, and C++ has certainly overstretched it. But still for the bread-and-butter use cases, the "better" syntaxes seem to always lose on those 2 axes.
This was and remains a bad decision, full stop.
'Pointer to something' should have been a parametrised type rather than C's weird syntax of overloading operator*. And I won't accept the argument that C was too old to have parametrised types: ML, Lisp, and many other functional-first languages developed alongside C and had them. We've just stuck with C because it got popular because of UNIX and then Linux.
I avoid raw pointers whenever I can when I write C++, and I yearn for a language that exposes pointers with a rich and expressive type system instead of making them glorified 64-bit unsigned ints. Pointers ought to be one-dimensional unsigned parametrised affine space types[1] (note: not affine types, which are completely different[2]), with several implications:
- comparing pointers to different types should be invalid
- subtracting pointers to the same type should return a signed 'pointer difference' type
- adding pointers to the same type should be invalid
- Get the address contained by a pointer with Ptr<T>::address()
[1]: http://videocortex.io/2018/Affine-Space-Types/
[2]: https://en.wikipedia.org/wiki/Substructural_type_system#Affi...
Programming languages are a huge waste of time. It's a domain with lots of opportunities for bike-shedding, and then for hard-core R&D too. But programming is still engineering, simple & easy that gets the job done wins over needlessly complex. And yes, inertia is real too, but if a programming language was dramatically better at what C does best, I wouldn't still start new code in it.
When you're doing systems programming, pointers being "glorified" 64-bit ints is pretty much what you need. When your requirements hit reality, all the nice abstractions break down quite easily.
> I avoid raw pointers whenever I can when I write C++
Empirically, this is the path to madness.
> - comparing pointers to different types should be invalid
It produces a warning on my C compiler and an error on C++ compiler. Note that there _can_ be pointers containing equal addresses with different types -- a struct and its first member have the same address.
> - adding pointers to the same type should be invalid
I think it is, or what exactly do you mean?
> - subtracting pointers to the same type should return a signed 'pointer difference' type
it does, that type is called ptrdiff_t, which is a signed integer type.
> - Get the address contained by a pointer with Ptr<T>::address()
But you didn't want them to be glorified 64-bit ints? Well, because of pointer arithmetic, which is a practical necessity, they kind of are, but then again they're not because C tries to abstract from that. You can kinda unwrap the pointer abstraction by casting to the (optional) uintptr_t type.
The thing is, not all machines necessarily have one flat address space that contains everything from functions to all data. Pointer representation isn't necessarily uniform -- e.g., you can have a bigger type for void-pointers that contain type information too, this way you could do run-time type checking.
I read it like 'IntegerPointer x' or 'x is an integerPointer' or 'x is a pointer to an integer'
It rhymes with the following : 'MilkGlass m' reads as:
'm is a MilkGlass' or 'm is a Glass of Milk'
int* x[200];
Now do a pointer to an array of 200 ints.
'a is of type one hundred intPointers' should, to be more consistent, be written as (int*)[100] a;
I'm not even sure whether that works, never tried it.
The fact that arrays are automatically pointers is very confusing for beginners, especially multi dimension arrays are brainbenders in that respect.
int * <---> foo;
int [] <---> foo; // ugh no!
Imagine if English had not a word for "son". To say Bob is Adam's son you would say "Bob's father is Adam".
To tell the truth, C does have the dual of * that is &. If operations on types were defined (and they are not!), then we could have a syntax like this:
&int foo;
It's not difficult to imagine a different language with a rich set of operators defined for types. We could have &T for "pointer to type T", Tn (note the infix , as multiplication) for "array of n elements of type T", and so on. Then declarations could be easier:
&int ptr;
float*3 rgb;
&int*8 foo; // array of 8 ptr
&(int*8) bar; // ptr to array
At this point, you would also move the variable to the left and the type to the right, and maybe add a colon for clarity:
ptr : ∫
rgb : float * 3;
foo : &int * 8;
bar : &(int * 8);
>foo : &int * 8;
>bar : &(int * 8);
let's aim to make the types unambiguous, simple to read and write
all C types can take at most one parameterizing type, so prefixing works unambiguously.
force const and volatile to be exclusively prefixing as well, sorting the weirdness trailing consts would allow.
() can represent a function-pointer, with its return type following
your examples would be
ptr : *int
rgb : [3]float
foo : [8]*int
bar : *[8]int
complex : a [](int, int)**(int,int)*const*volatile*(int,int)[][]*[][16]*char ;
char *(*(* volatile * const (**a[](int , int ))(int , int ))(int , int )[][])[][16]
Of course, this simple prefixing is also exactly what Go did to improve the types, with some syntactic sugar to help the reader along.
However, I strongly believe well-known symbols should keep their properties independently of whether they are used in type expression or in value expressions. So, for example, [] is already a postfix operator: it would be confusing if it was sometimes a postfix sometimes a prefix. And the unary * is already used to dereference, it would be weird if sometimes it was used to take a reference instead (for that there's already the unary &).
And don't forget the precedence: you shouldn't redefine it. So &int[] would mean &(int[]) not (&int)[].
And since we're talking of a hypothetical new language, for function types I'd choose to re-use an existing operator although for a completely different meaning: ->
Note that structs and typedefs that you define are proper type names, you can switch out "int" for them. You can easily "typedef int *intPtr;" and then merrily go "intPtr myptr".
(I think cast type-specs might be a bit of an exception here were the rule breaks a bit -- because they don't "use" a name in the cast "expression". I don't intimately understand how those work. The whole thing is an idea that was stretched to the limits, especially with C++ where consistency has pretty much been given up).
if you dont have space for that one line, switch back to punchcards
:does this look correct to you?
Although if I was writing this myself, I would split it up like so:
typedef char *StringArray[];
typedef StringArray *Func();
Func **foo[][8];
C type declarations become particularly tricky specifically when people try to directly declare (or typedef) pointers to functions/arrays without an intermediate typedef for the function/array type.
So if you make it a rule to typedef array types before creating pointers to them (although this usually makes for some rather unreadable code so maybe try avoiding it in general) and to typedef function types before creating pointers to them, you will usually have much more readable code.
As a bonus, you can then use the function typedef to provide an early type-check for a callback function (even if it's a callback your code doesn't directly use). E.g.:
typedef int Func(int a);
Func foo;
int foo(int a)
{
return a * 2;
}
if ((Lflag ? chown : lchown)(p->fts_accpath, s->st_uid, -1))
(void)printf(" not modified: %s\n",
strerror(errno));
cdecl> declare bar as const pointer to array 5 of pointer to function (int) returning const pointer to char
char * const (( const bar)[5])(int )
Also online at https://cdecl.org/
But maybe also because I changed up my general programming approach a bit and try to think a bit longer before hitting up a search engine. Also forced myself to read more reference sheets than stackoverflow or chatgpt. And I must say, this made me a lot more comfortable, because I understand more. Can recommend to go through the struggle/10
The same trick works for anything you want to typedef!
Consider this type declaration in Go:
func(string) []func(int)[]*float64
What a pointer to function (int) returning int?
The difficult way:
int (*p)(int);
typedef int Func(int);
Func *p;
// used for some hypothetical allocator API
typedef void *Alloc(size_t size);
Oh, functions can't return arrays in C. That would be a pointer. Well, that makes it easier.
double **(**(*)(char *))(int)
typedef double **A(int);
typedef A **B(char *);
B *
char *(*(**foo [][8])())[]
charへのポインタの配列へのポインタを返す関数へのポインタへのポインタの8要素からなる配列の未定サイズの配列
which uses the reverse of English possessive, and object verb order.
Imagine how much easier that last example would be with a trailing return type, Ptr<> and Array<> parametrised types, and lambda-esque function objects instead of function pointers:
char * (*(**foo[][8])())[]
let foo: Array<Array<Ptr<() -> Ptr<Arr<Ptr<Char>>>>, 8>> = ...
In this hypothetical language, one would probably dispense with 'pointer to char' and 'pointer to array' and replace them with view/range/span types, eliminating a layer of type parametrisation and many classes of bugs:
let foo: Span<Array<Ptr<() -> Ptr<Arr<StringView>>>, 8>> = ...
let foo: Span<Array<Span<() -> Span<Arr<StringView>>>, 8>> = ...
Addendum: https://cdecl.org/ is a very useful and very self-aware resource: 'C gibberish ↔ English'.
Rule #1 of programming is to make code easy to understand and self-documenting. This should be a sequence of typedefs with self-explanatory names followed by a function call taking one pointer or type and returning another.
Array<Ptr<(Int, String) -> Bool>>
Should be:
Array<OnClickCallback>
Applying that to C code keeps the insane decls in check, especially when using function pointer types
#define _Ptr(T) typeof(T\*)
#define _Array(T,N) typeof(T[N])
_Ptr(_Array(int, 8)) x = ...
(Also funny, multi-dimensional spans are coming in the form of TensorSpan<T>)
Could we have done without pointer arithmetic? Could we have hidden the pointer part of function pointers and made them syntactically just like Python or JS functions?
Did arrays as raw blocks of memory ever need to exist?
I remember when I first learned C, I didn't really see the problem, I thought it was a perfectly fine language, until I learned Python/JS/C++/Dart and saw how nice high level features and package management is.
But now I wonder how I ever used it at all without complaining!
char * foo[10][5];
$ sudo apt install cdecl
[…]
$ cdecl
Type `help' or `?' for help
cdecl> explain char *(*(**foo[][8])())[];
declare foo as array of array 8 of pointer to pointer to function returning pointer to array of pointer to char
cdecl> const foo: [_][8]**fn () [*][*:0]const u8;
Still an insane data structure, and I'm still learning Zig, so I can't promise this is precisely equivalent to the C, I got as close as I could and am unwilling to try and compile, let alone build, such a type.
No one would actually do this unless they needed `extern` compatibility. Ignoring the fact (pointed out in the Fine Article) that no one would use anything vaguely like this, a more Zig native version might be
const foo: [_][8]**fn() [][]const u8
seq[array[8, ptr ptr proc(): ptr seq[ptr char]]]]
I believe dcl mimics the cdecl program.
char*[]*function()[8][] foo;Plus the fact that arrays in type names sometimes act as pointers and sometimes not.
The best shot is to name intermediate types, since they aren’t really intermediate most of the times. Properly structured programs tend to disassemble complex structures to work on them, so you need these names anyway.
That said, C compilers definitely lack -Wunreadable-types flag which must be default.
It is a widely accepted practice to typedef pointers to functions.
With pointers, more than 2 levels of indirection is an indication of a badly written program.
In practice, the most complex declarations you should write are "pointer to pointer to x", "array of pointers to x", "array of function pointers returning x". Stuff like "pointer to function returning pointer to pointer to array" is nonsensical most of the time.
Foo : array (Positive range 1 .. 100) of access function return access Integer; uggclang: error in integer literal, did you mean "ONE HUNDRED"? at line oneAll syntax is horrible. Rust is the en vogue tool of the moment and it's objectively harder to read than C. Python used to be clean and now it's sort of a mess. C++, well...
Some languages try to get away with having simple syntax though. Javascript is in this camp, as of course are all the Lisps. And the result is that you end up drowning in a sea of complicated semantics instead, c.f. the famous "wat" video or the fact that every sexpr macro-ized DSL works like its own little butterfly.
You can't win. C is fine. Could you do better if you started from scratch? Sure. Would it last? No.
I think you're just used to C syntax. I find Rust syntax much easier to read than C syntax (and that was already true when I didn't know either language well).
When you have an entire Wikipedia article dedicated to how infamously hard your language is to parse, you have no choice but to admit that you've messed up: https://en.wikipedia.org/wiki/Lexer_hack
And let's not forget: https://en.wikipedia.org/wiki/Dangling_else
C++ must be comparatively a lot harder to parse -- C++ syntax is a huge amount of complexity added to a system that wasn't designed with that in mind.
That you link "Dangling else" is curious. The wikipedia page talks about "ambiguity" but in my mind it's no different than the ambiguity in "a + b * c", does it mean "(a + b) * c" or "a + (b * c)"? Well, make a choice and write it down.
Or don't and don't allow unnecessary ambiguity. For * and +, there's a agreed upon order of operations far more universal than a programming language, but it's sensible to use a partial order so nobody is mistaken about whether e.g. logical or and bitshift binds tighter. Similary C counld have just not have allowed omitting the braces around single-line else clauses and would have been a simpler language for it.
So... we collectively made a choice and wrote it down, then? I think you whooshed on the point. The if/else ambiguity is just a precedence rule, like many others in the expression grammar of every (well, every non-lisp) language that exists.
Which is a flaw that other languages don't have to deal with, because they learned from C's mistakes. There's no justifiable reason for a language's grammar to make this sort of thing necessary. C would be better--and simpler--without it.
I would like to have a better syntax too but it's a tradeoff. I really want to like more algebraic syntaxes like Zig/Odin/Jai but C's terseness and ease of use for the common, simple cases is unmatched unfortunately.
rust surely has it's issues, but reading types is not one of them. whatever you put inside the <> of a outermost symbol is a straightforward tree parse.
C type syntax has a simple guiding principle, there is no type syntax and "declaration follows usage" i.e. normal expression syntax. A few ugly additions that don't cleanly fit in this model were made later for practical reasons, but they don't change the basic idea, which is that there is so little to C type syntax that you can barely see it (which may also be why it's so easy to read once you've grokked it).
If this is "objectively" true please link the study which was able to somehow measure that.
That said, C's syntactic missteps appear to be accidents, while Rust delights itself in being ugly.
Rust has an innovative, but highly opinionated, memory model: the premise is writing high performance memory safe programs, with 'zero cost' abstractions and so on. You might write a program in Rust rather than C in the way you might write a program in Go rather than C: because the application is better modeled in a language which isn't C. For programs which pertain to the domain where C should be considered on its merits, if you try to write them in Rust, you may as well start each module with an unsafe block.
But no, C is not fine. It has a stunning amount of own-goals making it pointlessly difficult to write a program with a fine-grained memory policy that is correct. C also doesn't have a syntax at all until you've run CPP, and then you have a context-sensitive parse. Neither of these are mere technical formalities, they actively inhibit understanding a C program.
This is often said, but does not reflect reality. At this point, we have tons of bare-metal and OS-level Rust code existing in the world, and it still has very little unsafe overall.
There are many programs one can write in C, or Zig, or some other manual-transmission language, which, if you wrote them in Rust, would just be wrapped in a big unsafe block. That isn't because those programs have memory errors in them, it's because they have a memory policy which safe Rust doesn't support.
Examples include certain garbage collection algorithms, and embedded programs where all memory is pre-allocated and references shared somewhat promiscuously. It's possible to write analogous programs in safe Rust, but not the same program. The space of programs which are both correct, and not possible in safe Rust, is infinite. They don't come with compiler guarantees, so other support is needed. CompCert is a good example of an approach to that which isn't Rust's.
Keeping in mind that I'm referring to specific programs, not "a program which solves the problem domain". Otherwise we could just say that since you can write a program which solves the problem domain in Python, there's no use for Rust. That wouldn't lead to a productive conversation, would it.
People still choose C over Rust, even knowing what Rust is. This isn't the early days of the evangelism strike force, Steve. The above is why.
Sometimes they might be better off writing the analogous program in Rust, or seeing if they can get the program they're trying to write with limited use of unsafe blocks. Sometimes not. I know you've put a lot of work into your hammer over the years, but it's never going to be the only tool in the box.
Languages, and I'm thinking of Zig here, which make it easier to correctly implement a memory policy which doesn't happen to be Rust's, should be applauded, and not called "a massive step backwards for the industry <pouty sad face>". Like it or not, they're working in the same domain as Rust, based on different principles.
But yes, there is an infinitely large class of programs which can be written in the embedded and OS spaces, in Rust, with very little unsafe overall. I didn't intend to imply otherwise.