ANSI C compliance

Discussion in 'C Programming' started by Roose, Nov 4, 2003.

  1. Roose

    Roose Guest

    Just to make a tangential point here, in case anyone new to C doesn't
    understand what all these flame wars are about.

    Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"

    We are discussing whether this newsgroup should focus on 100% ANSI C or
    simply topics related to the C language in the real world. There is a C
    standard which is defined by an international committee. People who write
    compilers refer to this in order to make sure their compilers follow the
    standard -- that they actually compile C. However, they also add extensions
    to the C language to make your life easier, and of course there are bugs in
    the compilers and such.

    So for various reasons, C you write which runs and works as expected on one
    platform might not work on another platform. The C standard is there to
    alleviate this -- to decide which compiler is wrong if they differ in
    behavior.

    What percent of non-trivial programs are completely ANSI C (i.e. they work
    as intended on all platforms for which you have an ANSI C compiler, modulo
    compiler bugs)? I would suspect somewhere near 0%, just like about 0% of
    non-trivial programs are completely bug free. Even taking this into
    account, I would suspect less than 5% of non-trivial C programs written are
    intended to be, or actually are, standard C. It simply isn't necessary
    engineering practice, although there are certainly exceptions. For example,
    one job I once interviewed for was writing standard ANSI C implementions of
    licensed technology, that were meant to be ported (by hand) to assembly on
    DSPs by the licensees. That is, the idea was to write something for other
    people to read and compile, not something to actually go in a real product.

    Now, on to my point. Writing truly standard C as valued by the "regulars"
    in this newsgroup is time-consuming if you're not experienced. And it takes
    time to accumulate the knowledge necessary to do so. Thus, in the business
    world, it is not considered good practice, since time = money.

    There is a field of study you might call "software development", which is
    the study of how real teams build real software products. There is a notion
    called "speculative generality" (from one of Steve McConnell's books I
    think, don't
    remember which one, see also Martin Fowler). This is basically when you
    write code that speculates on what you may need to write need in the future.
    Instead of writing code that does exactly what you need to do, you write
    something that does more than that, potentially. This is shorthand for
    overengineering -- architecting a general system when a specific one will
    do.

    Writing 100% ANSI C when you are not in a special circumstance (like the one
    I listed above) is considered speculative generality. Portability is a
    feature of code. Thinking about portability to machine with 9 bit bytes or
    2 stacks or no stack or 6 stacks is a waste of time (at least business time,
    your personal time is free to be spent however you like), when you have no
    forseeable need for it. Because this time could be spent working on
    features that actually are required, ones that actually generate money.
    Even if you DO have a forseeable need for it, it is considered good practice
    to solve _only the problem at hand_. Business requirements are extremely
    volatile. Executives are fickle.

    An example. Our game started out on PS2. A couple years ago we ported it
    to the GameCube and XBox. Did we have completely portable code at first?
    No, we wrote a game for PS2. Would it have been easier to port if we had?
    Sure, a little. But it wasn't a big deal to fix all the problems as they
    came up, as compiled with *real* compilers. And so we did so, in a
    straightforward manner.

    Do we have standard C code now that we ported it? No. Do we need to? Not
    really, the products sold more than 1.5 million copies and generated
    millions of dollars in profits.

    Now we are investigating porting it to PSP (Playstation portable). Would
    it be easier if we have standard C code? Sure, a little. But what if we
    never had to port to PSP? Then our effort writing standard C would have
    been wasted. What if the PSP compiler has a bad bug that makes it
    incompatible with ANSI C? (Not unlikely, since there is only one compiler
    for these machines at first, generally).

    In software development, *incur the development cost* of a feature *when you
    need it*. Not any sooner.

    So, the bottom line is, if I was working on making some old nasty code that
    works ANSI C compliant, instead of implementing a feature on my schedule
    (ANSI C compliance would be laughed off the schedule), my boss would be
    PISSED. You don't do that. There is a very real risk of creating bugs in
    already working code, which of course is much worse than that code not being
    ANSI C.

    That said, you should learn the basic rules of the language (to a reasonable
    point, there is definitely a point of diminishing returns). Far too many
    programmers hack blindly, just trying to shut the compiler warnings up.
    (Believe it or not, I am actually the one on the team that adheres most
    strictly to standards, e.g. I am the one who hates it when people use enum
    as integers, even though that is standard, etc.. My co-workers would have a
    good laugh at this, and wonder if this newsgroup is from another planet.)

    So, the second bottom line is, that this is C programming in the real world,
    which the overwhelming majority of people are interested in doing. As
    opposed to whacking off in a newsgroup about their ANSI C knowledge as an
    end in itself. That is why CLC is a terrible place to discuss ONLY ANSI C,
    as there is already perfectly good place (CLC.moderated). This is where
    people new to C tend to come (as mentioned, alt.comp.lang.learn-c-c++ is a
    joke by its very title), and CLC.moderated would reject many of their posts
    as off topic. Since they don't KNOW what standard C is yet, they don't know
    what's on-topic.

    Good day. If you have a reasoned response to this, I'd be interested in
    your opinions.

    (But alas, let the flames from the "regulars" begin...)

    Roose
    Roose, Nov 4, 2003
    #1
    1. Advertising

  2. Roose wrote:

    > We are discussing whether this newsgroup should focus on 100% ANSI C or
    > simply topics related to the C language in the real world. There is a C
    > standard which is defined by an international committee. People who write
    > compilers refer to this in order to make sure their compilers follow the
    > standard -- that they actually compile C.


    Indeed. And people who write C programs refer to it to ensure that their
    programs are C programs.

    > However, they also add
    > extensions to the C language to make your life easier, and of course there
    > are bugs in the compilers and such.


    Other newsgroups exist to discuss the extensions relating to particular
    implementations and platforms. Please take up platform-specific discussions
    in those other newsgroups. Thank you.

    <snip>

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
    Richard Heathfield, Nov 4, 2003
    #2
    1. Advertising

  3. Roose

    Ian Woods Guest

    "Roose" <> wrote in
    news:3ZGpb.13633$:

    > Just to make a tangential point here, in case anyone new to C doesn't
    > understand what all these flame wars are about.
    >
    > Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"
    >
    > We are discussing whether this newsgroup should focus on 100% ANSI C
    > or simply topics related to the C language in the real world. There
    > is a C standard which is defined by an international committee.
    > People who write compilers refer to this in order to make sure their
    > compilers follow the standard -- that they actually compile C.
    > However, they also add extensions to the C language to make your life
    > easier, and of course there are bugs in the compilers and such.


    Let me rewrite this paragraph a little:

    comp.lang.c is a newsgroup dedicated to discussions about the C
    programming language. The C programming language is defined by an
    international committee and it's definition is published by ISO. People
    write compilers which conform to this standard because otherwise they
    wouldn't be compiling C. Many C compilers also have a non-conforming mode
    as an extension which makes it behave like a compiler for a language
    which is similar to but different from C.

    > So for various reasons, C you write which runs and works as expected
    > on one platform might not work on another platform. The C standard is
    > there to alleviate this -- to decide which compiler is wrong if they
    > differ in behavior.


    Hmmm... and this one:

    Some parts of the standard are implimentation defined, so some C programs
    will behave differently on another platform. The C standard defines the
    behaviour of programs compiled with a C compiler, and where parts are
    implimentation defined requires that the behaviour is documented by the
    vendor. Any compiler which, when compiling a C program, produces an
    executable with behaviour different to that defined by the standard for
    the compiled source is not a C compiler.

    > What percent of non-trivial programs are completely ANSI C (i.e. they
    > work as intended on all platforms for which you have an ANSI C
    > compiler, modulo compiler bugs)? I would suspect somewhere near 0%,
    > just like about 0% of non-trivial programs are completely bug free.
    > Even taking this into account, I would suspect less than 5% of
    > non-trivial C programs written are intended to be, or actually are,
    > standard C. It simply isn't necessary engineering practice, although
    > there are certainly exceptions. For example, one job I once
    > interviewed for was writing standard ANSI C implementions of licensed
    > technology, that were meant to be ported (by hand) to assembly on DSPs
    > by the licensees. That is, the idea was to write something for other
    > people to read and compile, not something to actually go in a real
    > product.
    >
    > Now, on to my point. Writing truly standard C as valued by the
    > "regulars" in this newsgroup is time-consuming if you're not
    > experienced. And it takes time to accumulate the knowledge necessary
    > to do so. Thus, in the business world, it is not considered good
    > practice, since time = money.


    If your intention is to learn C, then do so. That is what is typically
    discussed here. If you want to learn almost-but-not-C-from-a-specific-
    vendor then there are newsgroups for that too.

    <snip>
    >This
    > is shorthand for overengineering -- architecting a general system when
    > a specific one will do.


    I don't see how writing in C is overengineering compared to writing in 'a
    C like language provided by some vendor'. It takes me no longer to write
    in C than it does to write in almost-C for an implimentation I'm familiar
    with.

    > Writing 100% ANSI C when you are not in a special circumstance (like
    > the one I listed above) is considered speculative generality.
    > Portability is a feature of code. Thinking about portability to
    > machine with 9 bit bytes or 2 stacks or no stack or 6 stacks is a
    > waste of time (at least business time, your personal time is free to
    > be spent however you like), when you have no forseeable need for it.
    > Because this time could be spent working on features that actually are
    > required, ones that actually generate money. Even if you DO have a
    > forseeable need for it, it is considered good practice to solve _only
    > the problem at hand_. Business requirements are extremely volatile.
    > Executives are fickle.


    Indeed, it's a waste of time thinking about the portability issues
    involved in making code work on such an array of systems. That's why we
    leave it to C compiler programmers to do it for us. They worry about that
    stuff, and I can just code in C secure in the knowledge that my program
    will do what I intended it to do.

    <snip business example of using languages like-C but vendor specific and
    the effort of porting between them, and the financial success of said
    project>

    > In software development, *incur the development cost* of a feature
    > *when you need it*. Not any sooner.


    Indeed. This is why I write in C whenever reasonable, rather than for a
    specific implimentation of it. If I need to do something which requires
    vendor specific code, I do it at the latest possible opportunity rather
    than earliest. I only incur the cost of having to examine and learn the
    vendor specific parts when necessary.

    > So, the bottom line is, if I was working on making some old nasty code
    > that works ANSI C compliant, instead of implementing a feature on my
    > schedule (ANSI C compliance would be laughed off the schedule), my
    > boss would be PISSED. You don't do that. There is a very real risk
    > of creating bugs in already working code, which of course is much
    > worse than that code not being ANSI C.


    Certainly, if you're not programming in C to begin with then it takes
    time in your schedule to make it into C later. Personally, I'll stick
    with writing in C when reasonable, and only go into vendor specific non-C
    extentions when they're needed.

    <snip>

    > (But alas, let the flames from the "regulars" begin...)
    >
    > Roose


    *hands Roose some flame retardant underwear...*

    Ian Woods
    Ian Woods, Nov 4, 2003
    #3
  4. Roose

    Roose Guest

    I'm going to respond to this as a serious answer, even though you are trying
    to refute my arguments with a game popularized by Richard -- pretend that
    the only thing that exists is what this newsgroup discusses. My article was
    about things outside ANSI C, so to reason about it correctly, you must not
    play that game.

    "Ian Woods" <> wrote in message
    news:Xns94294FC6D5EC9newspubwuggyorg@217.32.252.50...
    > "Roose" <> wrote in
    > news:3ZGpb.13633$:
    > > Now, on to my point. Writing truly standard C as valued by the
    > > "regulars" in this newsgroup is time-consuming if you're not
    > > experienced. And it takes time to accumulate the knowledge necessary
    > > to do so. Thus, in the business world, it is not considered good
    > > practice, since time = money.

    >
    > If your intention is to learn C, then do so. That is what is typically
    > discussed here. If you want to learn almost-but-not-C-from-a-specific-
    > vendor then there are newsgroups for that too.


    I'm not talking about "you" or "I". I'm talking about a real development
    team, that makes a real product. On such a team, _as a fact_, you will
    encounter old code, code written by someone other than yourself. Old code
    that is likely not written in ANSI C.

    >
    > <snip>
    > >This
    > > is shorthand for overengineering -- architecting a general system when
    > > a specific one will do.

    >
    > I don't see how writing in C is overengineering compared to writing in 'a
    > C like language provided by some vendor'. It takes me no longer to write
    > in C than it does to write in almost-C for an implimentation I'm familiar
    > with.


    Again, I'm not talking about "you". I'm talking about the average
    programmer who you might be working with. If you were a project manager, if
    such a programmer was not very familiar with ANSI C -- what would you do?
    Would you schedule extra time for him to make his code ANSI compliant, or
    would you schedule just enough time for him to get it into a nice readable
    state, suitable for further modification?

    > > Writing 100% ANSI C when you are not in a special circumstance (like
    > > the one I listed above) is considered speculative generality.
    > > Portability is a feature of code. Thinking about portability to
    > > machine with 9 bit bytes or 2 stacks or no stack or 6 stacks is a
    > > waste of time (at least business time, your personal time is free to
    > > be spent however you like), when you have no forseeable need for it.
    > > Because this time could be spent working on features that actually are
    > > required, ones that actually generate money. Even if you DO have a
    > > forseeable need for it, it is considered good practice to solve _only
    > > the problem at hand_. Business requirements are extremely volatile.
    > > Executives are fickle.

    >
    > Indeed, it's a waste of time thinking about the portability issues
    > involved in making code work on such an array of systems. That's why we
    > leave it to C compiler programmers to do it for us. They worry about that
    > stuff, and I can just code in C secure in the knowledge that my program
    > will do what I intended it to do.


    Point taken, but I still contend that portability is a feature. It costs
    extra to make code ANSI compliant.

    > > In software development, *incur the development cost* of a feature
    > > *when you need it*. Not any sooner.

    >
    > Indeed. This is why I write in C whenever reasonable, rather than for a
    > specific implimentation of it. If I need to do something which requires
    > vendor specific code, I do it at the latest possible opportunity rather
    > than earliest. I only incur the cost of having to examine and learn the
    > vendor specific parts when necessary.


    Same logic applies, not talking about "you".

    Roose
    Roose, Nov 4, 2003
    #4
  5. Roose

    nobody Guest

    "Roose" <> wrote in message
    news:3ZGpb.13633$...
    > Just to make a tangential point here, in case anyone new to C doesn't
    > understand what all these flame wars are about.
    >

    Nice touch. Warmonger doin' explainin'.

    > Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"
    >

    Sure, he actually compiles your crap with ANSI compatibility switch on
    and if it compiles without diagnostics (s)he fires you. I don't think even
    newbies are going to believe it.

    > We are discussing whether this newsgroup should focus on 100% ANSI C or


    No, we are not. You are trying to change focus of this group (should I say
    hijack?). This NG *is* about standard C. As it was already suggested,
    feel free to create your own and feel free to choose your topicality.

    > simply topics related to the C language in the real world. There is a C


    Geez, didn't know that C standards were created in some *un*real (world).

    > standard which is defined by an international committee. People who write
    > compilers refer to this in order to make sure their compilers follow the
    > standard -- that they actually compile C. However, they also add

    extensions

    The fact that your boss doesn't like when C programs actually compile
    doesn't necessitate change in focus of this NG. Suggestion: name your
    NG comp.lang.c.non-compilable, with strict specification in FAQ that
    compilable code is not permitted.

    > to the C language to make your life easier, and of course there are bugs

    in
    > the compilers and such.
    >
    > So for various reasons, C you write which runs and works as expected on

    one
    > platform might not work on another platform. The C standard is there to


    One of those various reasons is writing non-standard code, as proposed
    by OP and it's "advice(s)".

    > alleviate this -- to decide which compiler is wrong if they differ in
    > behavior.
    >

    Alleviation lies exactly in adhering to standard.

    > What percent of non-trivial programs are completely ANSI C (i.e. they work
    > as intended on all platforms for which you have an ANSI C compiler, modulo
    > compiler bugs)? I would suspect somewhere near 0%, just like about 0% of


    What do compiler bugs have to do with standards? And it's not 0% - you
    didn't write all C code in the Universe. Your suspicion is unjustifiable and
    not
    backed by any facts. Of course, only if we don't count your desire to
    stir wars in this NG as a fact supporting your "suspicion".

    > non-trivial programs are completely bug free. Even taking this into
    > account, I would suspect less than 5% of non-trivial C programs written

    are

    Again, your suspition is not based on facts. Though it's nice
    demagoguery: "I would suspect ...". Stirring emotions for your support
    in absence of any real arguments?

    > intended to be, or actually are, standard C. It simply isn't necessary
    > engineering practice, although there are certainly exceptions. For

    example,

    Sure, you are entitled to your opinion, what you consider to be "necessary
    engineering practice". Hope you are not going to program weapons systems
    anytime soon and will stick with games (if even that claim of yours is
    true).

    > one job I once interviewed for was writing standard ANSI C implementions

    of
    > licensed technology, that were meant to be ported (by hand) to assembly on
    > DSPs by the licensees. That is, the idea was to write something for other
    > people to read and compile, not something to actually go in a real

    product.
    >

    So the other people read it and compiled it, and that was it. Presumably
    they had never used it for any "real product". They just bought it and read
    it (whatever that means) and compiled it for fun of it. I won't be rude and
    won't say that I hope you didn't get a job.

    > Now, on to my point.


    Finally. Enough of foreplay already.

    > Writing truly standard C as valued by the "regulars"


    No need for quotes.

    <def>
    Main Entry: 1reg·u·lar
    Pronunciation: 're-gy&-l&r, 're-g(&-)l&r
    Function: adjective
    3 a : ORDERLY, METHODICAL <regular habits> b : recurring, attending, or
    functioning at fixed or uniform intervals <a regular income> <a regular
    churchgoer>
    4 a : constituted, conducted, or done in conformity with established or
    prescribed usages, rules, or discipline b : NORMAL, STANDARD: as (1) :
    ABSOLUTE, COMPLETE <a regular fool> <the office seemed like a regular
    madhouse> (2) : thinking or behaving in an acceptable, normal, or agreeable
    manner <was a regular guy> c (1) : conforming to the normal or usual manner
    of inflection
    </def>

    As you've promissed, you are getting to your point. You simply can't
    stand if something is regular like in "orderly", "methodical", "normal",
    "standard" and more form above. So you have decided to bring discord,
    so you can have some fun (as admitted in previous posts of yours) in the
    ruse of 'C language for all', 'down with despots-regulars' and similar.
    Well, C is for all who are willing to do some walking, not only talking.

    > in this newsgroup is time-consuming if you're not experienced.
    > And it takes time to accumulate the knowledge necessary to do so.


    What an unholly idea - to extend one's effort to achieve one's goals.

    > Thus, in the business world, it is not considered good practice,
    >

    I'm sure that interested reader will find plenty of supportive evidence
    for above claim as published by "Roose" and other internationally
    recognized business analysts and other authorities.

    > since time = money.


    OK, Roose, let's start with basics. In standard (not yours) C,
    "=" is assignment operator. If you want to get idea of equivalence
    accross in clc, you should use "==" instead. Please feel free, in your
    new NG, to redefine the language. Also I would strongly suggest
    to rename it.
    "Yours only, Roose, will be Fame,
    and clc regulars will fall in Shame"

    > There is a field of study you might call "software development", which is
    > the study of how real teams build real software products. There is a

    notion

    Obviously, Roose doesn't want to only change focus of clc and redefine
    (C) language, it is also trying to redefine terms so less knowledgeable
    or experienced folks would fall into it's (liar's) lair. Roose is presumably
    the only one working in *real* team building *real* software products,
    and therefore the only authority on how such things are done and should be
    done. Rest of participants in this NG are either newbies needing Roose's
    directions, so they can become members of *real* teams and build *real*
    software products, or old farts who know nothing about *real* C, *real*
    software development, *real* business, and *real* life in general. They
    know only thing or two about standard, which is *real*, but obsolete
    and harmful for *real* developers (like Roose) working on *real*
    projects (alas, like Roose).

    > called "speculative generality" (from one of Steve McConnell's books I


    Indeed, "speculative" part was demonstrated by OP very sucessfully.

    > think, don't
    > remember which one, see also Martin Fowler). This is basically when you
    > write code that speculates on what you may need to write need in the

    future.
    > Instead of writing code that does exactly what you need to do, you write
    > something that does more than that, potentially.


    Like, for example:
    int* pi;
    int i = *pi;

    This code instead of doing "exactly what you need to do", "does more than
    that, potentially". Depending, among others, on platform, time of day and
    what program was swapped before you loaded yours. If you try hard
    enough, you even get SIGSEGV, which old clc fossils would jelaously
    try to take away from you. Don't let them! Think, guys,
    what great potentials you can achieve under Roose's directions,
    unimanigable under orderly, methodical, normal, standard regulars.
    What beautiful life's rewards are awaiting it's followers.Heaven pales in
    comparision.

    > This is shorthand for
    > overengineering -- architecting a general system when a specific one will
    > do.
    >
    > Writing 100% ANSI C when you are not in a special circumstance (like the

    one
    > I listed above)


    Roose's loathing of *any* order, rules, conventions or standards surely
    makes it expert on defining "special circumstance". Suggestion for
    comp.lang.c.non-compilable:
    Q 7.2: What is a "special circumstance"?
    A: Special circumstance is any event, or set, combination or permutation
    of events as decided by Roose from time to time as dictaded by it's mood
    and other factors, with retroactive applicability and subject to change
    without any notice, and subject to no change with maybe some advanced
    notice.

    > is considered speculative generality. Portability is a
    > feature of code.


    For sure it is not feature of code written by you, as you are admitting
    elsewhere in this post.

    > Thinking about portability to machine with 9 bit bytes or
    > 2 stacks or no stack or 6 stacks is a waste of time


    Because of standard's abstractions, you *don't* have think
    of it, if you adhere to standard. Not to have to think about
    something can be hardly demonstrated as a waste of time.
    Of course, in Roose's world, where portability is defined
    differently, you will have to think about it every time when
    you want to "port". If yo are lucky enough (or paid enough
    attention to Roose and followed it's advices), you will have to
    rewrite everything from scratch. Well, I guess for some it's viable
    definition of "porting".

    > (at least business time,
    > your personal time is free to be spent however you like),


    I like that - benevolent leader.

    > when you have no
    > forseeable need for it. Because this time could be spent working on
    > features that actually are required, ones that actually generate money.
    > Even if you DO have a forseeable need for it, it is considered good

    practice
    > to solve _only the problem at hand_.


    If you adhere to Roose's teaching and dogmas ("standard C. It simply
    isn't necessary engineering practice"), you won't have to worry about
    your jobs any more. There always will be some "problem at hand".
    Plenty of them. So there will never be time to be "spent working on
    features that actually are required, ones that actually generate money".
    Really fascinating. Ultimate job security. ("Can we fire Fred"? "No,
    we can't". "Why not"? "He is fixing some problem at hand". "And
    what about Lucy"? "Same, she is working on another problem at hand".
    "And Roose"? "No way, she is leading them".)

    > Business requirements are extremely
    > volatile. Executives are fickle.
    >

    Which is sufficient evidence in itself for abandonment of all standards,
    be it C, ethical, accounting or other regulatory (standards).

    > An example. Our game started out on PS2. A couple years ago we ported it
    > to the GameCube and XBox. Did we have completely portable code at first?
    > No, we wrote a game for PS2. Would it have been easier to port if we had?
    > Sure, a little. But it wasn't a big deal to fix all the problems as they
    > came up, as compiled with *real* compilers. And so we did so, in a
    > straightforward manner.
    >

    And maybe Roose is bullshitting everybody and didn't get past of
    successful compilation of "Hello word".

    > Do we have standard C code now that we ported it? No. Do we need to?

    Not
    > really, the products sold more than 1.5 million copies and generated
    > millions of dollars in profits.
    >

    And I was wondering why my kid's console freezes from time to time
    and needs to be rebooted. Now I know. It's funny how someone
    is proudly displaying it's ignorance and incompetence. Even if it
    admitted it doesn't exists.

    > Now we are investigating porting it to PSP (Playstation portable). Would
    > it be easier if we have standard C code? Sure, a little. But what if we
    > never had to port to PSP? Then our effort writing standard C would have
    > been wasted.


    What if user didn't press Enter without any data? Then my effort
    writing checks for errors would have been wasted.
    What if pilot didn't bank in such a way, than my effort checking
    from negative value would have been wasted.
    What if my car didn't crash? Then my effort buckling up would have
    been wasted.
    Quite novel reasoning concepts.

    > What if the PSP compiler has a bad bug that makes it
    > incompatible with ANSI C? (Not unlikely, since there is only one compiler
    > for these machines at first, generally).
    >

    So you see? Because there may be non-conforming compiler on some
    platform, it makes sense to write non-comforming code.

    > In software development, *incur the development cost* of a feature *when

    you
    > need it*. Not any sooner.
    >

    Sure. Like when enough patients die because of software malfunction.
    Then we will fix it. Or when enough planes fall from the sky. Treshold
    value determination will be left to developer. *Real* one.

    > So, the bottom line is, if I was working on making some old nasty code

    that
    > works ANSI C compliant, instead of implementing a feature on my schedule
    > (ANSI C compliance would be laughed off the schedule),


    Sure. For individuals lazy enough to learn (or stupid enough), writing
    ANSI C compliant code has to be reflected in the project schedule.
    And it requires immense intellectual effort to switch relevant compiler
    flags on and off. And who has time reading diagnostic messages these
    days, anyway?

    > my boss would be
    > PISSED. You don't do that. There is a very real risk of creating bugs in


    Only bugs seem to be only in your already not working head. (I'm not
    mentioning brain on purpose. It's existence wasn't demonstrated yet.
    But I suspect it's non-existence might be.)

    > already working code, which of course is much worse than that code not

    being
    > ANSI C.
    >

    Incompetent can **** up any code - already working or not. Which is
    noncorelated to conformance of code.

    > That said, you should learn the basic rules of the language


    Like assignment and logical operators, for example.

    > (to a reasonable point, there is definitely a point of diminishing

    returns).

    Of course, definition of "when enough is enough" will be supplied by Roose,
    from time to time, and all that.

    > Far too many programmers hack blindly,
    > just trying to shut the compiler warnings up.


    From your ravings it's clear that it's far_too_many++;

    > (Believe it or not, I am actually the one on the team that adheres most
    > strictly to standards,


    Readers should be beware of what "strictly" means in Roose's world.

    > e.g. I am the one who hates it when people use enum
    > as integers, even though that is standard, etc.. My co-workers would have

    a
    > good laugh at this, and wonder if this newsgroup is from another planet.)
    >

    I guess this NG wonders the same about you.

    > So, the second bottom line is, that this is C programming in the real

    world,

    Sorry for omission. Please name your NG comp.lang.c.non-compilable.real.

    > which the overwhelming majority of people are interested in doing. As


    Presumably Roose performed representative poll, so it must know
    what "overwhelming majority of people are interested in doing".
    Maybe it will be kind enough and share data with the readers,
    together with applied methodology.

    > opposed to whacking off in a newsgroup about their ANSI C knowledge as an


    No one called you here. You don't like it, please feel free to leave
    any time. Still some space left on news servers for your own group,
    with your own rules. If you know what "overwhelming majority"
    and all this want to do, they for sure will follow your call and you
    won't need to waste your time with rigid fossils. Why not to leave
    them peacfully alone here until they die of old age, and in meantime
    you can build yourself your little imperium in form of new NG based
    on whatever misconceptions you choose.

    > end in itself. That is why CLC is a terrible place to discuss ONLY ANSI

    C,

    Normal people tend to leave terrible places, as soon as they discover
    how terrible they are. They just don't persist there and bitch about
    how terrible places they are. Especially if no one holds them there
    and there is plenty of space in virtual neighborhood.

    > as there is already perfectly good place (CLC.moderated). This is where


    As it was explained to you, and as names indicate, both groups are
    about same "thing", only one of the groups is moderated. Don't lie
    at least about facts what everyone can see and verify. Actually, why
    *you* don't move there and moderate it - this way it will be *you*
    who decides who speaks and who not. This is what you are after
    anyway, so it is really "already perfectly good place (CLC.moderated)"
    for all your purposes - both clearly advertised and those yet hidden.

    > people new to C tend to come (as mentioned, alt.comp.lang.learn-c-c++ is a
    > joke by its very title),


    As mentioned by "regular". No need to hide the fact. Or are you sooo
    embarassed that you've agreed on one point with regular?

    > and CLC.moderated would reject many of their posts
    > as off topic. Since they don't KNOW what standard C is yet, they don't

    know
    > what's on-topic.
    >

    At best, you are again trying to mislead. FAQ and answers tell them both
    about standard and topicality. You are trying to convince people that
    they should vacate clc (and you take over, of course) and you had found
    them good new home, at all that. Suddenly, you are new-born authority
    on *real* programming in *real* C and to hell with everyone, right?
    I don't think so.

    > Good day. If you have a reasoned response to this, I'd be interested in
    > your opinions.
    >

    I don't think you will recognise *any* reasonable response as such.
    Judging by my experience of redefinition of terms by you.

    > (But alas, let the flames from the "regulars" begin...)
    >

    Ah, here we go. Now I know how you translate "reasonable".
    And as for flames, this is what you are trying to do, right? What
    about spending your time fixing bugs in your software instead?
    It would for sure serve better purpose than igniting wars on almost
    daily basis.
    nobody, Nov 4, 2003
    #5
  6. Roose

    nobody Guest

    "Roose" <> wrote in message
    news:LoJpb.13669$...
    > I'm going to respond to this as a serious answer, even though you are

    trying
    > to refute my arguments


    You are still top-posting, therefore you are not serious. BTW, either
    news server or my newsreader must have stripped any arguments you
    may have made in OP. Surely only this must be reason I didn't find
    any. If both server and client software function properly (presumably
    because they don't adhere to any standard), reason may be something
    else. Like your omission to post any (arguments). In that case, whoever
    you are responding to (which is not clear thanks to your insistence on
    top-posting) may have find it hard to refute them (non-existent arguments).
    nobody, Nov 4, 2003
    #6
  7. Roose

    Richard Bos Guest

    "Roose" <> wrote:

    > We are discussing whether this newsgroup should focus on 100% ANSI C


    No, we aren't. _You_ are discussing that. The regulars know that it
    _does_. Now be a decent netizen and drop it.

    Richard
    Richard Bos, Nov 4, 2003
    #7
  8. Roose

    Ian Woods Guest

    "Roose" <> wrote in
    news:LoJpb.13669$:

    > I'm going to respond to this as a serious answer, even though you are
    > trying to refute my arguments with a game popularized by Richard --
    > pretend that the only thing that exists is what this newsgroup
    > discusses. My article was about things outside ANSI C, so to reason
    > about it correctly, you must not play that game.


    Most of the time I skip through comp.lang.c and only really read the most
    recent threads and threads to which I've previously contributed. This is
    the case here. I wasn't aware that I'd stumbled into a game being played
    between yourself and Mr. Heathfield.

    With regards to what this newsgroup discusses, that's covered in the FAQ.
    Even outside of the FAQ and this newsgroup, however, how do you define C?
    For me that question is easy to answer: I have a document which defines
    C. When people speak of C I look to the most authoritative definition of
    C which I know about.

    > "Ian Woods" <> wrote in message
    > news:Xns94294FC6D5EC9newspubwuggyorg@217.32.252.50...
    >> "Roose" <> wrote in
    >> news:3ZGpb.13633$:


    <snip>

    > I'm not talking about "you" or "I". I'm talking about a real
    > development team, that makes a real product. On such a team, _as a
    > fact_, you will encounter old code, code written by someone other than
    > yourself. Old code that is likely not written in ANSI C.


    Here I'm using you not to refer to 'Roose' but as an impersonal pronoun
    (though, rereading that's not completely clear). Usually, I don't use the
    term 'one' because it sounds pretentious. But, I shall rewrite my
    paragraph as it was meant and bugger the pretentiousness:

    "If one's intention is to learn C, then do so. That is what is typically
    discussed here. If one wanted to learn almost-but-not-C-from-a-specific-
    vendor then there are newsgroups for that too."

    I hope that clears up the meaning.

    >> <snip>
    >> >This
    >> > is shorthand for overengineering -- architecting a general system
    >> > when a specific one will do.

    >>
    >> I don't see how writing in C is overengineering compared to writing
    >> in 'a C like language provided by some vendor'. It takes me no longer
    >> to write in C than it does to write in almost-C for an implimentation
    >> I'm familiar with.

    >
    > Again, I'm not talking about "you". I'm talking about the average
    > programmer who you might be working with. If you were a project
    > manager, if such a programmer was not very familiar with ANSI C --
    > what would you do? Would you schedule extra time for him to make his
    > code ANSI compliant, or would you schedule just enough time for him to
    > get it into a nice readable state, suitable for further modification?


    Assuming he was hired as a C programmer, I'd expect him to be familiar
    with C. If he were hired as a programmer of some particular
    implimentations not-C I wouldn't have that expectation. In either case, I
    would have ensured that original job description was accurate, and if
    not, then I'd like to know why not and how that could be corrected. The
    correction may very well involve some retraining time for the
    accidentally mis-hired programmer. I certainly wouldn't, as a manager,
    knowingly hire someone as a C programmer who wasn't one.

    I have, on and off, worked on projects in C with people who are only
    familiar with a particularly implimentation, and typically not the one
    which the project is using. In these cases I do my best to vet their
    code, and usually in a few weeks, no more than casual vetting is
    required. It's rare that this makes projects overrun since there's
    usually time for such code reviews already set aside.

    >> > Writing 100% ANSI C when you are not in a special circumstance
    >> > (like the one I listed above) is considered speculative generality.
    >> > Portability is a feature of code. Thinking about portability to
    >> > machine with 9 bit bytes or 2 stacks or no stack or 6 stacks is a
    >> > waste of time (at least business time, your personal time is free
    >> > to be spent however you like), when you have no forseeable need for
    >> > it.

    <snip>
    >> Indeed, it's a waste of time thinking about the portability issues
    >> involved in making code work on such an array of systems. That's why
    >> we leave it to C compiler programmers to do it for us. They worry
    >> about that stuff, and I can just code in C secure in the knowledge
    >> that my program will do what I intended it to do.

    >
    > Point taken, but I still contend that portability is a feature. It
    > costs extra to make code ANSI compliant.


    Yes, it would cost extra if you (or one) were to make code C after it
    were written. I don't see how it costs extra if the code is written in C
    in the first place. The handful of people who I've 'mentored' whilst they
    were learning C didn't (at least as far as I saw) find their learning any
    harder than a specific vendors C implimentation. The 'portability' they
    effectively get without having to go out of their way thinking about it
    because they naturally code the way they do.

    <snip>

    Ian Woods
    Ian Woods, Nov 4, 2003
    #8
  9. Roose

    rihad Guest

    On Tue, 04 Nov 2003 09:12:51 GMT, "nobody" <> wrote:

    >"Roose" <> wrote in message
    >news:LoJpb.13669$...
    >> I'm going to respond to this as a serious answer, even though you are

    >trying
    >> to refute my arguments

    >
    >You are still top-posting, therefore you are not serious. BTW, either
    >news server or my newsreader must have stripped any arguments you
    >may have made in OP. Surely only this must be reason I didn't find
    >any. If both server and client software function properly (presumably
    >because they don't adhere to any standard), reason may be something
    >else. Like your omission to post any (arguments). In that case, whoever
    >you are responding to (which is not clear thanks to your insistence on
    >top-posting) may have find it hard to refute them (non-existent arguments).
    >


    I've seen this kind of "top-posting" coming even from regulars, so it's got to
    be fine. This is not even top-posting in the strict sense, but a kind of a
    "prelude", background, to what will come.
    rihad, Nov 4, 2003
    #9
  10. Richard Bos <> scribbled the following:
    > "Roose" <> wrote:
    >> We are discussing whether this newsgroup should focus on 100% ANSI C


    > No, we aren't. _You_ are discussing that. The regulars know that it
    > _does_. Now be a decent netizen and drop it.


    But Roose's boss doesn't want him to write standard-compliant code, so
    therefore no one uses standard-compliant code, and this whole
    newsgroup is meaningless.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "Roses are red, violets are blue, I'm a schitzophrenic and so am I."
    - Bob Wiley
    Joona I Palaste, Nov 4, 2003
    #10
  11. Roose

    Richard Bos Guest

    Joona I Palaste <> wrote:

    > Richard Bos <> scribbled the following:
    > > "Roose" <> wrote:
    > >> We are discussing whether this newsgroup should focus on 100% ANSI C

    >
    > > No, we aren't. _You_ are discussing that. The regulars know that it
    > > _does_. Now be a decent netizen and drop it.

    >
    > But Roose's boss doesn't want him to write standard-compliant code, so
    > therefore no one uses standard-compliant code, and this whole
    > newsgroup is meaningless.


    Then I see no problem with Roose getting the fsck off this meaningless
    newsgroup and finding a meaningful one somewhere else. Or with him
    trying to create the group comp.lang.c.unportable.

    Richard
    Richard Bos, Nov 4, 2003
    #11
  12. Richard Bos <> scribbled the following:
    > Joona I Palaste <> wrote:
    >> Richard Bos <> scribbled the following:
    >> > "Roose" <> wrote:
    >> >> We are discussing whether this newsgroup should focus on 100% ANSI C

    >>
    >> > No, we aren't. _You_ are discussing that. The regulars know that it
    >> > _does_. Now be a decent netizen and drop it.

    >>
    >> But Roose's boss doesn't want him to write standard-compliant code, so
    >> therefore no one uses standard-compliant code, and this whole
    >> newsgroup is meaningless.


    > Then I see no problem with Roose getting the fsck off this meaningless
    > newsgroup and finding a meaningful one somewhere else. Or with him
    > trying to create the group comp.lang.c.unportable.


    Believe me, you're not the only one who sees no problem with that. In
    fact, Roose is the only one who does.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "As a boy, I often dreamed of being a baseball, but now we must go forward, not
    backward, upward, not forward, and always whirling, whirling towards freedom!"
    - Kang
    Joona I Palaste, Nov 4, 2003
    #12
  13. Roose

    goose Guest

    "Roose" <> wrote in message news:<3ZGpb.13633$>...
    > Just to make a tangential point here, in case anyone new to C doesn't
    > understand what all these flame wars are about.
    >
    > Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"
    >
    > We are discussing whether this newsgroup should focus on 100% ANSI C or


    we are not. *we* already know what this newsgroup focuses on. *you*
    dont know what it focuses on, apparently.

    <stupidity-inspired rant snipped>

    > Good day. If you have a reasoned response to this, I'd be interested in
    > your opinions.


    everyone already knows that there are compiler specific extensions
    to ANSI C. but we also know that there are newsgroups dedicated
    to that. this newsgroup is dedicated to ANSI C. if you require
    a borland answer, go to a borland newsgroup, if you require a
    sparc answer, go to the sparc newsgroups.

    why are you all het up about the fact that you've been off-topic
    numerous times ? why not just accept the advice given to you and
    get back on topic ?

    >
    > (But alas, let the flames from the "regulars" begin...)
    >


    that wasn't a flame, btw

    hth, hand
    goose,
    goose, Nov 4, 2003
    #13
  14. "Roose" <> wrote:
    yet another irrelevant troll-post, filled with loads of non-arguments.

    To whom it may concern
    ======================

    Roose is an individual incapable of accepting the fact that his
    attempts to take over comp.lang.c are futile. His posts are best
    ignored, as they are either poor examples of usenet trolling or
    contain misleading information, or both.

    In order to get an idea what comp.lang.c is all about, it is strongly
    suggested to read the following documents:

    Welcome message for comp.lang.c, by Billy Chambless:
    http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

    FAQ-list for comp.lang.c, maintained by Steve Summit:
    http://www.eskimo.com/~scs/C-faq/top.html


    Regards
    --
    Irrwahn
    ()
    Irrwahn Grausewitz, Nov 4, 2003
    #14
  15. Roose

    pete Guest

    Roose wrote:

    > So for various reasons,
    > C you write which runs and works as expected on one
    > platform might not work on another platform.
    > The C standard is there to
    > alleviate this -- to decide which compiler is wrong if they differ in
    > behavior.


    Which compiler is wrong because your code
    won't work on more than one platform ?
    That's a joke. Get it ?
    While there might be a problem with a particular compiler,
    if you haven't learned how to write portable code,
    then the problem is very most likely your code.

    The way to write portable code,
    can't be construed from your compiler experiences.
    How to write portable code is on topic.
    It has everything to do with the C standard.

    --
    pete
    pete, Nov 4, 2003
    #15
  16. Roose

    Alan Balmer Guest

    On Tue, 04 Nov 2003 08:26:19 GMT, "Roose" <>
    wrote:

    >I'm going to respond to this as a serious answer, even though you are trying
    >to refute my arguments with a game popularized by Richard -- pretend that
    >the only thing that exists is what this newsgroup discusses. My article was
    >about things outside ANSI C, so to reason about it correctly, you must not
    >play that game.


    Please play your game somewhere else. You have it wrong - it's not
    that "the only thing that exists is what this newsgroup discusses.."
    The point is that this newsgroup discusses what is on-topic for this
    newsgroup. Other things exist, are interesting to discuss, and are
    discussed - elsewhere. Not here.

    --
    Al Balmer
    Balmer Consulting
    Alan Balmer, Nov 4, 2003
    #16
  17. Roose

    Roose Guest

    "pete" <> wrote in message
    news:...
    > Roose wrote:
    >
    > > So for various reasons,
    > > C you write which runs and works as expected on one
    > > platform might not work on another platform.
    > > The C standard is there to
    > > alleviate this -- to decide which compiler is wrong if they differ in
    > > behavior.

    >
    > Which compiler is wrong because your code
    > won't work on more than one platform ?


    No, learn to read, if the compilers differ in behavior. Example: if one
    accepts void main() and one doesn't. Spare me the nitpicks.
    Roose, Nov 4, 2003
    #17
  18. Roose wrote:

    > I'm going to respond to this as a serious answer, even though you are
    > trying to refute my arguments with a game popularized by Richard --
    > pretend that
    > the only thing that exists is what this newsgroup discusses.


    That's a travesty. This newsgroup discusses C. Other things exist apart from
    C, but we don't discuss them here. We discuss them elsewhere.

    > My article
    > was about things outside ANSI C,


    Then it is off-topic in this newsgroup. If you wish to discuss things
    outside C, please post contributions to such discussions in a newsgroup
    where they are topical. Thank you.

    <snip>

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
    Richard Heathfield, Nov 4, 2003
    #18
  19. Roose

    Guest

    Richard Heathfield <> wrote:

    > That's a travesty. This newsgroup discusses C. Other things exist apart from
    > C, but we don't discuss them here. We discuss them elsewhere.


    A most interesting statement and in direct contradiction of what you
    have stated previously:

    "On the other hand, comp.lang.c is /also/ a community, and as
    such has its own internal community dynamics. These include
    backchat, in-jokes, and the occasional protracted OT discussion.

    "In other words, it's okay for "us" to post OT, but not okay
    for "them"."

    Why do you deny the truth now?

    By your own statement, you _do_ discuss things here that exist apart
    from C.

    --
    , Nov 4, 2003
    #19
  20. Roose

    Tom St Denis Guest

    <> wrote in message
    news:1g3wkq0.3eq4hm1rxni40N%...
    > Why do you deny the truth now?
    >
    > By your own statement, you _do_ discuss things here that exist apart
    > from C.


    Occasionally meta-threads [e.g. OT] are required to control/advise/etc the
    group. This doesn't mean that OT posts are ok here just that there are
    instances [like say, this one] where it's tolerable.

    If your post is truly about the C language then post away. If it isn't then
    find an appropriate group. Can't be any simpler than that.

    Tom
    Tom St Denis, Nov 4, 2003
    #20
    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. cp

    IEEE 1076.6 compliance

    cp, Aug 16, 2004, in forum: VHDL
    Replies:
    4
    Views:
    1,260
    Eric Delage
    Aug 20, 2004
  2. rhat
    Replies:
    103
    Views:
    1,999
    =?Utf-8?B?TG9nYW4gR3JlZW5sZWU=?=
    Jun 16, 2005
  3. Replies:
    1
    Views:
    487
  4. Replies:
    11
    Views:
    1,067
    Keith Thompson
    Apr 28, 2008
  5. Frank Iannarilli

    pre-ansi to ansi c++ conversion?

    Frank Iannarilli, Jul 21, 2009, in forum: C++
    Replies:
    2
    Views:
    411
Loading...

Share This Page