Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!udel!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: This one bit me today
Message-ID: <11348@smoke.BRL.MIL>
Date: 20 Oct 89 13:07:31 GMT
References: <2432@hub.UUCP> <568@sppy00.UUCP> <750@philmtl.philips.ca> <4147@ncsuvx.ncsu.edu> <267@wsl.UUCP> <244@bbxsda.UUCP> <1901@xyzzy.UUCP> <255@bbxsda.UUCP> <1949@xyzzy.UUCP> <273@bbxsda.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 23

In article <273@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>I don't get it.  Are you saying that a C compiler that allows the option
>of nested comments is *broken*?  I believe Turbo C has a nested comments
>option.  I agree that a compiler that insists on nesting comments is
>probably non-conforming (I say "probably" because I can't recite the
>actual ANSI text at this moment).  But what's wrong with command line
>options that allow various enhancements?

C does not now, and never has, permitted nested /*...*/ comments.
A compiler when it does treat /*...*/ comments as nesting (however
the compiler is invoked) is not processing the C programming language.
If it is advertised as a C compiler in that mode, then yes it is broken.

What is wrong with this "enhancement" is that it is not a transparent
extension.  It encourages writing code that looks like C but performs
differently from the way C code would.  When ported to a genuine C
environment, its operation can change, perhaps silently getting wrong
answers when compiled by a true C compiler.

Vendor extensions to C should be clearly identifiable, so that it is
easy to determine if an application is relying on them, and they should
be designed to cause diagnostics when code using them is compiled in an
environment that does not support the extensions.