It must be a compiler bug!

Why is it that every fucking moron who decides to start programming insists that any errors in their programs is the compiler's fault? Doesn't it ever enter their thick fucking skulls that if you don't even know the language, just maybe the error is their own?

Why is it that every fucking moron who decides to start shitposting on /prog/ insists that any shit in their post is shii^tchan's fault? Doesn't it ever enter their thick fucking skulls that if you don't even know the language, just maybe their posts are not ＶＩＰ ＱＵＡＬＩＴＹ?

I've seen ``senior programmers'' make the same statement.

It's especially difficult to counter claims where a C compiler is involved. Plenty of people seem to think that any implementation specific behavior in their preferred compiler is the ``one true way''. Tell a Windows programmer that right shifting a plain char or casting int * to long * isn't safe and there's a good chance they'll stare at you like you're smoking crack.

>>4
right shifting a plain char [..] isn't safe
Not to shit post... but why isn't that safe?
I'm a eunuch.

>>4
Because DA STANDARD doesn't specifically guarantee what you get (logical shift or arithmetic shift).

>>5
More precisely, C happens to have three char types: char, signed char, unsigned char. And that's three types, count them. Unqualified char is either signed or unsigned (it's implementation defined), but is still a separate type from the correct qualified type. Then, right shift on a negative value of a signed integral type is again implementation-defined (but at least not undefined, praise balls).

So, basically, (char)0x80 >> 1 might be (char)0x40 or (char)0xC0, depending on whether your compiler treats char as signed and how does it do shifts on negative values.

An important note: left-shift on negative values is undefined.

>>6
So if I want to perform shifts, I should cast to an unsigned integer type?

So if I want to check dubs, I should fap to an unclothed nigger kike?

Why is C such undefined shit?

>>9
Because it's not-very-portable-assembly.

People actually blame the compiler? I can't remember ever really thinking that.

>>11
YHBT

An important note: left-shift on negative values is undefined.
But as almost every system currently in use has no "arithmetic left shift", it behaves the same as a logical shift.

casting int * to long *
Again, not an issue on most systems.

>>9
LeAbstractSystemInterface.LeBackwardsCompatibilityFace

>>13
Invoking undefined behaviour is always a problem.

>>9
The language was designed to be portable across a wide range of hardware. Cases that can't be reasonably implemented are disallowed.

>>13
I believe the second case will produce a SIGBUS on 64 bit PowerPC and SPARC.

But aren't pointers to all types the same as they all store addresses? HIBT?

>>17
No. The two big things that make pointer conversion tricky on real hardware are

1) Many systems can't load or store an operand to an arbitrary address. Most RISC systems can only access word operands at addresses that are an even multiple of the word size (e.g. word data must be naturally aligned). Even x86 has similar limitations on some SSE instructions. In the best case, attempting non-aligned access on a system that can't support it will produce a machine exception of some sort; in the worst case the data read or written will be silently mangled.

2) Many systems can represent pointers in multiple, sometimes incompatible ways. This most frequently comes up when attempting to treat function pointers as data on systems where the code and data memories are addressed separately. Less common today but more widely known are the multiple logical addressing schemes involving x86 memory segmentation.