lcc-win

Discussion in 'C Programming' started by jacob navia, Aug 11, 2011.

  1. jacob navia

    jacob navia Guest

    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
    jacob navia, Aug 11, 2011
    #1
    1. Advertising

  2. jacob navia

    tom st denis Guest

    On Aug 11, 9:14 am, jacob navia <> 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...
    tom st denis, Aug 11, 2011
    #2
    1. Advertising

  3. jacob navia

    James Kuyper Guest

    On 08/11/2011 10:51 AM, tom st denis wrote:
    > On Aug 11, 9:14 am, jacob navia <> 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.".
    James Kuyper, Aug 11, 2011
    #3
  4. jacob navia

    tom st denis Guest

    On Aug 11, 11:23 am, James Kuyper <> wrote:
    > On 08/11/2011 10:51 AM, tom st denis wrote:
    >
    > > On Aug 11, 9:14 am, jacob navia <> 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
    tom st denis, Aug 11, 2011
    #4
  5. jacob navia

    James Kuyper Guest

    On 08/11/2011 11:35 AM, tom st denis wrote:
    > On Aug 11, 11:23 am, James Kuyper <> wrote:
    >> On 08/11/2011 10:51 AM, tom st denis wrote:
    >>
    >>> On Aug 11, 9:14 am, jacob navia <> 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.
    James Kuyper, Aug 11, 2011
    #5
  6. jacob navia

    jacob navia Guest

    Le 11/08/11 16:51, tom st denis a écrit :
    > On Aug 11, 9:14 am, jacob navia<> 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.
    jacob navia, Aug 11, 2011
    #6
  7. James Kuyper <> 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) <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"
    Keith Thompson, Aug 11, 2011
    #7
  8. jacob navia <> 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
    Ralf Damaschke, Aug 11, 2011
    #8
  9. jacob navia

    jacob navia Guest

    Le 11/08/11 22:12, Ralf Damaschke a écrit :
    > jacob navia<> 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...
    jacob navia, Aug 11, 2011
    #9
  10. Ralf Damaschke <> writes:
    > jacob navia <> 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) <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"
    Keith Thompson, Aug 11, 2011
    #10
  11. jacob navia

    Ian Collins Guest

    On 08/12/11 08:12 AM, Ralf Damaschke wrote:
    > jacob navia<> 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
    Ian Collins, Aug 11, 2011
    #11
  12. jacob navia

    tom st denis Guest

    On Aug 11, 2:46 pm, Keith Thompson <> wrote:
    > James Kuyper <> 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
    tom st denis, Aug 12, 2011
    #12
  13. jacob navia

    James Kuyper Guest

    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.
    James Kuyper, Aug 12, 2011
    #13
  14. jacob navia

    tom st denis Guest

    On Aug 12, 2:00 pm, James Kuyper <> 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
    tom st denis, Aug 12, 2011
    #14
  15. jacob navia

    Ben Pfaff Guest

    tom st denis <> 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
    Ben Pfaff, Aug 12, 2011
    #15
  16. jacob navia

    jacob navia Guest

    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.
    jacob navia, Aug 12, 2011
    #16
  17. jacob navia

    tom st denis Guest

    On Aug 12, 2:36 pm, (Ben Pfaff) wrote:
    > tom st denis <> 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
    tom st denis, Aug 12, 2011
    #17
  18. jacob navia

    Ben Pfaff Guest

    tom st denis <> writes:

    > On Aug 12, 2:36 pm, (Ben Pfaff) wrote:
    >> tom st denis <> 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
    Ben Pfaff, Aug 12, 2011
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jacob navia

    Warnings in lcc-win

    jacob navia, Sep 27, 2007, in forum: C Programming
    Replies:
    70
    Views:
    1,718
    Charlie Gordon
    Oct 3, 2007
  2. jacob navia

    ANN Linux version of lcc-win

    jacob navia, Oct 5, 2007, in forum: C Programming
    Replies:
    1
    Views:
    364
    Keith Thompson
    Oct 5, 2007
  3. jacob navia

    lcc-win and windows 98

    jacob navia, Jan 21, 2008, in forum: C Programming
    Replies:
    16
    Views:
    516
    santosh
    Jan 24, 2008
  4. Eddie

    Bug/problem with lcc-win

    Eddie, Jun 3, 2008, in forum: C Programming
    Replies:
    69
    Views:
    1,327
    Richard
    Jun 14, 2008
  5. Krist
    Replies:
    6
    Views:
    741
    Arne Vajhøj
    May 7, 2010
Loading...

Share This Page