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?

Buffer overflow

Perhaps you have a variable that is two bytes on the stack after your array. Writing X+2 will overwrite the short variable while any more may overwrite the return address or saved EBP, causing an obvious crash.

You're invoking undefined behavior so there is no telling what it will do, it might crash but then again it might not crash.

Read SICP.

It's ^{undefinedbehavi}our.

I am aware that it is undefined. I was just wondering why this happened so consistently. >>3 is probably the answer.

>>1,7
Protip: Fucking word alignment, how does it work

Also
undefined behaviour

>>8
This. The reason is due to your compiler aligning the variables and padding to meet alignment.

>> 7
actually I think >>2 is the answer

>>2 is correct, assuming you're compiling on a x86.

And it is not the case that the program should crash in the first place.

If you overwrite your return address with a valid address, the program will continue to run, and may even run correctly depending on your input. That is actually the basis for several buffer overflow exploits.

If your routine never returns (for example, an infinite loop or an early call to exit()), your program won't crash, even if you overwrite the entire stack space before it.

Undefined behavior means undefined behavior standard-wise. It is only a catch-all situation: a wildcard in the sense that any behavior produced by an implementation is correct according to the standard.

In this particular case, the program behavior is well-defined and consistent, as you might have perceived, and this behavior is determined by the underlying environment. The compiler might insert some code to protect against stack smashing, but in the situation of the normal call-ret pair, with or without a frame pointer involved, overwriting stack addresses only affect your own local variables and any or all of your callers. You can, for example, make you or any caller return to another function or block of code instead of returning to their respective callers.

Walking forward in the stack, on the other hand, is a typical hack used to create variables with "discardable" semantics, that is: variables which are not preserved across function calls, which do not grow the stack and without the need to allocate or deallocate heap memory. Care must be taken to not overrun the stack size, that is, overflow the stack itself.

This, naturally, applies only to the x86 architecture. In other environments the behavior may differ completely.

Take a look at this.

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

void g() {
    puts("Hello, World!");
    exit(0);
}

void f() {
    int stack[1];
    /* stack[0] is local data.
     * stack[1] contains ebp.
     * stack[2] contains the return address. */
    stack[2] = g;
}

int main(void) {
    f();
}

>>12
You're invoking undefined behavior, this isn't conforming C code.

>>13
This is intentional and most obvious.

>>14
So your program is worthless, why post it?

>>15
Just fuck off, troll.

>>16
How am I a troll? I'm not the one posting broken C programs.

>>17
He is obviously posting a program which only behaves in a specific way when compiled and run on a specific compiler and architecture. I actually suspect the behavior will differ greatly even within the same compiler if different settings were used when compiling. You have the C standard and within that, the behavior his program will have is undefined, however while that wouldn't be conforming C, it doesn't mean it doesn't have very precise semantics when using a specific compiler with specific settings on a specific architecture - you can almost always determine them when you have fully specified the environment, and when you can determine them, undefined behavior will be fully defined. If your program accidentally uses some undefined behavior (such as a stack overflow), you can blame the author for having made that error, but in practice, if you want to know if your error is exploitable by others, or how to exploit it, you must understand exactly what your program does - this can be done by examining the machine code the compiler generated, and that also has very precise semantics.

>>1
Most small overflows won't cause crashes as a typical ``crash'' is an unhandled exception or signal such as an "memory access violation" or "segmentation fault" which means you've tried to access a page of memory which is not allocated, and usually the stack's memory is allocated in bulk, so an overflow isn't typically fatal, and in some OSes, stacks are growable (this tends to be done by allocating a page where the stack is supposed to grow and setting the memory's protection flags in such a way as to cause an exception or segfault to be generated, which a handler installed by the OS or compiler (depends on implementation again) will then unprotect, allocate some some more memory and set new flags, then seamlessly continue your program like nothing happened at all), which means you would have to keep growing the stack for quite some time until a stack overflow would actually occur (until one reaches a limit imposed by the OS or compiler, usually such a limit is changable).

>>18

Exactly. Thank you for your kind and precise observation, even if it was directed to a troll.

And yes, the behavior can change if different compiler settings are used.

To illustrate that using GCC, just compile the program with -O3 and you'll see that the control flow analysis has decided that f() does nothing, thus removing the call to it. The result is simply an empty program.

>>19
Again, how am I a troll, or is that just a label you give everyone who says something that you don't understand?

>>11
>>18

thank you

>>18
You have the C standard and within that, the behavior his program will have is undefined, however while that wouldn't be conforming C, it doesn't mean it doesn't have very precise semantics when using a specific compiler with specific settings on a specific architecture - you can almost always determine them when you have fully specified the environment, and when you can determine them, undefined behavior will be fully defined.
What if the compiler has non-deterministic behavior? What if the compiler has a setting like "optimize for 30 seconds" which depends not only on the compiler but also the speed of the machine, the total amount of load on the system, disk swapping and other non-controllable factors?

>>22
"Undefined Behavior" in ANSI/ISO terms is what is known as a "Semantic Error". What that means is that the implementation is free to do anything it wants. In other words, undefined behavior is defined by the implementor and not the standard itself.

>>23
Also, before I forget, undefined behavior isn't the same as non-deterministic behavior. The latter can be (kind of) solved by the C preprocessor itself.

>>22
What if the compiler has non-deterministic behavior? What if the compiler has a setting like "optimize for 30 seconds" which depends not only on the compiler but also the speed of the machine, the total amount of load on the system, disk swapping and other non-controllable factors?See:
you can almost always determine them when you have fully specified the environmentHowever, to be fair, determining them by fully understanding the compiler is a bit of a pain, and in some cases it would be literally impossible(let's say you decide to defeat my argument by using a "true random" quantum RNG), the typical way one determines what the behavior is, is by examining the assembly listing generated by the compiler or just disassembling the compiled program - it would be a lot less work than mentally following the same steps a compiler would have to.

However, to be fair, determining them by fully understanding the compiler is a bit of a pain, and in some cases it would be literally impossible(let's say you decide to defeat my argument by using a "true random" quantum RNG), the typical way one determines what the behavior is, is by examining the assembly listing generated by the compiler or just disassembling the compiled program - it would be a lot less work than mentally following the same steps a compiler would have to.
How do you know the compiler produces the same program every time? Remember that the implementation is free to do whatever it wants with undefined behavior.

>>25
You have zero clue as to what your talking about. Let me quote the previous responses you idiot...

>>23
"Undefined Behavior" in ANSI/ISO terms is what is known as a "Semantic Error". What that means is that the implementation is free to do anything it wants. In other words, undefined behavior is defined by the implementor and not the standard itself. "

And

>>24
"Also, before I forget, undefined behavior isn't the same as non-deterministic behavior. The latter can be (kind of) solved by the C preprocessor itself. "

>>26
How do you know the compiler produces the same program every time? Remember that the implementation is free to do whatever it wants with undefined behavior.

The C compiler might generate a different program everytime. However, if the program is conforming, then the C standard itself guarantess that the program will produce the same output everytime.

>>28
Yes but I believe the person I quoted believed that specifying an environment would help defining an undefined program as he could look at the assembly output, I was arguing against that.

>>29
It won't. With that, I think you need to learn the fundamental difference between the implementation and the C Abstract Machine before you start answering any questions related to the standard.

>>30
Again, I never said it did, I specifically argued against it.

>>30
And the only reason I say that is because your responses are misleading.

>>32
What's unclear exactly?

He stated that you might look at the assembly output of a compiler to tell what a program as defined by the C code is doing, especially that you were able to do so in the face of undefined behavior in the C code so that undefined behavior might become "defined" by the implementation.

I said that isn't possible since the compiler might not produce the same assembly output every time.

>>33
No, the guy that works at Kodak said the compiler might produce not produce the same output assembly everytime.

>>34
I said it as well in >>26.

Look at response >>28. He clearly said that before you clued in. Now stop projecting you fucking douche

>>28
In that case, you can only judge the generated binary.
People don't actually compile the same program each time they run it.
You've won this argument, and I will say that your argument can extended like this: Just have the compiler terminate on any undefined behavior, thus it will generate no output.

This of course has little importance to the real world question that >>1 was asking about, since compilers are rarely that fickle things. As for >>12's example, it would still be defined ``in practice'' for most compilers/implementations when specified - it's true that you could make a compiler which might generate random binaries at runtime, or not generate anything, or generate different things depending on the environment, but in practice this is rare - most of the time, when someone is writing some piece of code which is undefined by the standard, but defined by the implementation (with some specific settings), in some cases it's possible to rely on what it can do. The example of accessing the stack's boundries randomly by indexing into some stack-allocated array (for a compiler which uses a stack) is actually not that unusual: it's behavior that even compiler/implementation developers depend in their own implementations of variable argument accessing code, among a few other uses. (Obviously the semantics of this would be completly different in an implementation that doesn't use a stack or an interpreter or ...)

I would rather specify GNU-C and use __builtin_frame_address.

In that case, you can only judge the generated binary.

That's incorrect. You'd judge the assembly.

have the compiler terminate on any undefined behavior, thus it will generate no output.

Let's say I have something like the following..

#include <stdio.h>

int main(void)
{
  (void)printf("Hello");
  return 0;
}

This program has undefined behavior. How do you propose that I have the program terminate in this case?

>>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!

>>78

The one you visibly don't have a single clue about? Sure.

One could never argue, for example, that a fwrite() which happens to write to a dying hard disk
is "underfined behavior",

You're mixing up the implementation with the "C Abstract Machine".

Well from the standard:
The printf function is equivalent to fprintf with the argument stdout interposed before the arguments to printf.

The fprintf function returns when the end of the format string is encountered.

So the program terminates after printf returns and stdout is flushed and closed.

jews

>>79
I can't right now because I'm not on my *nix box -(.

>>82

Actually you're the one which seems to be mixing these two things up, as per >>63.

>>22
This is not the case here and a non-deterministic compiler wouldn't prove very useful.

>>85
Still are you certain that you are correct in this example, given the information in >>83? If a flush on stdout is sufficient for it to not block the pipe then the program in >>40 certainly does not block as printf returns and stdout is flushed and closed after return 0; is encountered in main.

>>86
No you annoying stupid shit. All the standard states is that the implmentation must be such that its behavior corresponds to the C Abstract Machine. That means

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".

Would be legal as long as the behavior of the implementation was the same as the C Abstract machine.

>>86
No you annoying stupid shit. All the standard states is that the implmentation must be such that its behavior corresponds to the C Abstract Machine. That means


>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".

Would be legal as long as the behavior of the implementation was the same as the C Abstract machine.

>>89

What the fuck are you talking about, you brutish retard?

You're the one which provided a ridiculous and defective example, cited "pipe blocking" issues to justify your failure and now is trying to fix your own argument with something a dozen people has already told you: the C standard does not give a fuck about pipes or terminals, dumbass. The program is completely correct.

>>91
I'm summarizing what ISO says regarding the implementation itself you mental midget.

Also, the program isn't correct. Again, I think I'm gonna have to start giving some concrete examples, because once again, you're getting your panties in a bundle.

Failure to output the string you put in printf immediately doesn't produce any undefined behavior, failing to do so on program termination does however. There is no shall requirement that is violated here.

>>92

So the program is not correct. Lol.

You're simply intelectually impaired to go anywhere further this  point. And stubborn as a spoiled girlie.

Just fuck off. Stop wasting everyone's time and go back to Wal Mart.

>>91

C99 7.19.2p2 says:


    A text stream is an ordered sequence of characters composed into _lines_, each line consisting of zero or more characters plus a terminating new-line character. Whether the last line requires a terminating new-line character is implementation-defined.


So again, you're stupid. And again, you have no possible future as a programmer.

>>94
Shut up and learn something from this thread you fucking moron.

>>40
This program is correct and does not feature any undefined behavior.

<stdio.h> is included so printf is defined as per the C standard library

The printf function is equivalent to fprintf with the argument stdout interposed before the arguments to printf.

The fprintf function returns when the end of the format string is encountered.

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.


The requirement is that "At program termination, all data written into files shall be identical to the result that execution of the program according to the abstract semantics would have produced.", since stdout is flushed and closed the program writes the same data to stdout as the C abstract machine would at program termination so it's a conforming implementation.

>>97

C99 7.19.2p2 says:


    A text stream is an ordered sequence of characters composed into _lines_, each line consisting of zero or more characters plus a terminating new-line character. Whether the last line requires a terminating new-line character is implementation-defined.


So again, you're stupid. And again, you have no possible future as a programmer.

>>98
Your point is moot, nothing violates that requirement.

>>99
How do you figure?

>>100
And what happened to all toilets scrubbers that were arguing with me? Exactly. Non of you mental midgets can say jack shit now. With that, I think you all need to go run off and 'lol' with your fellow retards.

>>89
>>90

Haha. I lawl'd.

It seems the Kodak guy needs some samefagging support to give his opinions some more bulk.

>>95
>>96

...Ain't that so? :)

Dude, now I feel really sorry for you. You're such a loser.

Don't take my offenses personal anymore, you really need some friendship and caring.

>>100,101
What you posted only shows that no lines are written to stdout, this doesn't exactly change anything, as the data is still written to stdout at program termination in the same manner as the C abstract machine would do it.

>>102
Is that the best response you can give you fucking moron? Ya know, most people would try and rebutt me with a sound technical argument. However, the fact that you can't only reinforces my belief that you're a complete and total dumbass with no future as a computer programmer.

>>103
So to clarify, what you cited from the standard just shows that the data written might not be a line as defined per the C standard, but what >>97 shows is that the data is indeed written.

>>103
That's assuming the program terminates.

>>106
So in other words, it's undefined behavior.

>>106
What's keeping it from terminating? After all printf returns when it reaches the end of the format string. I suppose you could suspend it with a signal, but that still isn't undefined behavior as long as it's also valid input for the C abstract machine.

>>103
How come you don't seem to have any issues understading the concept of the C abstract machine? Just curious because the other person who is calling me a a loser can't seem to grasp what is going on.

>>109
I don't know, perhaps he's a mental midget or something.

>>108
I find it kind of interesting that you seem to grasp what is going on, but >>102 doesn't.

>>110
I guess so.

I wonder why Kodak is so angry all the time. I wonder if he has some psychological condition or it's just his personality, not that it matters, but it can't be very pleasant or relaxing to constantly insult people (who don't even feel insulted by his insults) or be constantly angry, his replies seem to have this attitude regardless if the one he is responding to is correct or wrong, actually he tends to almost always argue against what is being said regardless of the correctness of the post or criticism in question, usually the only thing required to qualify such a response seems to be that the post he responds to be a response to his own post, is this because he thinks his posts cannot ever be wrong(is it pride, but why?)? not taking advantage of the natural human self-correcting/learning abilities is a grave mistake, this might leave him open to ridicule when the one he is calling names actually has a correct position.

As a sidenote, for someone who insults so much, he sure loves reusing his stock insults centered around toilet cleaning, someone's programming industry job prospects and someone's mental faculties.

If I didn't include this line, he'd also assume this post was written by the person he was arguing with now (I'm not).

Expecting insulting response which is incapable of actually insulting me as he chose to form a persona here, which means someone will tend to form an opinion on him which biases how they see his posts, instead of just judging a post's worth by the content only. Needless to say, my opinion of him is somewhat low at the moment, but it could rise if he actually chose learning over pride and integrity over job whoring.

>>109
How come you don't seem to have any issues understading the concept of the C abstract machine?
Such a device can only be Jewish in origin, so to understand it he must either be Jewish or brainwashed by Jewish academia.

>>104

Many answers have already been given to you, of several technical dimensions. Yet you still ignore responses you receive, intentionally adding confusion with your multiple impersonations and with your gratuitously uneducated responses.

There is no undefined behavior in the original program. Data will be flushed in program termination as though as fflush() was called. There is no violation of any clauses in any part of the code. Environmental influences of the sort I've described do not trigger undefined behavior as erroneous language constructs or erroneous execution paths do. There's nothing else to discuss on that matter.

You confuse a lot of things: implementations, abstract machines and language semantics. Summed up with your general lack of posture, it is surely a discussion not worth going any further, since it has seemingly become a matter of personal honor for you to "win" such a debate.

I'd surely not worry about my future. But what about yours?

For real: you need friendship and support, and maybe even some therapy. You won't go very far with your attitude. >>109, >>110: Your multiple personalities are rather pitiable. Don't you realize you've already debunked yourself?

>>114
Do you always translate the word 'abstract' to that nationality/religion? You don't consider anything that isn't directly accessible to senses real in any sense, do you?

>>113
but it can't be very pleasant or relaxing to constantly insult people
I do this now and again and I'll tell you, it feels great! The problem is that you become so committed to your earlier statements that there is no way that you can acknowledge that any of them are wrong without losing all credibility. Kodak is mostly right but he also get certain things wrong now and again, of course he denies that he's ever wrong either because he's too committed or because he actually thinks he's right.

>>115
I'm not Kodak and I wrote >>110 in response to >>109, I'm not a personality of Kodak if that's what you're implying.

>>115
Which part of the following

C99 7.19.2p2 says:


    A text stream is an ordered sequence of characters composed into _lines_, each line consisting of zero or more characters plus a terminating new-line character. Whether the last line requires a terminating new-line character is implementation-defined.


Don't you understand?

>>116
Actually I'm not ``that guy'' who constantly shitposts about all things abstract and Jewish, I was just joking.

>>117
Wow, we have a psychologist!

>>121
I'm not a psychologist I was just speaking from personal experience, for all I know you (I assume Kodak) might have a personality disorder which might make my reasoning around your incapability of admitting mistakes wrong.

WHY THE FUCK ARE YOU AFRAID OF ASSUMING YOUR ERRORS?
THIS IS A FUCKING ANONYMOUS BOARD!
NO ONE AT YOUR LAME COMPANY WILL JOKE IF YOU BEHAVE LIKE A KIND PERSON HERE BECAUSE THEY WON'T KNOW!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Kodak has decent programming knowledge but lacks the intelligence to properly use it, as evident by the mathematics thread where he showed his incompetence when it came to mathematical clarity and thought. He made several poor attempts at defining some concepts mathematically and he even attempted to argue against a mathematically proven statement disregarding the simple proofs given in the thread itself presumably because he didn't understand them. If a person isn't intelligent enough to intuitively grasp what a subset is after reading the definition and seeing a couple of simple examples then he's most likely not very bright. He even started to mix the empty set into the definition as if it made any difference.

>>113

In a number of other threads in which I discussed with him, he behaved rather well. So I kept a good feeling towards raising some discussion with him.

>>119

No part of it. It is a definition of a text stream. However, it is not stated that writing a partial text stream yields undefined behavior. The program could, for example, simply exit prematurely without terminating a given line. If there is somewhere in the document stating that incomplete text streams are not allowed, please share it.

>>118

I'm sorry, but honestly it's been hard to tell the Kodaks from other responses.

>>124
BUT I CAN WRITE ENTERPRISE QUALITY CODE!!!

>>125
I found the following..

" Data read in from a text stream will necessarily compare equal to the data that were earlier written out to that stream only if: the  data consist only of printing characters and the control characters horizontal tab and new-line; no new-line character is immediately preceded by space characters; and the last character is a new-line character.
"

>>126
Most of the code he writes that's over 5 lines usually have some kind of unintentional mistake in them, in the thread where he posted Java code he posted some nonsensical loops that didn't do what he said they were doing and he used that to argue against unordered collections. When prompted about it he of course just called the person who asked a mental midget even though the code was completely wrong.

>>127
There is no data read in from a text stream in the example so that's irrelevant. What Kodak posted is also irrelevant as there is nothing in >>40 which violates that, for reasons previously stated in this thread.

Just like I was sure % in java wasn't modulo, I'm sure what I posted has undefined behavior.

>>128
And I clearly stated that I responded to the wrong person you idiot.

>>129
Fail

check 'em

>>127

I reread that here too.

From what I understood, this says that the data effectively written will not compare equal to the data which were supposedly written, when read back in. But it does not say that if the written data does not terminate in a newline, the program will exhibit undefined behavior.

Nonetheless, I believe that something in the lines of >>64 applies in this situation. There might have been an unintentional omission from the committee, either for deciding that partial text streams are invalid, or that they are valid. Regardless, wasting time in this kind of discussion is surely not something the standard was intended to do in the first place.

There are more interesting and significant examples of undefined behavior that affect day-to-day programming and, specially, security. Even Kodak himself, filtering through his gigantic morass of offenses and violence, provided a good one.

>>124
>>128

This is some sort of serious personality flaw. Fortunately it's fixable, but it takes time and effort. I rarely relate personally to online peers, though. I just consider myself having been trolled in this case.

>>134
I wouldn't say that is insigificant because both Vi and Emacs approach this problem differently. So in other words, the people behind both of these idiotic editors clearly thought something like what I just mentioned was an issue. Otherwise they wouldn't have gone to such great lengths to "fix it".

>>134

Why are you partaking in a discussion that you consider a waste of time?

>>136
Maybe he's hoping to increase his programming foo to the point that he can land a job at Google.

>>45

detecting any possibility of undefined behavior will reduce to the halting problem.

>>138
I didn't mean 'any undefined behavior', just 'some' undefined behavior.

this thread is now about the undecidability of kittens

>>140
plox don't troll decidability of kittens has been long decided
by the ISO standard no.NY4NN3K0

>> 140 that wen't (^^) well...

this thread is now about deciding which hex codes will be used to overflow with, and the code it corresponds to ;D

i hear Nop's are kind of good? (/maybe, i'm sooo not leet ^^ / they are pretty useless on their own(?))

OP here. This has been a very informative thread. Thank you!

>>143
Well, the beginning is, anyhow.