Live data from Hacker News

Declaring C String Constants

eklitzke.org

21–30 of 87 posts

Re: Declaring C String Constants

#21
There's a big mistake here:

  // Bogus function, just to see how arguments are passed.
  void bogus();

  // Invoke bogus using ptr.
  void do_ptr() { bogus(&ptr, ptr); }

  // Invoke bogus using arr.
  void do_arr() { bogus(&arr, arr); }
"&ptr" and "&arr" are not the same. &ptr gives you a pointer to a pointer (char * *), but &arr just gives you a pointer to the array data. That's why the code is different.

This would normally show up as a compilation error, since &ptr and &arr have different types. It's disguised here by the variadic bogus() function.

(I didn't know that no-arg functions in C are implicitly variadic! That's bizarre. I would have expected modern compilers to disable that by default, but I can't get Clang to warn me about it even with -Wall.)

Re: Declaring C String Constants

#22
post #2

Interestingly, we get .LC0: .string "Lorem ipsum" [...] movl $.LC0, %esi movl $ptr2, %edi xorl %eax, %eax jmp bogus for the same experiment done with a const pointer to const data, const char * const ptr2 = "Lorem ipsum"; (Incidentally, this kind of thing is why I prefer to write 'char const STAR const' rather than 'const char STAR const', and 'char const STAR' rather than 'const char STAR'; it systematically places…

Had parent been a StackOverflow post, this would be the undisputed correct answer.

Re: Declaring C String Constants

#23

Any programming language that needs an entire blog post about how to declare string constants "the right way" is a programming language that needs to disappear.

Any poster that needs to post comments about how any language requiring real understanding needs to disappear needs to disappear.

Haha, real understanding. Any language which requires a standard of 700 pages should be seem suspicious. And any language, which lead to thousands of vulnerabilities needs to disappear.

Re: Declaring C String Constants

#24
post #10

Earlier quoted context omitted.

C is not that far removed from assembly, and gives the programmer strong control over how the program operates. It is a tool, and if you need safety over control / performance / portability / etc., then don't use C.

Being a language not far form assembly shouldn't mean being broken and error prone.

I'm not sure what you mean by "broken". The programmer must provide 100% correct code, as in any language. It is harder to write secure code in C than in other languages, and in return you get near-maximum control over the program.

Re: Declaring C String Constants

#25

There's a big mistake here: // Bogus function, just to see how arguments are passed. void bogus(); // Invoke bogus using ptr. void do_ptr() { bogus(&ptr, ptr); } // Invoke bogus using arr. void do_arr() { bogus(&arr, arr); } "&ptr" and "&arr" are not the same. &ptr gives you a pointer to a pointer (char * *), but &arr just gives you a pointer to the array data. That's why the code is different. This would normally sh…

>(I didn't know that no-arg functions in C are implicitly variadic! That's bizarre. I would have expected modern compilers to disable that by default, but I can't get Clang to warn me about it even with -Wall.)

I didn't know that either. I wonder if `void bogus(void)` behaves any differently?

Re: Declaring C String Constants

#26

Earlier quoted context omitted.

This is a joke, right?

Why would it be a joke? Using `#define` for a string constant is perfectly reasonable for C code, IMO I'd argue it's the idiomatic and best way to do it. String constants that are `#define`d can take advantage of C's automatic string-literal concatenation, allowing you to avoid lots of unnecessary string operations in some cases. If you declare it as a pointer or array instead, then you can't do that.

> Why would it be a joke?

A certain influential segment of the C and C++ development community, the kind that tends to worship "best practices" and "consistency", has been preaching for years that C preprocessor macros are evil, even in cases where they allow for much clearer code.

I'm not sure these people were born with the ability to experience joy.

Re: Declaring C String Constants

#27

Any programming language that needs an entire blog post about how to declare string constants "the right way" is a programming language that needs to disappear.

No, all the programming languages that trade a huge amount of CPU cycles and RAM for a small increase in convenience need to disappear.

C/C++ is there to stay for a looong time.

Re: Declaring C String Constants

#28

There's a big mistake here: // Bogus function, just to see how arguments are passed. void bogus(); // Invoke bogus using ptr. void do_ptr() { bogus(&ptr, ptr); } // Invoke bogus using arr. void do_arr() { bogus(&arr, arr); } "&ptr" and "&arr" are not the same. &ptr gives you a pointer to a pointer (char * *), but &arr just gives you a pointer to the array data. That's why the code is different. This would normally sh…

You speak the truth! &arr is a "char (*)[12]"!

Re: Declaring C String Constants

#29
post #25

There's a big mistake here: // Bogus function, just to see how arguments are passed. void bogus(); // Invoke bogus using ptr. void do_ptr() { bogus(&ptr, ptr); } // Invoke bogus using arr. void do_arr() { bogus(&arr, arr); } "&ptr" and "&arr" are not the same. &ptr gives you a pointer to a pointer (char * *), but &arr just gives you a pointer to the array data. That's why the code is different. This would normally sh…

>(I didn't know that no-arg functions in C are implicitly variadic! That's bizarre. I would have expected modern compilers to disable that by default, but I can't get Clang to warn me about it even with -Wall.) I didn't know that either. I wonder if `void bogus(void)` behaves any differently?

Yes it would behave differently. Putting void in the parenthesis tells the compiler the function accepts no arguments at all.

Re: Declaring C String Constants

#30

Any programming language that needs an entire blog post about how to declare string constants "the right way" is a programming language that needs to disappear.

I think that C is an excellent choice for -some- projects. I also like that it is easy to see how things work at a low level, since C is relatively close to the metal and maps quite well to assembly.
Post reply on HN