Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #9209 > unrolled thread

lcc-win

Back to article view | Back to comp.lang.c

Contents

  lcc-win jacob navia <jacob@spamsink.net> - 2011-08-11 15:14 +0200
    Re: lcc-win tom st denis <tom@iahu.ca> - 2011-08-11 07:51 -0700
      Re: lcc-win James Kuyper <jameskuyper@verizon.net> - 2011-08-11 11:23 -0400
        Re: lcc-win tom st denis <tom@iahu.ca> - 2011-08-11 08:35 -0700
          Re: lcc-win James Kuyper <jameskuyper@verizon.net> - 2011-08-11 12:28 -0400
            Re: lcc-win Keith Thompson <kst-u@mib.org> - 2011-08-11 11:46 -0700
              Re: lcc-win tom st denis <tom@iahu.ca> - 2011-08-12 10:20 -0700
                Re: lcc-win James Kuyper <jameskuyper@verizon.net> - 2011-08-12 14:00 -0400
                  Re: lcc-win tom st denis <tom@iahu.ca> - 2011-08-12 11:23 -0700
                    Re: lcc-win blp@cs.stanford.edu (Ben Pfaff) - 2011-08-12 11:36 -0700
                      Re: lcc-win tom st denis <tom@iahu.ca> - 2011-08-12 11:42 -0700
                        Re: lcc-win Ben Pfaff <blp@cs.stanford.edu> - 2011-08-12 11:52 -0700
                    Re: lcc-win jacob navia <jacob@spamsink.net> - 2011-08-12 20:37 +0200
      Re: lcc-win jacob navia <jacob@spamsink.net> - 2011-08-11 19:45 +0200
        Re: lcc-win Ralf Damaschke <rwspam@gmx.de> - 2011-08-11 20:12 +0000
          Re: lcc-win jacob navia <jacob@spamsink.net> - 2011-08-11 22:43 +0200
          Re: lcc-win Keith Thompson <kst-u@mib.org> - 2011-08-11 13:43 -0700
          Re: lcc-win Ian Collins <ian-news@hotmail.com> - 2011-08-12 08:50 +1200
      Re: lcc-win gordonb.04sy5@burditt.org (Gordon Burditt) - 2011-08-12 19:54 -0500

#9209 — lcc-win

The lcc-win compiler is a C99 compiler for windows systems. It can be
downloaded at no cost from

http://www.cs.virginia.edu/~lcc-win32/

It is an experimental system, with several extensions to the C language
like operator overloading, exception handling, and others.

jacob

[toc] | [next] | [standalone]

#9214

On Aug 11, 9:14 am, jacob navia <ja...@spamsink.net> wrote:
> The lcc-win compiler is a C99 compiler for windows systems. It can be
...
> It is an experimental system, with several extensions to the C language

These statements are incompatible.

:-)

I'd instead say "it's a C99 compiler which can also be used in non-
standard ways."  If the compiler accepts non-C99 syntax it's not a C99
compiler, so the non-standard options would be to be enabled through a
mode-switch to be a "c99 compiler."

e.g.

lcc /myhacks /c myfile.c /o myfile.obj

or whatever...

[toc] | [prev] | [next] | [standalone]

#9216

On 08/11/2011 10:51 AM, tom st denis wrote:
> On Aug 11, 9:14 am, jacob navia <ja...@spamsink.net> wrote:
>> The lcc-win compiler is a C99 compiler for windows systems. It can be
> ...
>> It is an experimental system, with several extensions to the C language
> 
> These statements are incompatible.

Not true; a fully conforming implementation of C99 can provide it's own
definition of the behavior of a program whenever it contains specific
features that render it's behavior undefined by the C99 standard.
Extensions implemented by making use of that fact do not interfere with
conformance. Example: extensions that occur only when your code uses a
identifier that is, in it's context, reserved to the implementation,
such as __aligned. A #pragma statement (or _Pragma() expression) is
another mechanism that a fully conforming implementation of C can use to
turn an extension on or off.

These same mechanisms could also be used to trigger extensions which
give the user control over behavior that is unspecified by the C
standard, without rendering the implementation non-conforming.

Somewhat more obtrusive, but still fully conforming, would be an
extension that gives meaning to code that constitutes a syntax error or
a constraint violation. A fully conforming implementation of C can
accept such code, so long as it generates a corresponding diagnostic,
such as "Congratulations on using our forma-link extension! We hope you
enjoy using it.".

[toc] | [prev] | [next] | [standalone]

#9218

On Aug 11, 11:23 am, James Kuyper <jameskuy...@verizon.net> wrote:
> On 08/11/2011 10:51 AM, tom st denis wrote:
>
> > On Aug 11, 9:14 am, jacob navia <ja...@spamsink.net> wrote:
> >> The lcc-win compiler is a C99 compiler for windows systems. It can be
> > ...
> >> It is an experimental system, with several extensions to the C language
>
> > These statements are incompatible.
>
> Not true; a fully conforming implementation of C99 can provide it's own
> definition of the behavior of a program whenever it contains specific
> features that render it's behavior undefined by the C99 standard.
> Extensions implemented by making use of that fact do not interfere with
> conformance. Example: extensions that occur only when your code uses a
> identifier that is, in it's context, reserved to the implementation,
> such as __aligned. A #pragma statement (or _Pragma() expression) is
> another mechanism that a fully conforming implementation of C can use to
> turn an extension on or off.
>
> These same mechanisms could also be used to trigger extensions which
> give the user control over behavior that is unspecified by the C
> standard, without rendering the implementation non-conforming.
>
> Somewhat more obtrusive, but still fully conforming, would be an
> extension that gives meaning to code that constitutes a syntax error or
> a constraint violation. A fully conforming implementation of C can
> accept such code, so long as it generates a corresponding diagnostic,
> such as "Congratulations on using our forma-link extension! We hope you
> enjoy using it.".

ya but if I write code like

return main(void) { int 0; }

That's clearly totally bogus C99 syntax but his compiler might [I know
it doesn't I'm just making up an example] say "hey that's cool, I got
this!"

If the C99 specifies "implementation defined" syntax e.g. #pragma then
it's not a C99 syntax violation it's just not portable.

However, if he used #prada instead that's not defined [as
implementation or otherwise] and should result in an error.

Tom

[toc] | [prev] | [next] | [standalone]

#9219

On 08/11/2011 11:35 AM, tom st denis wrote:
> On Aug 11, 11:23 am, James Kuyper <jameskuy...@verizon.net> wrote:
>> On 08/11/2011 10:51 AM, tom st denis wrote:
>>
>>> On Aug 11, 9:14 am, jacob navia <ja...@spamsink.net> wrote:
>>>> The lcc-win compiler is a C99 compiler for windows systems. It can be
>>> ...
>>>> It is an experimental system, with several extensions to the C language
>>
>>> These statements are incompatible.
>>
>> Not true; a fully conforming implementation of C99 can provide it's own
>> definition of the behavior of a program whenever it contains specific
>> features that render it's behavior undefined by the C99 standard.
>> Extensions implemented by making use of that fact do not interfere with
>> conformance. Example: extensions that occur only when your code uses a
>> identifier that is, in it's context, reserved to the implementation,
>> such as __aligned. A #pragma statement (or _Pragma() expression) is
>> another mechanism that a fully conforming implementation of C can use to
>> turn an extension on or off.
>>
>> These same mechanisms could also be used to trigger extensions which
>> give the user control over behavior that is unspecified by the C
>> standard, without rendering the implementation non-conforming.
>>
>> Somewhat more obtrusive, but still fully conforming, would be an
>> extension that gives meaning to code that constitutes a syntax error or
>> a constraint violation. A fully conforming implementation of C can
>> accept such code, so long as it generates a corresponding diagnostic,
>> such as "Congratulations on using our forma-link extension! We hope you
>> enjoy using it.".
> 
> ya but if I write code like
> 
> return main(void) { int 0; }
> 
> That's clearly totally bogus C99 syntax but his compiler might [I know
> it doesn't I'm just making up an example] say "hey that's cool, I got
> this!"

The only thing that the C standard requires of a fully conforming
implementation of C when the source code contains a syntax error is a
diagnostic message. Whatever else the implementation chooses to do after
issuing the diagnostic message has no impact on whether or not it
conforms to the C standard.

There only needs to be one such diagnostic, no matter how many different
syntax errors or constraint violations the code contains. The message
doesn't have to say where the syntax error occurred. The message doesn't
have to say anything useful at all. It doesn't even have to be in any
known language. About the only restrictions imposed by the standard on
the contents of a diagnostic is that diagnostics must be identifiable as
such, and the way they can be so identified must be explained in the
documentation for that implementation.

> If the C99 specifies "implementation defined" syntax e.g. #pragma then
> it's not a C99 syntax violation it's just not portable.

True, any code which relies upon the use of extensions is not portable
to any compiler which fails to support those extensions. That's not
exactly big news. But accepting non-portable code is the norm, not the
exception, with C compilers. It does not, in itself, prevent them from
being fully conforming compilers - not even when working in the mode
where they accept such code.

> However, if he used #prada instead that's not defined [as
> implementation or otherwise] and should result in an error.

A line starting with "#prada" is one example of what the C standard
calls a non-directive (6.10p1). As pointed out in footnote 150, despite
the name, non-directives count as preprocessing directives, as far as
parsing C code is concerned. Therefore, so long as a non-directive does
not begin with one of the standard preprocessing directive names
(6.10p3), it is not a syntax error for a C program to contain one.

There's one, and only one, feature that a program can possess that
prohibits a conforming implementation of C from accepting the program: a
#error directive that survives conditional compilation (4p4). A #prada
non-directive doesn't qualify.

[toc] | [prev] | [next] | [standalone]

#9224

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> The only thing that the C standard requires of a fully conforming
> implementation of C when the source code contains a syntax error is a
> diagnostic message. Whatever else the implementation chooses to do after
> issuing the diagnostic message has no impact on whether or not it
> conforms to the C standard.
>
> There only needs to be one such diagnostic, no matter how many different
> syntax errors or constraint violations the code contains. The message
> doesn't have to say where the syntax error occurred. The message doesn't
> have to say anything useful at all. It doesn't even have to be in any
> known language. About the only restrictions imposed by the standard on
> the contents of a diagnostic is that diagnostics must be identifiable as
> such, and the way they can be so identified must be explained in the
> documentation for that implementation.
[...]

And there's no requirement that diagnostics required by the language
(those for syntax errors and constraint violations) be distinguishable
from any additional diagnostics that the standard might choose to emit.

So in principle, a compiler that issues a single warning for every
translation unit (and handles #error correctly) would satisfy the
standard's requirements for diagnostics.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#9270

On Aug 11, 2:46 pm, Keith Thompson <ks...@mib.org> wrote:
> James Kuyper <jameskuy...@verizon.net> writes:
>
> [...]> The only thing that the C standard requires of a fully conforming
> > implementation of C when the source code contains a syntax error is a
> > diagnostic message. Whatever else the implementation chooses to do after
> > issuing the diagnostic message has no impact on whether or not it
> > conforms to the C standard.
>
> > There only needs to be one such diagnostic, no matter how many different
> > syntax errors or constraint violations the code contains. The message
> > doesn't have to say where the syntax error occurred. The message doesn't
> > have to say anything useful at all. It doesn't even have to be in any
> > known language. About the only restrictions imposed by the standard on
> > the contents of a diagnostic is that diagnostics must be identifiable as
> > such, and the way they can be so identified must be explained in the
> > documentation for that implementation.
>
> [...]
>
> And there's no requirement that diagnostics required by the language
> (those for syntax errors and constraint violations) be distinguishable
> from any additional diagnostics that the standard might choose to emit.
>
> So in principle, a compiler that issues a single warning for every
> translation unit (and handles #error correctly) would satisfy the
> standard's requirements for diagnostics.

Maybe Jacob could add an experimental mode in which errors/warnings
were more standardized and helpful than that as required by the ISO C
spec... :-)

Tom

[toc] | [prev] | [next] | [standalone]

#9272

On 08/12/2011 01:20 PM, tom st denis wrote:
...
> Maybe Jacob could add an experimental mode in which errors/warnings
> were more standardized and helpful than that as required by the ISO C
> spec... :-)

I would hope that, like most real-world compilers, lcc-win32 already
does so in default mode. It would be pretty difficult to generate
diagnostics that are less standardized or less helpful than required by
the C standard. I'm not sure it's possible to provide diagnostics that
are less helpful than required by the C standard, since the standard
imposes no limits on how un-helpful a diagnostic could be.

[toc] | [prev] | [next] | [standalone]

#9273

On Aug 12, 2:00 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 08/12/2011 01:20 PM, tom st denis wrote:
> ...
>
> > Maybe Jacob could add an experimental mode in which errors/warnings
> > were more standardized and helpful than that as required by the ISO C
> > spec... :-)
>
> I would hope that, like most real-world compilers, lcc-win32 already
> does so in default mode. It would be pretty difficult to generate
> diagnostics that are less standardized or less helpful than required by
> the C standard. I'm not sure it's possible to provide diagnostics that
> are less helpful than required by the C standard, since the standard
> imposes no limits on how un-helpful a diagnostic could be.

I mean Jacob comes up with his own "standard" for errors/warnings and
documents that.  Joking aside, that actually might be helpful to the
industry.  Imagine if Solaris CC, GCC, CLANG, etc all produced
identical text for errors/warnings.  That'd be plenty darn handy.

Tom

[toc] | [prev] | [next] | [standalone]

#9275

tom st denis <tom@iahu.ca> writes:

> I mean Jacob comes up with his own "standard" for errors/warnings and
> documents that.  Joking aside, that actually might be helpful to the
> industry.  Imagine if Solaris CC, GCC, CLANG, etc all produced
> identical text for errors/warnings.  That'd be plenty darn handy.

It would be?  What would it be handy for?
-- 
"All code should be deliberately written for the purposes of instruction. 
 If your code isn't readable, it isn't finished yet."
--Richard Heathfield

[toc] | [prev] | [next] | [standalone]

#9279

On Aug 12, 2:36 pm, b...@cs.stanford.edu (Ben Pfaff) wrote:
> tom st denis <t...@iahu.ca> writes:
>
> > I mean Jacob comes up with his own "standard" for errors/warnings and
> > documents that.  Joking aside, that actually might be helpful to the
> > industry.  Imagine if Solaris CC, GCC, CLANG, etc all produced
> > identical text for errors/warnings.  That'd be plenty darn handy.
>
> It would be?  What would it be handy for?

For starters, it'd make people trying to debug syntax errors not have
to learn the idiosyncrasies of their compiler.  It'd mean in theory
they could post them to clc without getting an OT banhammer, etc...

Tom

[toc] | [prev] | [next] | [standalone]

#9280

tom st denis <tom@iahu.ca> writes:

> On Aug 12, 2:36 pm, b...@cs.stanford.edu (Ben Pfaff) wrote:
>> tom st denis <t...@iahu.ca> writes:
>>
>> > I mean Jacob comes up with his own "standard" for errors/warnings and
>> > documents that.  Joking aside, that actually might be helpful to the
>> > industry.  Imagine if Solaris CC, GCC, CLANG, etc all produced
>> > identical text for errors/warnings.  That'd be plenty darn handy.
>>
>> It would be?  What would it be handy for?
>
> For starters, it'd make people trying to debug syntax errors not have
> to learn the idiosyncrasies of their compiler.  It'd mean in theory
> they could post them to clc without getting an OT banhammer, etc...

Hmm.  The former might be useful.  I don't think the latter makes
much sense; it would be unusual for someone to post a compiler
error message to comp.lang.c, along with some code, and have
anyone complain that the error message by itself made the article
off-topic.
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#9278

Le 12/08/11 20:23, tom st denis a écrit :
>
> I mean Jacob comes up with his own "standard" for errors/warnings and
> documents that.  Joking aside, that actually might be helpful to the
> industry.  Imagine if Solaris CC, GCC, CLANG, etc all produced
> identical text for errors/warnings.  That'd be plenty darn handy.
>
> Tom


I have tried to improve all error messages issued by lcc-win.
For instance, "lvalue required" was replaced by "the left hand
side can't be assigned to", I try to detect missing semi-colons
and diagnostic them as such instead of just "syntax error",
etc.

[toc] | [prev] | [next] | [standalone]

#9221

Le 11/08/11 16:51, tom st denis a écrit :
> On Aug 11, 9:14 am, jacob navia<ja...@spamsink.net>  wrote:
>> The lcc-win compiler is a C99 compiler for windows systems. It can be
> ...
>> It is an experimental system, with several extensions to the C language
>
> These statements are incompatible.
>

You are just speaking nonsense, as you do very often.

The C standard (in its 99 edition) says in 4.6: (page 7 in the 2007
pdf that I have)

<quote>
A conforming implementation may have extensions (including additional
library functions), provided they do not alter the behavior of any
strictly conforming program.
<end quote>

None of my extensions affects strictly conforming programs. I have
never added ANY keyword, nor a reserved identifier.

I have repeated this countless times since several YEARS but you
(and your friends) ALWAYS bring up the same WRONG argument.

[toc] | [prev] | [next] | [standalone]

#9228

jacob navia <jacob@spamsink.net> wrote:

> None of my extensions affects strictly conforming programs. I have
> never added ANY keyword, nor a reserved identifier.
> 
> I have repeated this countless times since several YEARS but you
> (and your friends) ALWAYS bring up the same WRONG argument.

May be because even an eternal repetition of your argument does not
make it true. I remember to have seen here reports that lcc-win
deliberately copies declarations of standard functions to standard
headers they do not belong to, and pollutes the user name space
with proprietary macro and function names. All of these "extensions"
will prevent a specific strictly conforming program from being
compiled.

-- Ralf

[toc] | [prev] | [next] | [standalone]

#9229

Le 11/08/11 22:12, Ralf Damaschke a écrit :
> jacob navia<jacob@spamsink.net>  wrote:
>
>> None of my extensions affects strictly conforming programs. I have
>> never added ANY keyword, nor a reserved identifier.
>>
>> I have repeated this countless times since several YEARS but you
>> (and your friends) ALWAYS bring up the same WRONG argument.
>
> May be because even an eternal repetition of your argument does not
> make it true. I remember to have seen here reports that lcc-win
> deliberately copies declarations of standard functions to standard
> headers they do not belong to, and pollutes the user name space
> with proprietary macro and function names. All of these "extensions"
> will prevent a specific strictly conforming program from being
> compiled.
>
> -- Ralf

Yes, I have deliberately built bugs. I never had bugs
accidentally of course. All bugs are part of my plot to
sell my software (for free) and "lock in" my users into my headers...

You are just like the others: the fact that I wrote all those headers
(including the windows headers, several megabytes of them) alone with
no help is obviously a fact against me.

And the fact that I have tried to defend C99 for years in this forum
against thompson and heathfield doesn't bother you. No, you were
with them yesterday, telling everywhere and everybody
that "C99 is a failed standard" ,that shouldn't be used in portable
programs, and today you are the defender of "standard C".

Anything goes...

[toc] | [prev] | [next] | [standalone]

#9230

Ralf Damaschke <rwspam@gmx.de> writes:
> jacob navia <jacob@spamsink.net> wrote:
>> None of my extensions affects strictly conforming programs. I have
>> never added ANY keyword, nor a reserved identifier.
>> 
>> I have repeated this countless times since several YEARS but you
>> (and your friends) ALWAYS bring up the same WRONG argument.
>
> May be because even an eternal repetition of your argument does not
> make it true. I remember to have seen here reports that lcc-win
> deliberately copies declarations of standard functions to standard
> headers they do not belong to, and pollutes the user name space
> with proprietary macro and function names. All of these "extensions"
> will prevent a specific strictly conforming program from being
> compiled.

My understand is that lcc-win's "-ansic" command-line option is
intended to cause it to conform to C99, which includes issuing
diagnostics for any incompatible extensions.  Most C compilers are
non-conforming in their default mode.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#9231

On 08/12/11 08:12 AM, Ralf Damaschke wrote:
> jacob navia<jacob@spamsink.net>  wrote:
>
>> None of my extensions affects strictly conforming programs. I have
>> never added ANY keyword, nor a reserved identifier.
>>
>> I have repeated this countless times since several YEARS but you
>> (and your friends) ALWAYS bring up the same WRONG argument.
>
> May be because even an eternal repetition of your argument does not
> make it true. I remember to have seen here reports that lcc-win
> deliberately copies declarations of standard functions to standard
> headers they do not belong to, and pollutes the user name space
> with proprietary macro and function names. All of these "extensions"
> will prevent a specific strictly conforming program from being
> compiled.

Why are you bashing a tool you haven't used?  Jacob has also repeatedly 
stated that those extensions are disabled in conforming mode.

Can you name a compiler that is strictly conforming in its default mode?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#9315

>> The lcc-win compiler is a C99 compiler for windows systems. It can be
> ...
>> It is an experimental system, with several extensions to the C language
> 
> These statements are incompatible.

Not if the compiler provides two different implementations distinguished
by compiler flags, such as -std=c99 or -std=jacob-C .  And maybe even
if it doesn't.

Also, all a standard C compiler has to do is produce at least one
diagnostic if it finds an incompatible non-standard feature being
used.  This diagnostic could be one that reads:
	Copyright 2010 ...
and is always output on *every* compilation.  (Although the standard
doesn't require it, diagnostics are often divided into warnings,
errors, and threats, with copyright messages (at least on closed-source
compilers) being the threats.)

What a compiler can't do in standards mode is make standard-conforming
code do something different from what the standard says.  Very few,
if any, of Jacob's extensions do this.  I seem to recall one of
them had an accidental side effect that did this (perhaps it was
something in an include file being visible when it shouldn't be).
Jacob fixed it amazingly quickly compared to any commercial vendor.

> I'd instead say "it's a C99 compiler which can also be used in non-
> standard ways."  If the compiler accepts non-C99 syntax it's not a C99
> compiler, so the non-standard options would be to be enabled through a
> mode-switch to be a "c99 compiler."

If it puts out a copyright message, which in the documentation is
defined as a diagnostic, then accepting:
	2 + 2 =: a;
as meaning the same thing as:
	a = 2 + 2;
is acceptable because there's no way that the first line would be
accepted by a compiler operating in standards mode.

GCC gets away with at least as much in extensions as lcc.

On another topic, as I recall there *is* some kind of standard for
error messages, but it's probably not what you think.  An error
message essentially consists of the file and line number on which
an error occurred, and the text of the error message.  The "standard"
simply permitted parsing the file name and line number out of the
error message, so if a special program is fed the transcript of a
failed compile session, it could bring up an editor at the point
of the error.  It said nothing about the content of the error messages.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web