🚀 go-pugleaf

In article <1992Aug19.234812.11723@unix.brighton.ac.uk> amn@vms.brighton.ac.uk writes:
>people mentioned the Plum Hall validation suite  -  this is not of interest to
>me.  PH may well be a useful test, but it only checks that a compiler accepts
>the PH files & gives an output that runs correctly.  This seems to be a
>drastically inadequate test for std compliance,

From reading your report, I personally make the same judgement that you made.
However, that doesn't affect whether it might be valuable or not.  After all,
on a car, it's nice to have more than one braking system, and seat belts
besides, even though all of these together won't make a car go.

>my understanding is that:
>1   It is only applicable to compilers that include a complete ANSI library,
>    often not the case when targetting embedded systems, ...

I'll believe you, but this makes me curious.  If you're testing a standalone
implementation (no library) how can the test report success/failure?

>2   It does not check that system constants (#define's) and function prototypes
>    are in the correct header files, ...
>3   It does not ensure that the compiler defaults to ANSI compliant mode, with
>    language extensions being available only as an option.

3 would not be a good test.  There is no reason for a compiler to default to
ANSI compliant mode.  You should read the vendor's manual, do what they say
to invoke an ANSI compliant implementation, and see if the test suite tells
you that you didn't get one.

>4   It does not prevent tampering with the input (PH) files to get the desired
>    output.

4 doesn't make much sense to me.  Do other test suites come with the source
files encrypted and the encryption key hidden somewhere so that it takes
cracking-like techniques to tamper with the source files?

>5   It does not reject compilers that accept invalid operations or illegal
>    syntax.
>6   It does not test typesafe linkage, where implemented :-)

A test of typesafe linkage (other testing whether violations of Constraints
sections get diagnosed) would not be a test of ANSI compliance.

(Of course, I understand your smiley too.  No one's expecting other vendors
to catch up to Intel's 1978 linking technology, at least not in this century.
I wish I could put a smiley on this.  Anyway it's irrelevant to this topic.)

>7   ... other tests requiring impartial checking of compile or link errors, or
>    inspection of development specification.

Huh?

>In my very humble opinion, claiming PH compliance for a compiler is like
>saying a container is decorated with lead free paint,

Maybe the other way around.  Maybe PH tells you that the container was able
to hold ferric chloride, though you need other test suites to tell you that
the container has a tight seal.
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."