Prev: header files
Next: Company looking for talented coders.
From: DavidW on 18 Feb 2010 22:11
Richard Heathfield wrote:
> JoeC wrote:
>> I cut and pasted a simple text file from one program to another. But
>> when I use the code in a different project it doesn't work. The
>> program just quits or something when it comes to the code.
>
> To answer the question in your Subject line, yes, it's possible that
> compilers have bugs BUT the chances of your revealing a bug in the
> compiler are very low. In almost 30 years of programming, I've only
> twice come across genuine bugs in C or C++ compilers "in the field"
> (as opposed to corner cases found only on Usenet!). One of them was
> amazingly obscure and it was sheer bad luck that I stumbled across it.
> The other was a really stupid thing in VS6 which they fixed in the
> next release. It is highly unlikely that you have found a compiler
> bug. Rule 1: don't blame the compiler, EVER. Rule 2 (for experts
> only): don't blame the compiler, YET.

Highly unlikely that he's found a bug or highly unlikely that he's found an
unknown one? I have found a number of bugs in MS compilers over the years. I
don't think bugs involving code optimization, for example, are all that rare. I
also found a bug in an MS linker, which was for linking 16-bit code but had
32-bit capability if you had 80386 assembly code object files. It placed the
wrong value in instructions that contained a negative 32-bit address. (I managed
to track it down in a debugger and fixed it by changing one opcode from SHR to
SAR in the linker executable file).


From: Richard Heathfield on 19 Feb 2010 06:21
DavidW wrote:
> Richard Heathfield wrote:
>> JoeC wrote:
>>> I cut and pasted a simple text file from one program to another. But
>>> when I use the code in a different project it doesn't work. The
>>> program just quits or something when it comes to the code.
>> To answer the question in your Subject line, yes, it's possible that
>> compilers have bugs BUT the chances of your revealing a bug in the
>> compiler are very low. In almost 30 years of programming, I've only
>> twice come across genuine bugs in C or C++ compilers "in the field"
>> (as opposed to corner cases found only on Usenet!). One of them was
>> amazingly obscure and it was sheer bad luck that I stumbled across it.
>> The other was a really stupid thing in VS6 which they fixed in the
>> next release. It is highly unlikely that you have found a compiler
>> bug. Rule 1: don't blame the compiler, EVER. Rule 2 (for experts
>> only): don't blame the compiler, YET.
>
> Highly unlikely that he's found a bug or highly unlikely that he's found an
> unknown one?

Highly unlikely that he's found a bug. Extraordinarily unlikely that
he's found an unknown one.

> I have found a number of bugs in MS compilers over the years.

I've only found two, in over 20 years of looking[1]. As it turned out,
neither of the bugs was unknown to MS.


[1] Kind of you to be so concerned, but no, it wasn't the *only* thing I
was doing over those 20 years! :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
From: DavidW on 23 Feb 2010 18:18
Richard Heathfield wrote:
> DavidW wrote:
>> Richard Heathfield wrote:
>>> JoeC wrote:
>>>> I cut and pasted a simple text file from one program to another. But when I
>>>> use the code in a different project it doesn't work. The program just quits
>>>> or something when it comes to the code.
>>> To answer the question in your Subject line, yes, it's possible that
>>> compilers have bugs BUT the chances of your revealing a bug in the
>>> compiler are very low. In almost 30 years of programming, I've only
>>> twice come across genuine bugs in C or C++ compilers "in the field"
>>> (as opposed to corner cases found only on Usenet!). One of them was
>>> amazingly obscure and it was sheer bad luck that I stumbled across
>>> it. The other was a really stupid thing in VS6 which they fixed in
>>> the next release. It is highly unlikely that you have found a
>>> compiler bug. Rule 1: don't blame the compiler, EVER. Rule 2 (for
>>> experts only): don't blame the compiler, YET.
>>
>> Highly unlikely that he's found a bug or highly unlikely that he's
>> found an unknown one?
>
> Highly unlikely that he's found a bug. Extraordinarily unlikely that
> he's found an unknown one.
>
>> I have found a number of bugs in MS compilers over the years.
>
> I've only found two, in over 20 years of looking[1]. As it turned out,
> neither of the bugs was unknown to MS.
>
>
> [1] Kind of you to be so concerned, but no, it wasn't the *only*
> thing I was doing over those 20 years! :-)

Some bugs can be pretty obscure. I have this comment in an old source file. I
didn't report it so I don't know if it was known:
// Compiler bug causes an internal error under the following conditions:
// 1. A function declared static is present
// 2. The static function contains a char * array also declared static
// 3. The source file contains no calls to the function
// Example source file:
// static void f()
// { static char *s[] = {"string"};
// }

To clarify, the 'internal error' was reported by the compiler.

From memory the first MS compiler to provide templates had a number of bugs in
their implementation that I came across.


 | 
Pages: 1
Prev: header files
Next: Company looking for talented coders.