Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > lcc-win32 conformance question

Reply
Thread Tools

lcc-win32 conformance question

 
 
Ben Bacarisse
Guest
Posts: n/a
 
      04-27-2008
Chris Torek <(E-Mail Removed)> writes:

> In article <(E-Mail Removed)>
> <(E-Mail Removed)> wrote:

<on the correctness of gcc silently accepting:>

>>__attribute__((unused)) static int a;
>>
>>Is this unnamed compiler non-conforming?

>
> Not from this example. The reason is that names prefixed with
> various kinds of underscores (including single underscores followed
> by uppercase, and double underscores) are reserved to the
> implementation, and once you use an "implementation keyword", the
> entire "contract", as it were, that the Standard provides to the
> C programmer is terminated, at least in principle.


That is an interesting (and new to me) viewpoint. It means that the
standard does require that a conforming implementation should be able
to be told to reject all extensions. Obviously an implementation may
offer this help, but I can't be sure that turning on all the standards
flags will do it.

Allowing all bets to be off after a #pragma is not so worrying to me --
I can grep for those. I can't search for examples of __?words that are
not "standard" with anything like the same ease.

--
Ben.
 
Reply With Quote
 
 
 
 
Chris Torek
Guest
Posts: n/a
 
      04-27-2008
>Chris Torek <(E-Mail Removed)> writes:
>> ... once you use an "implementation keyword", the
>> entire "contract", as it were, that the Standard provides to the
>> C programmer is terminated, at least in principle.


(Incidentally, I am not sure whether one can at least expect
the file *up to that point* to respect C syntax.)

In article <(E-Mail Removed)>,
Ben Bacarisse <(E-Mail Removed)> wrote:
>That is an interesting (and new to me) viewpoint. It means that the
>standard does require that a conforming implementation should be able
>to be told to reject all extensions. Obviously an implementation may
>offer this help, but I can't be sure that turning on all the standards
>flags will do it.
>
>Allowing all bets to be off after a #pragma is not so worrying to me --
>I can grep for those. I can't search for examples of __?words that are
>not "standard" with anything like the same ease.


Indeed. However, it is worse (and yet better) than that. Consider,
for instance, the following:

#include "my.h"

This *looks* inocuous enough, until we find that my.h starts with:

#include <system-magic.h>

which, through a chain of 97812 other "#include"s, eventually does:

#pragma lisp

so everything after including "my.h" is Lisp!

This problem never actually occurs in practice, because people are
not quite that crazy.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
 
Reply With Quote
 
 
 
 
ymuntyan@gmail.com
Guest
Posts: n/a
 
      04-27-2008
On Apr 26, 8:31 pm, Chris Torek <(E-Mail Removed)> wrote:
> In article <(E-Mail Removed)> <(E-Mail Removed)> wrote:
> >Actually what I wanted was the reference to the standard,
> >and I found it (surprisingly, it's where "diagnostic"is
> >defined). I have always thought that syntax extensions are
> >allowed, that's why I insisted on "why?". E.g. I was sure
> >that gcc doesn't have to warn about __attribute__ even in
> >conforming mode. Now I have a question about conformance
> >of one unnamed compiler [which does not complain about a

>
> translation unit consisting entirely of the one line]
>
> >__attribute__((unused)) static int a;

>
> >Is this unnamed compiler non-conforming?

>
> Not from this example. The reason is that names prefixed with
> various kinds of underscores (including single underscores followed
> by uppercase, and double underscores) are reserved to the
> implementation, and once you use an "implementation keyword", the
> entire "contract", as it were, that the Standard provides to the
> C programmer is terminated, at least in principle.
>
> Thus, the following does not require a diagnostic:
>
> #pragma comment !
> ! hi there.
> static int a;
>
> because "#pragma" can also do pretty much anything (although in
> C99 there are now standardized #pragma operations). (Perhaps, as
> in this case, the "#pragma" turns "!" into a comment-to-end-of-line
> character. "#pragma fortran" might be used to switch to Fortran
> code, which would change the syntax even more.)
>
> This is, of course, the danger of doing anything that departs from
> Standard C: the moment you abandon the standard, even for an instant,
> the standard can abandon you, possibly "forever".


I believe I understand what you're saying, yet I don't
quite understand where that fine line between "syntax
error" and "not a syntax error" is drawn. Namely, why
is // a deviation from the C syntax which must be diagnosed,
while __attribute__ isn't? Or why __attribute__ is fine
while 234i literal isn't?

So, the question is: where exactly does the standard say
that implementation is free to use any __-prefixed identifier
as a magic word which may completely change semantics of the
program? It does say that such identifiers are reserved,
yet they still are identifiers.

Yevgen
 
Reply With Quote
 
ymuntyan@gmail.com
Guest
Posts: n/a
 
      04-27-2008
On Apr 27, 12:09 am, Richard Heathfield <(E-Mail Removed)> wrote:
> (E-Mail Removed) said:
>
> <snip>
>
> > Jacob certainly should not overreact, he harms himself with
> > that. But you should admit that all the posters assumed
> > that the given issue is a non-conformance bug, yet nobody
> > said why it is so.

>
> Are you claiming that failure to issue a required diagnostic message for a
> syntax error is somehow not a conformance problem?


No, and I have not claimed that. I didn't know that diagnostic
was required in that case, that's true. Yet I didn't even claim
it wasn't required.

Yevgen
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-27-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> On Apr 26, 8:31 pm, Chris Torek <(E-Mail Removed)> wrote:
>>
>> because "#pragma" can also do pretty much anything (although in
>> C99 there are now standardized #pragma operations). (Perhaps, as
>> in this case, the "#pragma" turns "!" into a comment-to-end-of-line
>> character. "#pragma fortran" might be used to switch to Fortran
>> code, which would change the syntax even more.)
>>
>> This is, of course, the danger of doing anything that departs from
>> Standard C: the moment you abandon the standard, even for an instant,
>> the standard can abandon you, possibly "forever".

>
> I believe I understand what you're saying, yet I don't
> quite understand where that fine line between "syntax
> error" and "not a syntax error" is drawn. Namely, why
> is // a deviation from the C syntax which must be diagnosed,
> while __attribute__ isn't? Or why __attribute__ is fine
> while 234i literal isn't?
>

__attribute__ is in the implementation's namespace, so the
implementation is free to treat it how is sees fit. 234i is not.

> So, the question is: where exactly does the standard say
> that implementation is free to use any __-prefixed identifier
> as a magic word which may completely change semantics of the
> program? It does say that such identifiers are reserved,
> yet they still are identifiers.
>

Reserved, for the implementation. So it can do what it likes with them.

--
Ian Collins.
 
Reply With Quote
 
ymuntyan@gmail.com
Guest
Posts: n/a
 
      04-27-2008
On Apr 27, 12:38 am, Ian Collins <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
> > On Apr 26, 8:31 pm, Chris Torek <(E-Mail Removed)> wrote:

>
> >> because "#pragma" can also do pretty much anything (although in
> >> C99 there are now standardized #pragma operations). (Perhaps, as
> >> in this case, the "#pragma" turns "!" into a comment-to-end-of-line
> >> character. "#pragma fortran" might be used to switch to Fortran
> >> code, which would change the syntax even more.)

>
> >> This is, of course, the danger of doing anything that departs from
> >> Standard C: the moment you abandon the standard, even for an instant,
> >> the standard can abandon you, possibly "forever".

>
> > I believe I understand what you're saying, yet I don't
> > quite understand where that fine line between "syntax
> > error" and "not a syntax error" is drawn. Namely, why
> > is // a deviation from the C syntax which must be diagnosed,
> > while __attribute__ isn't? Or why __attribute__ is fine
> > while 234i literal isn't?

>
> __attribute__ is in the implementation's namespace, so the
> implementation is free to treat it how is sees fit. 234i is not.


"namespace" here is not the standard term, so if you
mean "it's magic", then I already got that
So, 234i is not C, "int __attribute__((something)) something;"
isn't C either, both are invalid according to the grammar.
The former is not magical, the latter is. Does "reserved" really
clearly imply this magic/not-magic distinction? I do think
it's a good rule, "__ => anything may happen", but it doesn't
seem to be what standard really say, or is it?

> > So, the question is: where exactly does the standard say
> > that implementation is free to use any __-prefixed identifier
> > as a magic word which may completely change semantics of the
> > program? It does say that such identifiers are reserved,
> > yet they still are identifiers.

>
> Reserved, for the implementation. So it can do what it likes with them.


Yevgen
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      04-27-2008
Ben Bacarisse wrote:
>
> Do you mean lcc-win32? If so, I have found problems with compound
> literals, VLA parameters, complex numbers and designated initialisers
> so some of the C99 parts are a bit rough round the edges. There have
> been a few other reports of conformance issues, but they may well have
> been fixed. For example, it used to consider long * and int * to be
> compatible types.
>
> It is probably fair to say the standards conformance is not a top
> priority for that compiler.
>


All the bugs you mentioned were fixed as quickly as I could.

That is not, of course, TOP PRIORITY. Some bugs were
fixed in less than a few hours. But that is NOT TOP PRIORITY.

What, then, would be TOP PRIORITY?

A few seconds?


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      04-27-2008
Richard Heathfield wrote, On 27/04/08 07:13:
> (E-Mail Removed) said:
>
>> On Apr 27, 12:09 am, Richard Heathfield <(E-Mail Removed)> wrote:
>>> (E-Mail Removed) said:
>>>
>>> <snip>
>>>
>>>> Jacob certainly should not overreact, he harms himself with
>>>> that. But you should admit that all the posters assumed
>>>> that the given issue is a non-conformance bug, yet nobody
>>>> said why it is so.
>>> Are you claiming that failure to issue a required diagnostic message for
>>> a syntax error is somehow not a conformance problem?

>> No, and I have not claimed that. I didn't know that diagnostic
>> was required in that case, that's true.

>
> Thank you for explaining this. I was under the impression that you knew.
>
>> Yet I didn't even claim it wasn't required.

>
> No, you didn't claim that. I didn't realise you didn't know the situation
> pertaining to the diagnostic obligations of conforming implementations.
> Now that I do realise this, I can answer your above point more
> pertinently:
>
> I would guess that all the posters who knew that the given issue is to do
> with non-conformance (and why) assumed that everyone else in the
> discussion also knew that it was to do with non-conformance (and why).
>
> And *that* assumption (i.e. the assumption that everyone else knew) now
> appears to be ill-founded.
>
> So: to clarify, the appearance of a // in a C90 program is either:
>
> (a) part of a string literal " like // this "; or
> (b) part of a comment /* like // this */; or
> (c) a division followed immediately by a comment like//*this*/that; or
> (d) a syntax error.
>
> I think that covers all the possibilities.


You missed multi-byite character constants like this '//'

> As you can see, it isn't *necessarily* a syntax error - but that is the
> most likely of the four possibilities when someone has been using // for
> comment syntax without malice aforethought. And syntax errors *must* be
> diagnosed; the Standard requires it. So if a compiler finds a // that it
> can't twist into some syntactically legitimate interpretation (e.g. (a)
> through (c) above), it must issue a diagnostic message.


The example given, of course, clearly did not fit in to any of the
legitimate interpretations.
--
Flash Gordon
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      04-27-2008
(E-Mail Removed) wrote, On 27/04/08 07:07:
> On Apr 27, 12:38 am, Ian Collins <(E-Mail Removed)> wrote:
>> (E-Mail Removed) wrote:
>>> On Apr 26, 8:31 pm, Chris Torek <(E-Mail Removed)> wrote:
>>>> because "#pragma" can also do pretty much anything (although in
>>>> C99 there are now standardized #pragma operations). (Perhaps, as
>>>> in this case, the "#pragma" turns "!" into a comment-to-end-of-line
>>>> character. "#pragma fortran" might be used to switch to Fortran
>>>> code, which would change the syntax even more.)
>>>> This is, of course, the danger of doing anything that departs from
>>>> Standard C: the moment you abandon the standard, even for an instant,
>>>> the standard can abandon you, possibly "forever".
>>> I believe I understand what you're saying, yet I don't
>>> quite understand where that fine line between "syntax
>>> error" and "not a syntax error" is drawn. Namely, why
>>> is // a deviation from the C syntax which must be diagnosed,
>>> while __attribute__ isn't? Or why __attribute__ is fine
>>> while 234i literal isn't?

>> __attribute__ is in the implementation's namespace, so the
>> implementation is free to treat it how is sees fit. 234i is not.

>
> "namespace" here is not the standard term, so if you
> mean "it's magic", then I already got that


"namespace" is not a standard term, but "name spaces" is a standard term,

> So, 234i is not C, "int __attribute__((something)) something;"
> isn't C either, both are invalid according to the grammar.


Not necessarily. Consider the following TU which uses the same syntax:

#define attribute(a)
int attribute((something)) something;

So whether it is valid according to the grammar depends on the
definition of __attribute__. Note that the implementation is
specifically allowed to have predefined macros starting with a double
underscore. Note also that predefined macros are not subject to
#undef/#define according to the standard.

> The former is not magical, the latter is. Does "reserved" really
> clearly imply this magic/not-magic distinction? I do think
> it's a good rule, "__ => anything may happen", but it doesn't
> seem to be what standard really say, or is it?


<snip>

It is an interesting point. Conforming implementations are explicitly
allowed to have extensions provided they do not affect the behaviour of
any strictly conforming program, and no strictly conforming program can
use identifiers starting with __ except where they are explicitly
defined by the standard.
--
Flash Gordon
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      04-27-2008
In article <(E-Mail Removed)>
<(E-Mail Removed)> wrote:
>So, 234i is not C, "int __attribute__((something)) something;"
>isn't C either, both are invalid according to the grammar.
>The former is not magical, the latter is. Does "reserved" really
>clearly imply this magic/not-magic distinction?


It is not the "reserved" per se, but rather the fact that use
of a reserved identifer results in undefined behavior.

In my C99 draft, this is in section 7.1.3, "Reserved identifiers",
where we have the following text:

...
- All identifiers that begin with an underscore and
either an uppercase letter or another underscore are
always reserved for any use.
...
[#2] No other identifiers are reserved. If the program
declares or defines an identifier that is reserved in that
context (other than as allowed by 7.1., the behavior is
undefined.134

(Note that you must add more C99 text before interpreting the above
too literally, since (e.g.) __func__ fits this pattern, but has
Standard-defined semantics, so a C programmer can use __func__ in
the Standard-defined way without losing all of the other C99
guarantees.)

(Note also that the text above says "declares or defines", so one
might attempt to call gcc non-conformant at this point, since "int
__attribute__" is not yet a complete definition: we would have to
see a semicolon, comma, or equal-sign-and-expression in order to
get the definition to happen. Perhaps simpler, we could point to
gcc's __extension__, which gcc allows to appear in a context that
does not even *resemble* a declaration or definition. I would
argue, though, that the draft wording I quoted above fails to
capture the "true intent" of the Standard, which allows the compiler
to "pre-define" any reserved identifier. Perhaps, for instance,
the preprocessor starts out by doing "#define __extension__" in
such a way that the occurrence of __extension__ declares a second
reserved identifier, thus triggering the undefined behavior. [This
is not in fact what gcc does, but we cannot observe this fact with
any strictly conforming code -- even "#ifdef __extension__" is not
sufficient, since gcc *could* #define __extension__ only on those
source lines where there are no "#ifdef" tests for it -- so from
a black-box point of view, at least, gcc can get away with this.])

(If the goal is to find "gcc bugs", it is simpler to find "real"
failures in gcc's conformance, in which compiling with -std=c99
fails to implement C99 in various ways. There may well be various
conformance bugs with -std=c89 aka -ansi as well. And of course
gcc obviously fails to conform with "-ansi" unless one *also*
includes "-pedantic", since "-ansi", by design, does not turn on
all the required diagnostics. But this little aside is not relevant
to my rela point, which is: compilers are allowed, and even
encouraged, to use Standard C's "undefined behavior" in various
well-controlled, documented-in-the-implementation-manual ways to
provide features that are otherwise missing from Standard C, so
that real programmers can get real work done.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
W3C complience checker and conformance EN HTML 45 05-04-2006 11:40 PM
c library conformance testing cenan.ozen@gmail.com C Programming 0 12-01-2005 07:20 PM
Is there any new C++ compiler standard conformance test result? Tao Wang C++ 7 11-07-2005 02:24 PM
[Maybe OT] How to convince people about the importance of ANSI standards conformance ? Amarendra GODBOLE C Programming 25 01-21-2004 01:46 PM
Triple-A conformance? T.J. HTML 20 12-16-2003 08:37 AM



Advertisments