Program won't crash when it should

(GCC C)
I ran a pointer over each member of an integer array, storing one character of input in each cell.

The program seems to consistently crash when I try to store X+3 or more characters, where X is the size of the array, but if I do not exceed X+2 it will not crash.

Why does it crashes exactly at the point it does, but not for X+1 or X+2?

>>40
I think what he's saying is that the compiler terminates so there is no program.

>>41
So how would the compiler terminate the program in this case?

>>42
Again, I think what he's saying is that the compiler doesn't produce any program, so there is no program to terminate.

>>39
That's incorrect. You'd judge the assembly.
Sometimes. Not all compilers generate output assembly files and instead just generate intermediate object files or just binaries. I would say that the only thing that's guaranteed to exist is the binary, but that's false: there are interpreters and there are implementations which compile code to memory without generating a binary (such as some Lisps, or various other high-level languages with JITs, although maybe I shouldn't care about them here as this thread is about C implementations).

>>40,42
What >>43 said. Compiler could refuse to compile programs with undefined behavior. Maybe it's not the best thing to do, but it's about as reasonable as the example someone gave where it's generating random code.

>>40
whats undefined here?

>>40
looks like a 'pretty valid' C program,
there is not rule against casting to void

>>45
Naw, the typical C reasoning for undefined behaviour, as well as stupid/dangerous allowed stuff, is:
You're the programmer, it's your fucking fault, faggot.

To conclude: you can determine how a compiler handles some particular piece of undefined behavior by doing some of the following: examining compiler's source code or debugging the compiler, examining generated output or intermediate files. It may not be possible to generalize this for all implementations or all programs or languages - being able to generalize for all would be impossible as it entails solving the halting problem, nevertheless, this is something which is tractable in practice for most cases people would care about - just like the endeavour of programming is tractable in practice, but a hard AI problem in general.

>>49
you can determine how a compiler handles some particular piece of undefined behavior by doing some of the following:

examining compiler's source code or debugging the compiler
Yes.

examining generated output or intermediate files
Only if you have already examined the compilers source code and have found guarantees that it will not create random programs in the face of undefined behavior, unless of course you feel that an answer to "handling some particular piece of undefined behavior" could be "randomly" :-)

>>40
What's undefined here, exactly?

>>51
Not entirely sure what >>40 has in mind, but main's prototype typically has 2 arguments: argc and argv. Defining it with no arguments won't cause problems with most popular x86 C compilers as they use the cdecl calling convention (caller cleans the stack), which essentially means that you could define a function which uses that calling convention with less arguments and it won't corrupt anything or cause a crash (but a different calling convention might corrupt the stack).

>>47
I never said nor implied that casting printf() to void produced undefined behavior. By the way, that isn't the semenatic error. Try again toilet scrubber.

>>51
The programming doesn't flush its stdout.

>>53,54
You're not even trying.

>>52
Having something like

int main(void)

Is legal according to the various C standards.

>>55
What am I not trying you fucking idiot?

Or how about something something like

#include <stdio.h>

int main(void)
{
    int x;
    printf("%d\n", x);
    return 0;
}

>>52
The standard says that you're allowed to do int main(void) as well.

>>54
That happens at exit for any conforming implementation.

As I'm sure you know the return 0 in main is equivalent to calling exit with 0 as an argument which will flush all open streams with unwritten buffered data then close all open streams.

That's conforming to ISO/IEC 9899:2011 though, C89 behavior might be different I'm not certain what the guarantees are.

>>59
The undefined behavior happens at the time printf() executes. Not when the  program terminates.

>>60
Okay now I'm curious, what's undefined about the call printf("Hello")?

So how would I have the compiler terminate these programs? Both programs have valid C syntax.

>>61
What happens if the underlying device is something other than a terminal? Would you still see the output?

>>20

You're a troll because you knew from the very beginning the purpose of the example and the purpose of the thread in general, yet you've insisted on being picky about issues which are ludicrously obvious to most of us, and which were evidently discarded as not pertaining to the discussion.

Thus, either a troll or a complete illiterate retard. I most respectfully prefer to judge you as the former.

>>24

What. Excuse me? Non-deterministic behavior solved by C preprocessor? What the fuck are you talking about?!

>>22

TL;DR: Don't over-interpret standards.

Standard-wise compilers can generate different code not only in the case of undefined behavior, but also when compiling compliant code, provided that the result meets with the observable behavior of the source code. Theoretically a compiler could insert a number of useless operations anywhere in the code, if these operations wouldn't change the output of the program. Even strictier: the compiler could refuse to compile a piece of compliant code, simply because the C standard does not say it should correctly compile every piece of compliant code!

Let me elaborate a bit what I'm trying to say.

Often with good intentions and in response to the demand of writing good, correct programs, people learn to be exaggeratedly picky and overconcerned about standards. While this is in general much better than not paying attention to the documentation at all, being ridiculously pedantic and stubborn with regards to every single letter written on an ISO document is not any good either.

Standard documents have the goal of being comprehensive, authoritative and remarkably precise references in a given subject and in the context they're devised. They must clearly give solutions to the problems they're destined to tackle, and disambiguate and answer any possible question that might arise. For that reason these documents are often extremely elaborated and carefully crafted, in the very linguistic level, to afford this degree of exactness.

However, it is this same exactness which suggest that people should be mathematically precise when relating to these documents, when in reality, there are also very practical goals which a standard tries to achieve, and sometimes these goals are not expressed in the document, mostly because these goals are rather ineffable and it would take too much verbosity to explain and enforce them. Yet these goals are fairly obvious to anyone marginally insighted into the subject.

For example, the C standard does not specify how exactly the operations in the source code should be done in the machine level. It does not explicitly state that the compiler ought to generate, let's say, the most succint or the most "natural" way of executing a given statement, simply because it is near to impossible to define these things in the general case. This allows for the behavior I've exemplified: a compiler could insert an arbitrary number of NOPs before every other sensible instruction it yields.

Now, the question is, should a compiler do that? Obviously not. While the C standard does not make such a compiler illegal, in practice this kind of behavior is simply nonsense. The committee has not written that explicitly, but they surely hadn't such a "design goal" in mind when they joined efforts to standardize the language. It's a practicality not liturgically written in the document, but nonetheless an issue everyone is well aware of.

In other words, some sort of good taste is necessary when interpreting standard documents. They're not mathematically precise, they will never be, and they were not designed with that purpose in mind in the first place. The text should never be over-interpreted, tested against every possible piece of dreamy interpretation one could think of.

Can a compiler produce random output based on some sort of generator or astrological prediction? Yes, it could. Should a compiler do that? Most likely not. Would anyone use such a tool in the general case? Well, I surely would not. These insanities are simply a disservice against their users. Compilers ought to be as predictable as possible: given the same input, it should not vary its output, unless there's a good reason for that. Compilers should not impact their program's performance arbitrarily, either. One's output is another one's input: a compiler which does not offer good, consistent behavior in its output will turn the life of linkers, interpreters, loaders and kernels an incompatibility hell.

Some people object with things like, "Well, the standard does not define the execution character set of programs, how can one possibly write a compliant 'Hello World' program? What if the compiler generated ROT13 representations of the EBCDIC character set as output?" That's just stupid. No one would ever design such a tool, at least not expecting it to be employed for anything useful at all. Should you care, thus, about strings of your output being "accidentally" replaced with ROT13 EBCDICs by your enemy-compiler? Of course not. Your code is still fully compliant as far as any standard is concerned.

So, don't be insanely obsessed with what standards allow and do not allow. When writing compliant code one should always try to be up to par with what is explicitly allowed, but look no further if you're completely crippled by what is explicitly and strictly allowed. For example, do not worry whether your high-performance code will be filled in with NOPs because, well, you know, the current date/time of your machine is a multiple of 7 and your compiler could decide it's a good reason for trolling you.

Note that when one is writing code with performance in mind, one is implicitly assuming the compiler won't arbitrarily mess with his work, and this assumption could drive the idea that you're actually writing code which depends on compiler behavior!

>>64
I'm talking about how you would handle a functions prototype, its declaration, and its defintion you mental midget.

>>63
How does "seeing the output" have anything to do with printf invoking undefined behavior? printf doesn't come with any guarantees of seeing the input.

>>61
I believe it's because the printf doesn't end in a newline, so the stdout buffer isn't flushed.

>>67
It doesn't matter, it's flushed at exit.

>>66
If you're on a terminal, the example I gave would work. However, if I changed the underlying device to say a pipe, you wouldn't see any kind of output. Now if I flushed the stdout, I would see the output, regardless of the underlying device.

>>67
Yeah!

>>64
You copied that from some article, right?
Or do you have a stash of copy-pastas for everything.

>>69
Still I don't see how that's undefined behavior, a conforming implementation only has to write the same data as the C abstract machine does at termination.

>>72
C abstract machine
Oh boy, here we go again.

>>72
Yeah, but if the program is running over a pipe, it will never terminate because a pipe is fully buffered whereas something like a terminal is line buffered.

>>40
>>69

There is absolutely nothing undefined in the original program. Absolutely. Also note that the C standard has no notion of devices.

Undefined behavior is something that only exists at the language level. One could never argue, for example, that a fwrite() which happens to write to a dying hard disk
is "underfined behavior", or that an auto int x; which happened to be allocated on a failing memory circuitry during execution is "undefined behavior".

Don't mix things up.

The >>58 program, however, is indeed undefined.

GC a sHIT

>>71

No, but I will take that as a compliment.

>>75
It's undefined. Uhh...Don't make me have to cite the standard on your monkey ass.

>>74
The program terminates after printf has written its data to stdout and after that stdout is flushed and closed.

Perhaps I am missing something here, could you please set up a simple example of using this program in a pipe where it will block? So I may understand better.

>>78
Bring forth the holy standard!