0

For example, in

#define NUM_THREADS 8
char *messages[NUM_THREADS];
messages[0] = "English: Hello World!";
messages[1] = "French: Bonjour, le monde!";
messages[2] = "Spanish: Hola al mundo";
messages[3] = "Klingon: Nuq neH!";
messages[4] = "German: Guten Tag, Welt!"; 
messages[5] = "Russian: Zdravstvytye, mir!";
messages[6] = "Japan: Sekai e konnichiwa!";
messages[7] = "Latin: Orbis, te saluto!";

During compile time, does the compiler calculate the maximum length of all those strings and then reserve space = NUM_THREADS * ( max_len + 1 ). Added 1 for the null byte at the end of strings. Or is different amount of space allocated for each of those strings depending on their length rounded up to the nearest word?

However, this can't always be possible since the initialization need not necessarily happen at compile time. I'm assuming a pointer to the data section where the strings will be stored is held with messages[i].

user3740387
  • 337
  • 1
  • 3
  • 13
  • 1
    It is an array of pointers (each points to an char array of it's own length) and make it `const char *messages[NUM_THREADS];` –  Apr 08 '15 at 18:33
  • This is illegal for ISO standard, although gcc and clang allow it without error. – SwiftMango Apr 08 '15 at 19:07
  • What is it that's illegal? Also could you pl go through my comments in Blindy's answer and answer them? I'm interested in knowing the entire mechanism as to how and in which segment the string is stored and accessed. In addition why does a certain way work with compile time strings but doesn't work with input entered at runtime. Thanks. – user3740387 Apr 08 '15 at 19:18

1 Answers1

4

The memory used by those strings is exactly as long as the string length plus one (the terminating null character). The array you defined has 4*NUM_THREADS bytes (assuming your vanilla variety of 32-bit C compiler) since it only holds pointers, not copies of the entire strings.

There's no rounding, no guessing, no fuzzing of data. This is C.

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • 3
    "This is C." Awesome. – John Bollinger Apr 08 '15 at 18:36
  • Am I right in assuming that the strings reside in the data segment and the same works for cin>>messages[i] i.e. the string goes into the data segment even at runtime? – user3740387 Apr 08 '15 at 19:06
  • `cin>>messages[i]` is undefined behavior. – drescherjm Apr 08 '15 at 19:08
  • Oh, thanks for pointing that out to me. I wrote that on Xcode and it didn't give any compilation error. But it faulted on running. Could you please explain as to why this is so? Why doesn't the same mechanism work even for runtime input. This actually was my primary question. – user3740387 Apr 08 '15 at 19:13
  • @drescherjm From the link you recently posted(http://stackoverflow.com/questions/1614723/why-is-this-string-reversal-c-code-causing-a-segmentation-fault/1614739#1614739), I understand that the data segment I was referring to is read-only and can't be written to at runtime. So why does the data segment exist at all? Just to hold strings literals declared at runtime and save space in stack and some time during execution(stack writing/loading)? – user3740387 Apr 08 '15 at 19:24
  • The read only data segment as you call it isn't the opposite of the stack. It could be held literally anywhere in RAM. It's actually a code segment, your executable is memory mapped when loaded and since the strings are assembled as is you can just use the address right away. Also it's not "runtime", the runtime has no write access to these pages (hence the crash in any protected OS). – Blindy Apr 08 '15 at 21:32