John,
>I agree with Paddy's sentiments, but am also aware of the problems of
>producing test cases for some problems. Users might spend an hour trying
>to produce a simple test case, but if that fails they will tend to write
>workarounds or switch compiler versions to avoid the problem, especially
>as the combination of fix time and install time can be so great.
>I've had a compiler bug extant in operational code for several years
>because I know I can fix a memory over-writing problem by inserting an
>otherwise pointless internal write statement. No attempts to duplicate
>the situation in test cases ever did, and its currently easier to leave
>the hack in place than track down the bug.
[What happens with the memory overwrite if you have to port to another machine,
or upgrade your present one?]
We use regression testing extensively, and any acceptance of a variation must be
documented. And yes, we have compiled without optimisation, if that was a cure,
but only UNTIL we could resolve the problem.
To elaborate. I did say that my organisation has been a field test site for our
vendor. We agree as part of the licence (and we get Fortran on machines that
are not normally licenced) that we will provide code or a subset that fails. We
have found compiler bugs ("hoped for" by the vendor), and we have also found
bugs in our code.
We have also found that this attitude of "subsetting" can help you or a
colleague realise the problem. An interesting new way of debugging "difficult"
problems. "Subsetting" is becoming almost an art with us.
Our field is electrical HV transmission and associated
transients/dynamics/harmonics. We need to eradicate all "bugs", ours or
vendors, to declare our planning engineers' analyses electrically and
environmentally safe and economic.
The team that I work with believes any time spent in resolving a bug a necessary
evil. We have found problems with our vendors compiler (luckily in field test
time -- ooh a minor one out of -- but still one), the Nag library that we use
extensively (two) and MATLAB (one in Simulink). All of which we subset the
problem -- might take two of us an hour -- but they are all resolved by our
vendors. As compilers get smarter, we are also finding problems and dubious
practices in our own code, some of which dates back to the '70s.
Unlike your comment in your last para., once we are aware of a bug we will throw
the whole team at it if necessary to resolve vendor or us. At the end of the
day, we feel happier about our code, and obviously the results that our planning
engineers will use.
Regards, Paddy
Paddy O'Brien,
System Planning,
TransGrid,
PO Box A1000, Sydney South,
NSW 2000, Australia
Tel: +61 2 9284-3063
Fax: +61 2 9284-3050
Email: [log in to unmask]
Either "\'" or "\s" (to escape the apostrophe) seems to work for most people,
but that little whizz-bang apostrophe gives me little spam.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|