Re: [PATCH 10/10] tests: Add C++ test binary.

[Roland McGrath <roland at hack dot frob dot com>]

In addition to my previous remarks about the names of things and not
duplicating the self-binaries list:

Say "C++" in a comment, not "c++".  

A sentence in a comment should end with a period and be grammatically
correct English ("might" doesn't appear without a subject).

Use full GNU style everywhere in cpp-various.cxx: return type on separate
line before function name, etc.

Might as well say "C++11" in comments, even if we use -std=c++0x for the
older compilers.

We used .cc in the dwarf branch, didn't we?
So use that, not .cxx.

Call it cxx-various rather than cpp-various (cpp often reads as cpp, the
preprocessor, whereas cxx always reads as C++, the language).

For each construct, add a comment saying what C++ construct it is
exercising and what DWARF features we expect that to generate.

It's fine to have the test in source form so that we can test future
compilers.  But we also want reliable, constant test data.  So build it
with all the compiler versions you have handy and add testdata files for
each of those.  (You can elide any that are not interestingly different
from the others.)

To keep life simple once we do that, that file should not have a normal
GPLv3 copyright notice.  Either make it just public domain, or copyright
with trivial terms like configure files (autoconf output) have.  That way
we don't complicate anyone's life as the source changes over time but we
and redistributors keep the old testdata binaries made from previous
versions that we will no longer be distributing.

Unless there is a problem with this, just compile it and don't link it;
test the tools on a .o file.  That way we are testing just what we
explicitly intend to, rather than whatever is brought in from libstdc++
headers or whatever.  Definitely do that for the canned testdata files.
For the test built from source, you could test both the .o and the linked
binary, so as to catch in self-test any new corner cases from future
libstdc++ and whatnot, but clearly distinguish in the test results what's
from just the compiler and what's from things that got linked in.


Thanks,
Roland