3 ms·
The signature doesn't tell you that. If my API said int frobnicate(char*) and you make that kind of assumption, then your code may or may not work, depend
by Retra 10y ago
The signature doesn't tell you that. If my API said
int frobnicate(char*)
and you make that kind of assumption, then your code may or may not work, depending on what the function does internally. You simply do not know whether I am operating on null-terminated char sequences or a single char.
>Um ... how do you "happen" to have a pointer-to-char?
char* text = "some text";
char* c = text[2]
There you go.
>And unknowingly call to_upper()?
Who said anything about unknowingly calling a function? It's "toupper", not "string_to_upper" or "char_to_upper". The function signature simply doesn't tell you what the function requires of its input.
PS: char* is also a pointer-to-byte in C.
- spc476 10y agoYour response to me shows you don't program in C all that much. I ran your code example through a C compiler and got: a.c:2: warning: initialization makes pointer from integer without a cast a.c:2: error: initializer element is not constant What you really want is: char * text = "some text"; char * c = &text[2]; which still doesn't prove your point because c is still pointing to a NUL-terminated string. If fronnicate() really takes a single character, I might ask why the function requires a pointer to char for a single character instead of: int frobnicate(char); but if you are going to really argue that point, so be it. Discard the fact that in idiomatic C, a char * is generally considered a NUL-terminated string (and here I'm talking ANSI C and not pre-ANSI C where char * was used where void * is used today). You are also shifting the argument, because in your original comment I replied to, the function you gave was to_upper(). toupper() is an existing C function. P.S. char * is a pointer-to-character, not a "pointer-to-byte", pedantically speaking. All the C standard says is that a 'char' is, at minimum, 8 bits in size. It can be larger. Yes, there are current systems that this is true.
- Retra 10y agoA single typo doesn't tell you anything about my programming habits. >which still doesn't prove your point because c is still pointing to a NUL-terminated string. No, it's pointing at a char that happens to be part of a nul-terminated string. The semantic intent of that distinction is entirely lost because C fails to make a distinction. I could easily overwrite that nul, and it would no longer be the case. Then it's suddenly an array of chars, and everything pointing at it is now a new type of thing. char* s = (char*) rand(); This also will point at a 'nul terminated string' with very high probability. Doesn't mean it is safe to call string functions on it... >I might ask why the function requires a pointer to char for a single character instead of int frobnicate(char) You could say the same about any pointer argument. Obviously pointers are useful for a reason. If frobnicate returned a char, I would just end up dereferencing a pointer to stick it back in the string it came from. Whether that is frobnicate's job or it's caller's job is a matter of API design, and should not be determined by C, especially when it makes no preference for any other kind of pointer. >You are also shifting the argument, because in your original comment I replied to, the function you gave was to_upper My arbitrary example function name doesn't matter one iota. Get over it, and stop being needlessly dense.