Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Declaring C String Constants

eklitzke.org

Post reply on HN
Print view View original

61–70 of 87 posts

Re: Declaring C String Constants

#61

Post by microtherion »

DSMan195276 wrote: post #14
std_throwaway wrote: post #4

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.

And you pay for that with global namespace pollution and utter confusion if you ever reuse that name in a scope where you didn't even know you included the original header file.

Re: Declaring C String Constants

#62

Post by novia »

drt1245 wrote: post #35
iainmerrick wrote: post #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 sh…

Additionally, he keeps talking about dereferencing the pointer, which I don't think is right. The pointer never gets deferenced in the code shown. I'm not an x86 guru, but I think that "movq ptr(%rip), %rsi" is different because ptr needs to be moved from relative to the instruction pointer (because it is on the stack, as a non-const variable).

This is a little off topic, but does anyone have any good resources to help me wrap my head around pointers in C? Right now they are very confusing to me.

Re: Declaring C String Constants

#63

Post by nercht12 »

Koshkin wrote: post #31
0xffff2 wrote: post #25

Earlier quoted context omitted.

>(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, in C you must use 'void' to indicate that the function takes no arguments. (This is deprecated in C++ in favor to an empty argument list - which breaks backward compatibility with C).

What happens if I extern a C function with no "void" then? Do I get a variadic in C++?

Re: Declaring C String Constants

#64

Post by nercht12 »

irundebian wrote: post #45
seibelj wrote: post #24

Earlier quoted context omitted.

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.

The point is, if it's possible to have maximum control over the program without hardness of writing secure code. And it is, as Rust and Ada are showing.

I don't know about you, but I always found Rust a real pain to use. One could say Rust is "secure", but you can still break Rust too. Incompetency knows no bounds. It's better just to learn to be competent than complain it's not dumbed-down enough for one's way of thinking. Hence, I should still learn Rust, and you can still learn C.

Re: Declaring C String Constants

#65

Post by bsder »

tonyg wrote: 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…

  char const * const ptr2 = "Lorem ipsum";
Edit: Said exact same thing as parent but formatted differently. Sorry. :)

Re: Declaring C String Constants

#66

Post by bsder »

What I find funny is that through all this he never actually mentioned the fact that sizeof() a string constant includes the NUL character at the end.

This has bitten me more times than I care to admit.

Nowadays, I almost always use the array form and actually declare my strings character by character so that I see the NUL if I actually meant to use it.

Re: Declaring C String Constants

#67

Post by 2trill2spill »

irundebian wrote: post #53
2trill2spill wrote: post #46

Earlier quoted context omitted.

I find it funny that your bashing the C language but your screen name is "irundebian" you realize that Debian is almost entirely written in C right? > The only valid reason why it should be used is for legacy reasons. Also there are many projects even today where C is the only choice, like embedded programming, some micro controllers only have a C compiler available.

And because I hate C I should run an operating system written in Rust or Ada or what? Don't understand what's so funny about that. > Also there are many projects even today where C is the only choice, like embedded programming, some micro controllers only have a C compiler available. Yes, as I said, for legacy reasons.

> And because I hate C I should run an operating system written in Rust or Ada or what? Don't understand what's so funny about that.

Do you hate C? You clearly like software written in it, ie Debian.

> Yes, as I said, for legacy reasons.

Starting a new software project wether it be embedded programing or programing on big X86-64 machines is not legacy software.

Re: Declaring C String Constants

#68

Post by Zelizz »

novia wrote: post #62
drt1245 wrote: post #35

Earlier quoted context omitted.

Additionally, he keeps talking about dereferencing the pointer, which I don't think is right. The pointer never gets deferenced in the code shown. I'm not an x86 guru, but I think that "movq ptr(%rip), %rsi" is different because ptr needs to be moved from relative to the instruction pointer (because it is on the stack, as a non-const variable).

This is a little off topic, but does anyone have any good resources to help me wrap my head around pointers in C? Right now they are very confusing to me.

Imagine all memory is a big array. A pointer is just an index into that array. A pointer dereference is like accessing something at an array index. A pointer to a pointer is array index to a location where you'll find another array index.

Re: Declaring C String Constants

#69

Post by khaled »

iainmerrick wrote: post #56
khaled wrote: post #34

Earlier quoted context omitted.

GCC has -Wstrict-prototypes.

Strange that that isn't included in -Wall! I knew -Wall isn't the same as -Weverything, but I'm always surprised at what it omits. Why wouldn't you want that warning? Edit to add: Aha, my 'gcc' was actually Clang because I'm on OS X. Installing the real GCC, I find: gcc -Wstrict-prototypes does what I want and disallows this feature. But -Wall doesn't include that flag, and GCC doesn't seem to have -Weverything. Clan…

I think it is not included in -Wall because such prototype are legitimate pre-ANSI K&R C function prototypes.

Re: Declaring C String Constants

#70

Post by irundebian »

nercht12 wrote: post #64
irundebian wrote: post #45

Earlier quoted context omitted.

The point is, if it's possible to have maximum control over the program without hardness of writing secure code. And it is, as Rust and Ada are showing.

I don't know about you, but I always found Rust a real pain to use. One could say Rust is "secure", but you can still break Rust too. Incompetency knows no bounds. It's better just to learn to be competent than complain it's not dumbed-down enough for one's way of thinking. Hence, I should still learn Rust, and you can still learn C.

I think there so reason to be competent, whatever you mean it, to complain about C.

What I learned about C is that you can never be competent enough for it. And that's the problem. A technology which isn't designed to get under control by humans under a reasonable amount of time is bad.

C is an old language, designed with the knowledge in the 70 and influenced by the needs of the later decades. At its time it was revolutionary, but today it's not fulfilling our needs.

I'm not talking about theoretic problems of C. C vulnerabilities are hunting us from day to day. Everyone is knowing that, but people still find it cool to code in C, want to be competent in C or dare to write security-critical applications in C, as though nothing had happened.

I don't want to be competent in C, because it's overly complex and it's error prone for humans to write safe, secure and readable C code. And every good software developer should know that's wise to don't use overly sophisticated technologies.

Post reply on HN