0

I have the following code:

#include <stdio.h>
#include <stdlib.h>

int main()
{
    char buffer[2];
    strcpy(buffer, "12345678910");
    printf("%s\n", buffer);
    return 0;
}

Since, I have already defined the char array with size 2, I shouldn't be able to put in more than 2 char plus null terminating character. Yet, it is able to take more than that without any buffer overflows or segmentation faults. Even if I copy the string strcpy(buffer, "123456789101298362936129736129369182");, it works fine. The error is generated when I push strcpy(buffer, "1234567891012983629361297361293691823691823869182632918263918");.

More of a theroetical question than a practical, but I hope it helps the new and the experienced programmers alike since it talks about the fundamentals, and helps improving coding ethics. Thanks in advance.

Devanshu Misra
  • 773
  • 1
  • 9
  • 28
  • 2
    *"I shouldn't be able to ...."* - you *can*, but you incur *undefined behavior* when doing so, and with that, all sanity and predictable behavior of your program goes down the drain. Your assessment of validity of "without any buffer overflows or segmentation faults."is a point of confusion. You're assuming the behavior you *observed* is defined; the very structure of your program says otherwise. Don't confuse defined behavior with observed behavior. The former leads to the latter; the latter proves *nothing* if the former isn't there to begin with. – WhozCraig Oct 30 '19 at 09:41
  • Depends on the current memory layout, your OS, etc. You're either overriding accessible memory, or you are performing an illegal memory write-access. The behavior of your program is not well defined when executed on different platforms (and even on a single platform where conditions change from one execution to another). – goodvibration Oct 30 '19 at 09:41
  • 1
    And BTW, this forum is kinda like a cult, with a very strict set of rules, one of the basic of which being "shalt not perform or even think about performing any type of undefined behavior"... So get ready for some dislikes (not by me of course). – goodvibration Oct 30 '19 at 09:43
  • The worst of scenarios is exactly what you are experiencing; everything *appears* to work, but in reality all is not well. Such situations tend to rear the nature of undefined behavior at the most inopportune times, such as when code that appears to run fine on *your* machine pukes its guts out on, say, a professor's rig, or even work, a *customer's* environment. Fail-hard/Fail-fast is far more preferential to appears to work; at least then there is less of a chance of false, misplaced, contentment just waiting to gouge us with a dull spoon. – WhozCraig Oct 30 '19 at 10:09
  • @goodvibration Except from compiler extensions, I don't see any reason to invoke UB. At least not when you are learning. If you really know what you're doing and you're doing some heavy micro optimizations (Carmack trick) for a specific platform, then it's another thing. But UB:s are the source of so many bugs that are really tricky to find, so you should be able to motivate invoking it EVERY time. – klutt Oct 30 '19 at 11:08

1 Answers1

4

The simple answer is that C does not protect you from yourself. It's YOUR responsibility to check boundaries. The program will happily read and write wherever you instruct it to. However, the operating system may say something if you do this, which is usually a "segmentation fault". A worse scenario is that it may overwrite other variables.

This is a source of many bugs in C, so be careful. Whenever you're writing outside outside a buffer, you're invoking undefined behavior and these can manifest themselves in various ways, including the program working as it should, overwriting variables and segmentation faults.

I shouldn't be able to put in more than 2 char plus null terminating character

This is a common bug. It's NOT "plus null terminating character". It's INCLUDING null terminating character.

klutt
  • 30,332
  • 17
  • 55
  • 95