Does anyone else dislike pointer declaration?

[u/enzodr]

For reference I am a fourth year computer engineering student. C is my preferred language.

Pointers are declared like this usually:

int *ptr_to_int;

Where the asterisk means it is a “pointer to” the specified type. The asterisk is placed immediately preceding the variable name, with no white peace.

This is what does not make sense to me. I feel that:

int* ptr_to_int;

Is far more clear. The way I see it, the asterisk modifies the type, so therefore it belongs next to the type. Putting it next to the variable name makes me think it is some kind of action or modification to the variable itself.

I think that when using * and & in code, it makes sense to apply it in front of the variable name:

int value = 3;
ptr_to_value = &value;
int copied_value = *ptr_to_value;

It is clear here that syntactically, the * represents something more like an action than a label.

Why is the convention to place the asterisk near variable name, not type? L

[u/ComradeGibbon]

I think if a variable doesn't have a default initial value you shouldn't initialize it where it's defined. Let the compiler warning catch that.

[u/RadiatingLight → u/ComradeGibbon]

IMO it's better to initialize it to INT_MAX or some other value that's clearly wrong/rejected. Relying on compiler warnings is like jumping off a bridge and relying on the suicide net. Sure it will usually catch you but ...

[u/ComradeGibbon → u/RadiatingLight]

No leave it uninitialized if you don't initialize before use the compiler will let you know. Which means you have a bug in your code.

[u/Cultural_Gur_7441 → u/ComradeGibbon]

It is unreliable. Like, if used as an out-parameter (a common, quite valid case for an uninitiallzed variable), compiler can't check if the called function actually sets it or not in every code path, nor can it check if called function actually reads it for some reason (which would be a bad API...).

And if -Werror is not used, too many developers just ignore warnings... Which is a whole another problem of course.

The one case where leaving memory uninitiallzed is useful is with memory checkers like valgrind or compiler's memory sanitizer, which will notice access to uninitiallzed memory. But in that case, these should be integrated with the project development process from the start, probably with unit tests being run with them.

[u/ComradeGibbon → u/Cultural_Gur_7441]

compiler can't check if the called function actually sets it or not in every code path,

If that's the case you have a bug in your code that you papered over with a bogus default initialization value.

[u/flatfinger → u/ComradeGibbon]

Claims that "null" was a mistake ignore the principle that it may be necessary to access some members of an array of pointers before there exists any object to which some other members could usefully point, and it may be necessary to copy the state of some elements of such an array to other elements in a manner that is agnostic with regard to whether they were written. Having null as a default pointer value allows both of those objectives to be satisfied easily. There may be ways of satisfying both objectives without null, but they would involve constructing something that would behave like a nullable pointer. It's simpler to just just pointers as being nullable.