Re: [www-patch] bugs.html rewrite, part 1: factor out non-bugs section

[Wolfgang Bangerth <bangerth at ices dot utexas dot edu>]

> The first patch (see below) addresses (b), i.e. it factors out the non-bugs

Thanks for doing this! I'd like to have the following points addressed, if 
possible (some of the were already in the original, but they could be fixed 
while you are at it already):

> +In particular, bugs caused by invalid code have a simple work-around:
> +<em>fix the code</em>.</p>

I find the emphasis offensive. This may be rewritten as "In particular, the 
best work-around for invalid code is to make it standard conforming."


>+<p>GCC 3.0 had a new ABI, which affected class layout, function mangling and
> +calling conventions. We had intended it to be complete, but unfortunately
> +some issues came to light, too late to fix in the 3.0 series.
> +The ABI should not change in dot releases, so we addressed most issues
> +in GCC 3.1.</p>

And in 3.2, and we may do it again in 3.4. This is in the "Frequently reported 
bugs section, and the first in the list. Frankly, we don't get so many ABI 
bugs (and if we do from really skilled people looking out for weird 
inconsistencies). This section also doesn't say what exactly it is that is 
the bug, so it's of not much use. I recommend dropping the entire section.


> +<dt>Covariant return types</dt>
> +
> +<dd>Up to (and including) GCC 3.3 we did not implement non-trivial
> +covariant returns.  This has been addressed for GCC 3.4.</dd>

But as far as I understood Nathan, they are still not implemented for variadic 
functions. This should be clarified then.


> +<dt>Two stage lookup in templates is not implemented.</dt>
> +<dd><p>[14.6] specifies how names are looked up inside a template. G++
> +does not do this correctly, but for most templates this will not be
> +noticeable.</p></dd>

That's not true any more. Mainline is pretty good in this respect.


> +<p>Up to and including GCC 3.0, the compiler will give "parse error" for
> +seemingly simple code, such as</p>

That's a lengthy section, and we don't get many PRs any more for these old 
compilers. I'm for dropping those parts of the section that really apply to 
anything pre-3.2. If someone sends in code like this it's not a lot of work 
for us to close the PR, but it saves potential submitters quite some time if 
the section went away.


> +<p>Programming languages themselves change.  Earlier versions of GCC
> +might have accepted source code that is <em>no longer</em> valid.
> +This means that code which might have "worked" in a previous version,
> +is now rejected.  You should update your code to match recent language
> +standards (this holds especially for C++).</p>

Usually, it's not the language standard that makes something illegal, but that 
either there was no standard before (C++), or that we defined our own 
language (via extensions) and are now moving away from it. Maybe this could 
be made clearer. We shoot ourselves in the foot if we say on the one hand 
"language standards are changing constantly in incompatible ways" and on the 
other hand drop extensions with the argument that we want to move closer to 
standards.


> +<dt>Problems with floating point computations.</dt>

We could have a link to our favorite PR 323 in this section.


About the upgrade 2.95->3.0 thing: replace it by 3.x instead, or by "3.0 and 
later". The problems are the same in any case.

Thanks for the work
  W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/