Hacker News Reader

Comment by amelius | Hacker News Reader

I don't mind the declarator syntax in C so much. What I do mind is the way some things are implicitly converted. For example: in

   char buffer[10];

the name "buffer" is a pointer to the first element of the buffer. This always feels like a hack, because "buffer" is an array, not a pointer to an element. I'd rather write &buffer[0]. This also feels like a hack when the buffer is coincidentally of size 0, and buffer[0] does not exist. So I'm just left with the feeling that something is missing in the language.

View on HN

If you're curious why it works that way, you should read "The Development of the C Language" by Dennis Ritchie: http://cm.bell-labs.com/who/dmr/chist.html

The short version is that in the early days, pointers where declared like "char p[]" and for arrays declared like "char buf[10]" a pointer was created, like this (in modern C):

    char buf_storage[10];   /* this is not actually visible to the programmer */
    char *buf = &buf_storage[0];

So pointers and arrays really were the same thing. Of course, this didn't fly anymore when structs were introduced (or when embedding arrays in structs was allowed, at least) so that's when arrays were introduced as a first-class type, with weird semantics so that existing code that used array variables as if they were pointer variables wouldn't break.

You're right about the implicit conversions but "buffer" is not a pointer to char. The type of buffer is "array of 10 chars" and sizeof(buffer) equals 10, not sizeof(char*) which usually will be 4 or 8. Personally, being a lazy typist, the implicit conversions from array to pointer-to-first-element have never bothered me as it allows you to write terse code and the cases where stuff gets complicated are rare and can be clarified by typedefs, as somebody already pointed out.

I don't code in C very often, but when I do, I'm always annoyed that when I see a declaration `type ∗x`, I don't know whether `x` is meant to be a "simple pointer" or a an array. At least with Go, you clearly declare `type []x` or `type ∗x`.

P.S.: how do you input a literal asterisk on HN? Escaping with a backslash doesn't work, had to find a fancy unicode asterisk.

Yeah, or that the declaration syntax of pointers are "intended to be a mnemonic". It's syntactic sugar that, instead of being a convenience, simply misleads you. C is a language where you need to know what's going on and because of these weird decisions knowing how things work actively hinders you when writing code.

int p; type nameOfInstanceOfType;

int *p; notType notNameOfInstanceOfType;

How about something sane like: "pointer p = pointer(int)" or even Scalalike "pointer[int] p"? Pointers aren't so bad really. I think a lot of the hate for them is because the syntax begs you to fuck up. And inevitably you do. I mean, I just type random stuff until I get no warnings and things look like they work. Literally. That's how I program. How many asterisks here? I dunno, I'll just try zero through three and see if any of those work...

    int* p;

Follows the Type NameOfVar pattern, though of course it breaks for multiple simultaneous declarations.

Well, it would be fairly inconvenient to have to type strcmp(&some_name[0], &some_other_name[0]) all the time. Or having to type const char ∗s = &"some constant_string"[0] -- the type of a string literal is after all "char[size]".

As to your other point: it's legal for a pointer to an object to point one item past the end of the object. You may not read/write to this of course, but if you allocate 100 bytes of memory you may have char ∗start, and char ∗end = start+100. That's a nice concept taken to its limit in STL where all algorithms operate on abstract start; end+1 iterator pairs. So an empty sequence has start == end.

(Thanks to a sibling poster for the usage of ∗).

Well, you can declare your variable as const char s[] = "...". And if strncmp were to be defined today, it really should have a prototype of int strncmp(size_t n, const char s1[static n], const char s2[static n]). This is valid C99, although it seems nobody writes code like this and prefers to degrade their arrays to pointers. (Today's C also has pointers to arrays, so the need for dynamic allocation is no valid excuse either.)

It's actually not a pointer, but it acts similarly.

http://eli.thegreenplace.net/2009/10/21/are-pointers-and-arr...

Reply on news.ycombinator.com