sam bakki:

You've already received the answer, but here's a little history:

Certain things were left undefined to allow flexibility in implementation as well as allow the compiler to generate fast code. The various CPU architectures all had various quirks, so the best way to code some statements turns out to be very different on the different architectures. As an example, some CPUs didn't have automatic stack handling, but had addressing modes with preincrement and postdecrement. So the statements on the left would compile into faster code that the code on the right:

But on another CPU, the opposite could occur, and on yet another, neither would be faster or slower. When you combine some operations into a single expression, then if the behaviour were precisely defined, you'd penalize one CPU architecture, forcing it to generate worse code in many cases. There are (IIRC) similar issues with endianness, such as:

union foo {
    long a;
    char b;
};

int main(int, char**) {
   foo temp;
   temp.a = 0x30313233;   // ASCII values of '0', '1', '2', '3'
   putchar(temp.b);
);
[download]

One some architectures, when you run this code, you'll see the computer print a 0, while on others you'd get 3 because of the order in which the CPU would lay out bytes.

There are other issues, too, where the sizes of data types would vary by architecture (the Honeywell 6000 used 9 bits for char, 36 bits for int and 72 bits for double), character set (IBM would use EBCDIC), how structures were laid out in memory (some architectures would have a bus fault if you tried to access a word at an odd byte boundary (they wouldn't do two memory accesses for a fetch).

So when they were ironing out the standards, they punted on some decisions to allow code to be generated in the most efficient manner on the various architectures. It's one of the reasons that portability can be tricky in C. On the bright side, it's one of the reasons that C became such a widely-used language, and displaced assembly language programming--it's a bit higher level, but still lets you tune your code to be performant. When you become proficient in C, you'll get used to the oddities (especially when you write embedded code on various microprocessors).

When perl was created, it inherited some oddities from C.

...roboticus

When your only tool is a hammer, all problems look like your thumb.