Prevent optimization of zero-ed memory.

Code:

---

#include <stdio.h>
#include <string.h>
#define BUFFLENGTH 100
int main() {
  char buffer[BUFFLENGTH+1];
  memset(buffer,0,BUFFLENGTH+1);
  fgets(buffer,BUFFLENGTH,stdin);
  buffer[strcspn(buffer,"\n")] = 0;
  printf("%s.\n",buffer);
  return 0;
}

---

This snippet of code should demonstrate my problem. GCC's optimization level of 0 will make this perform as expected: that is, any trailing newlines get removed. But at any higher optimization levels, GCC seems to decide that the assignment to zero is unnecessary, and vanishes it away.

I can, of course, make "buffer" a volatile char array, but in my real code (this is just a simplified version for clarity), GCC complains with a warning whenever I try to use "buffer" for anything else; e.g. passing it to a function, unless I re-cast it to a char * or const char *. I know of no reason why I shouldn't cast like this (to my understanding, a volatile char is the same size as a char, just treated differently by the compiler), but doing this for each invocation of "buffer" seems both annoying and ugly.

Is there any other way I can hint to GCC not to optimize this specific statement?

Since it is impossible to assign to 0, I'm guessing you mean the opposite, that is, this line?

Code:

---

buffer[strcspn(buffer,"\n")] = 0;

---

If so, that's weird: the statement is not a candidate to be removed as part of optimisation to begin with. Just to check: how did you know that the compiler is optimising it away at higher optimisation levels? For example, is this by observing actual output from test input, and if so what was your test input? Or was this by observing assembly output, and if so, what was the assembly output?

EDIT:
Scratch my request for test input, I realised that it was quite silly to ask for that. I compiled your program with gcc 7.4.0 on Ubuntu 18.04 with -O3 and could not replicate behaviour indicating that that line has been optimised away.

By the way, fgets will only read at most BUFFLENGTH - 1 characters from stdin, so are you sure you need to allocate BUFFLENGTH + 1 characters for the array?

Quote:

---

Originally Posted by laserlight

Since it is impossible to assign to 0, I'm guessing you mean the opposite, that is, this line?

Code:

---

buffer[strcspn(buffer,"\n")] = 0;

---

---

Assignment of 0 to the first character in "buffer" to have a newline, then. シ Sorry for the confusion.

Quote:

---

If so, that's weird: the statement is not a candidate to be removed as part of optimisation to begin with. Just to check: how did you know that the compiler is optimising it away at higher optimisation levels? For example, is this by observing actual output from test input, and if so what was your test input? Or was this by observing assembly output, and if so, what was the assembly output?

---

Test input. I can't read assembly, unfortunately -- I'm just a hobbyist, and haven't yet devoted time to learning it. Anyway, anything works, but I just ran it using the input "Test". On -O0, the output was

Code:

---

Test.

---

O3:

Code:

---

Test
.

---

If your statement that this shouldn't be optimized is true, I'm stumped as to how this is happening.

What version of gcc did you use to compile?

FYI: "O3" is often broken in GCC on Windows OSes.

Tim S.

Quote:

---

Originally Posted by laserlight

What version of gcc did you use to compile?

---

9.2.0.

You know, I apologize for most likely wasting your time, but the code I posted is no longer exhibiting the issue after I changed parts of it to test, then reverted to what I wrote here. I assume I must have had something different in my test code causing this issue, but I genuinely don't know what it would be, since I copy-pasted from my test file to the board.

That said, I'm still having this problem in my "real" code -- appearing when optimizations are turned on, and disappearing when they're off. It's designed roughly the same way -- strcspn-ing a char array -- so I guess I'll work on reproducing this issue in a smaller chunk of code.

Anyway, thanks for being willing to help. I apologize, again, for what was probably a stupid user error.

stahta01, thanks for the advice, but I'm running a Linux distro :eek:

I guess upgrading compiler isn't an option then :)

Unfortunately in your real code, this could be due to undefined behaviour interacting with compiler optimisation, rather than a compiler bug. But if it is due to a compiler bug involved writing a zero to previously zeroed memory, then that suggests a workaround: don't zero the memory. Now, if it must have static storage duration then that's not an option, but otherwise it might work. If you really need the trailing unused portion of the array to be zeroed, you could always do a memset after fgets instead.