Why doesn't this end

>>1
mingw
Ah, I found the bug. You're on Windows. C only works on unix. On windows you need C++ or C#. My favourite programming language is dot net.

>>16
>variables are not initialised unless you explicitly initialise them
Except compilers don't give a fuck, and the program still increments a, though it's undefined.

And "something is not undefined" is not an explanation for it's behavior when it's not.

>>18
"something is not defined"*

>>16

This still does not mean he can't use an int.

The true error lies in the lack of initialization, not in the usage of int instead of char.

Hell, you can use:

time_t t;
for (t=0;t<256;++t) { putchar((char)t); }

if you wish.

>>20
The whole point of my thing though is where, or more important, what determines where unitialized variables start?

Yes, my original code seems to go on endlessly looping 255 characters, but where and why does it even start without being initialized?

>>18
Its value is defined, you just don't know what it is. This is what warnings are for. What if a happened to be 257?

>>22
Then the value that's in the position is determined by whether or not that part of memory has been wiped? That is the only effect of not initializing variables?

Apparently ``undefined behavior'' is a difficult concept now.

>>23
>Yes.
>He finally gets it.

>>25
>finally gets it
No, there is no possibly way it's clear for someone who hasn't learned the conventions of the language.

>>24
>undefined behavior
>implying the C standard leaves anything undefined
If it did, I would call shame on ANSI for ratifying it.

If you leave a variable unitialized, it will just take the value of whatever is there in the stack (assuming you're using a stack-based C implementation, which is the majority of them). Some (very few) implementations actually null the stack, but most won't, so the value of your variable depends on whatever leftover variables were left from other functions that ran before it, including your own code, or system's initialization code or whatever. In general, it's bad to rely on uninitiliazed variables for anything, you can't rely on them being constant or random, or anything (that is, unless you're in exact control of your compiler, implementation, OS, etc). >>24 said it right. This is a fairly direct form of "undefined behaviour", although in practice you can expect undefined variables to have a value, just none you can rely on in any way whatsoever, so you should always initialize your variables.

>>24
He's from the imageboards, cut him some slack. It's a wonder he managed to get from nothing to a text file that he somewhat knows how to compile.

What I don't understand is why OP's loop never ends.

He does increment a, even if it's not initialized. By declaring the variable, it gets some block of memory assigned and, by not initializing it, the allocated memory is not cleared and the old value there is kept. Assume the worst - that this value is 257, and assume that an int is signed 4 bytes. By incrementing the variable in this while loop, it should reach 2^15-1 relatively quickly, overflow, wrap around to -2^15 and keep counting until it reaches 256 and terminates.

It certainly would NEVER exit if it were a char. An unsigned char will never reach 256. Instead, it wraps around at 255 back to 0 and the test in the while loop would always be true.

>>29
It's 2³²-1. Also I/O takes a long time.

back to /g/, please

>>30

It'd be 2^31-1 if it were signed.

>>32
Yeah, I realised this. It's still a hell of a lot of numbers though.

>>33
It doesn't really take that long to run it, here's a quick benchmark I just wrote:

RDTSC
XOR ECX,ECX

LOOP:        
INC ECX
JNZ SHORT LOOP
MOV ECX,EAX
MOV EBX,EDX
RDTSC
SUB EAX,ECX
SUB EDX,EBX
This results is: eax = 019E6C7A, edx= 00000001 here, which is only some 1-2s on my x86 CPU.

For those that can't read x86 asm, that's the equivalent of:

unsigned int i = 0; while(++i);
With some timing code wrapped around at the start and end (well, actually it's a tick count, however given the processor and its frequency, you can convert it into a time unit).

>>34
There is a bottleneck, and it is putchar.

>>34,35
Oh, never mind I just read >>3

>>35
Yes, I know, however just looping through unsigned integer (on 32bit systems), barely takes more than a few seconds on most modern x86 CPUs.

Just pipe it to /dev/null

>>35
If you're piping the output to /dev/null, the compiler is going to optimize it out anyway.

>>39

You pipe it at runtime.

>>40
yhbt

>>41
Motherfucker.

Maybe a has a value greater than 256?
IT IS A MYSTERY

>>43
Maybe PAY ATTENTION TO THE THREAD GODDAMN

yhl yhbt hand

Relevant parts of the latest C99 standard (n1256.pdf) regarding uninitialized automatic storage duration objects:

6.7.8p10: If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate.

3.17.2 (definition of indeterminate value): Either an unspecified value or a trap representation.

3.17.3 (definition of unspecified value): Valid value of the relevant type where this International Standard imposes no requirements on which value is chosen in any instance. NOTE An unspecified value cannot be a trap representation.

6.2.6.1p5 (definition of trap representation): Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.⁴¹⁾ Such a representation is called a trap representation.

Footnote 41: Thus, an automatic variable can be initialized to a trap representation without causing undefined behavior,but the value of the variable cannot be used until a proper value is stored in it.

>>46
Thanks, Zhivago.

49 Name: Anonymous 2011-02-04 19:10

---

Don't change these.

Name:		Email:
Entire Thread Thread List