[OT] lcc first experience

Discussion in 'C Programming' started by Morris Dovey, May 6, 2008.

  1. Not related to your point but I tried the above code
    with splint , c99 and c89 from Sun Studio 12. None
    of the tools produced any warnings. To be precise
    with the compilers (including gcc) you have to add
    the -c option otherwise they complain about the lack
    of main().
    Spiros Bousbouras, May 9, 2008
    1. Advertisements

  2. Are you being deliberately obtuse, or are you just trying to fit in with
    the stupid literalism that's all the vogue in clc?

    A compiler is, by definition, system specific. It doesn't exist in a
    vacuum, but is a C program's link to the underlying system. Of course
    extensions will be necessary if the program is to make best use of the
    system it's running on.

    The C standard describes an abstract machine. The fact that many posters
    to this newsgroup treat it with a fetishistic reverence and try to make
    it into something it isn't doesn't change the reality. If you're happy
    to write trivial little homework-type programs, then fine, use strictly
    conforming standard C. If you're interested in writing C programs in the
    real world, then get real.
    Antoninus Twink, May 9, 2008
    1. Advertisements

  3. I meant it's extremely difficult to write a conforming C compiler that
    doesn't provide extensions. I hadn't meant to imply anything about the
    source code of the compiler. Now that you brought it up though, not all
    extensions are a good idea, if you want to be able to compile the compiler
    on a system that doesn't already have it.
    Harald van Dijk, May 9, 2008
  4. To the best of my recollection, neither gcc nor lcc-win has been
    flamed for providing extensions that do not affect the behavior of
    strictly conforming programs such as gcc's __attribute__ or lcc-win's
    operator overloading. (I'm assuming that lcc-win's operator
    overloading doesn't break strictly conforming code.)

    The standard does not require a diagnostic for the use of
    __attribute__, therefore we have no problem with the lack of a
    diagnostic. (IMHO it would be nice if gcc had a "really pedantic"
    mode in which it does diagnose such things, but I'm not going to
    insist on it.)

    If a gcc developer repeatedly advocated the use of
    __attribute__((const)) in comp.lang.c, that developer would
    undoubtedly be flamed for it, and asked to take his advocacy

    lcc-win does not conform to C90, and does not claim to do so. That's
    not a problem. When the existence of the undocumented "-ansic89"
    option recently came to light, and it was found that it did not cause
    lcc-win to conform to C89/C90 requirements, a lengthy discussion
    ensued -- one that could have been cut short if you had simply
    mentioned that "-ansic89" is not intended to implement C89/C90

    lcc-win declares several non-standard identifiers in its standard
    headers ("wtof" was the most recent example). This breaks strictly
    conforming programs. I consider these to be minor bugs, easy to fix
    -- and, given the knowledge of the standard that I would expect from a
    compiler developer, trivially easy to avoid in the first place. You
    have been mildly criticized for these bugs; you have been flamed for
    reacting to bug reports as if they were vicious personal attacks. If
    your response had been something like "Thanks for pointing that out;
    I'll fix it in the next release", or even "... I'll fix it when I get
    around to it", there would have been no real problem, at least as far
    as I'm concerned.

    You have been one of the most vociferous advocates of adopting the C99
    standard and discarding the (officially obsolete) C90 standard, in
    spite of the fact that the C99 standard is not yet sufficiently widely
    implemented to make C99 code portable. This is an odd attitude in
    view of the fact that your own lcc-win's C99 conformance is flawed,
    not just by bugs but by missing features.

    Yes, you and your compiler have been criticized here in ways that gcc
    and its developers have not. Part of this may be due to a general
    pro-gcc bias, but I believe the majority of the criticisms have been
    of things that *don't apply* to gcc.
    Keith Thompson, May 9, 2008
  5. Are you a professional moron, or just a gifted amateur?
    Antoninus Twink, May 9, 2008
  6. That should have been -ansi, which is what I typed but pan's word wrapping
    changed. If you look back at my message, you will find that - appeared at
    the end of a line, and ansi appeared at the start of the next.
    What made you think I was unaware of that? The fact that it's an allowed
    extension doesn't make it any less of an extension.
    Harald van Dijk, May 9, 2008
  7. I don't think the standard makes any such requirement.
    Well I won't repeat why it is OK but I must disagree that it is much
    more intrusive. The syntax was designed so that it can be very simply
    removed (gcc '-D__attribute__(x)=' does it from the command line) or,
    if I need to see where it may have been used (because I am porting to
    a system that uses the same syntax for something else) I can force a
    syntax error -- even from the command line if need be (gcc
    '-D__attribute__(x)={+}' would probably do it).
    Ben Bacarisse, May 10, 2008
  8. Eric, you really can be a total dick sometimes.

    Here are a couple of characteristic messages from long threads in the
    past few months. I'm sure if you trawl through the archives you'll find
    many, many more examples of occasions when you've jumped on the
    anti-Jacob bandwagon.


    Message-ID: <[email protected]>
    Is this the same debugger about which you said "Without [garbage
    collection], I would never have finished?"

    Let's see: You've already described C's lack of operator overloading as
    evidence of neglect on the part of the committee, you've characterized
    __declspec(naked) as an important language feature you use "very often,"
    you've railed at the absence of fixed-point arithmetic, ... Is there
    any feature, doodad, or dingbat you think *isn't* essential to C's


    Message-ID: <>

    Finally, operator overloading is by no means the only fad you promote.
    Your exact words were "many things that are necessary in a modern
    software development environment," with no limitation on or
    characterization of all these so-called "necessities." The sole
    mechanism you suggest for deciding whether something would or would not
    be a useful change to the language is "Whatever Jacob is enthusiastic
    about is an `advance' and goes into Jacob's compiler, which should by
    rights be the reference implementation for and definition of C." Pfui!
    Antoninus Twink, May 10, 2008
  9. Morris Dovey

    Old Wolf Guest

    The Metaware C compiler for ARM allows this syntax:

    where the bit between the two x's is the base (in hex).
    Old Wolf, May 12, 2008
  10. Morris Dovey

    Richard Bos Guest

    YM it can be made not to. Ganuck as a language does; and Gnu programs as
    a body do very much so.

    Richard Bos, May 16, 2008
  11. Morris Dovey

    Richard Bos Guest

    jacob, jacob, jacob... your paranoia is running away with you again. I
    specifically said upthread that you are _a disciple of_ Ganoo and M$,
    IOW, as bad as, not worse than.

    Richard Bos, May 16, 2008
    1. Advertisements

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.