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

[Volker Reichelt]

On 14 Aug, Wolfgang Bangerth wrote:
> 
>> 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):

I just wanted to do the sorting in my first patch and tackle the points
that you want to address in follow-up patches (in order to only make
incremental changes). So I don't think this will go into the first
patch.

But thanks for pointing those flaws out - they'll soon be addressed!

>> +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."

Seems reasonable.

>>+<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.

I'm unsure about that one. I'd rather keep it until things have settled
down.

>> +<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.

Gerald already contacted Nathan. He'll have a look into the stuff.

>> +<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.

That's on my TODO list already. Mainline still has flaws, though.

>> +<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.

I haven't looked into this section, but it's way too complicated IMHO.
I'll look into it soon to see, which paragraphs still apply and which
can be disposed of.

>> +<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.

Yup.

I also wanted to add a small example which focuses on the effects
of storing a value to memory (there *seems* to be no computation, but
the value changes anyway) and not on the rounding in the computation
itself.

> 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.

That section deserves a patch for its own I think.

> Thanks for the work
>   W.

Regards,
Volker