S
Serve Lau
"user923005" <[email protected]> schreef in bericht
These issues are separate issues.
First, there is determination of correctness:
If correctness is covered by a standard, then correctness is defined
that way.
If correctness is covered by a specification that is not a formal
standard, then we follow the specification.
Second, there is determination of robustness:
We must test our code against a known standard or expected outcome to
see if the outputs are correct.
Here, at CONNX Solutions, we have hundreds of test machines that are
occupied 24x7 testing our product.
They operate around the clock for 7 days before we even know if we
have a candiate for shipping.
By that time many millions of tests will have been performed.
I think it should be obvious what the clear separation is here. But
maybe it is only the way that I see things.
I jumped into this because of the statement
"If it is correct C and executes erratically, then your tools are broken.
Switch tools."
But your program can still execute erratically no matter how good C it is.
But I guess you were talking about compiler bugs and ulrich more about
software bugs
I agree. I noticed over the years that when software engineers talk about
improving C code its always about the UB aspects of C. "use lint or some
better tool like that" they say. But in my experience the majority of bugs
doesnt come from somebody accidently or not using UB behaviour. Its almost
always when something unexpected happens in the field. We tend to put so
much energy in lint or trying to learn write better standard compliant
code
but bugs arent reduced by it.
I remember in 11 years coding in C and C++ only ONE example where somebody
forgot to allocate space for '\0' in a string. I remember ZERO times where
I
put '=' instead of '==', only one time I remember that I forgot 'break' in
a
switch and I corrected that mistake after 1 time testing.
I dont dare think about how much time I spent on dynamic memory related
issues though
These issues are separate issues.
First, there is determination of correctness:
If correctness is covered by a standard, then correctness is defined
that way.
If correctness is covered by a specification that is not a formal
standard, then we follow the specification.
Second, there is determination of robustness:
We must test our code against a known standard or expected outcome to
see if the outputs are correct.
Here, at CONNX Solutions, we have hundreds of test machines that are
occupied 24x7 testing our product.
They operate around the clock for 7 days before we even know if we
have a candiate for shipping.
By that time many millions of tests will have been performed.
I think it should be obvious what the clear separation is here. But
maybe it is only the way that I see things.
I jumped into this because of the statement
"If it is correct C and executes erratically, then your tools are broken.
Switch tools."
But your program can still execute erratically no matter how good C it is.
But I guess you were talking about compiler bugs and ulrich more about
software bugs