Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > ANSI C compliance

Reply
Thread Tools

ANSI C compliance

 
 
Roose
Guest
Posts: n/a
 
      11-04-2003
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
****ED. 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


 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      11-04-2003
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 : http://www.velocityreviews.com/forums/(E-Mail Removed)
"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
 
Reply With Quote
 
 
 
 
Ian Woods
Guest
Posts: n/a
 
      11-04-2003
"Roose" <(E-Mail Removed)> wrote in
news:3ZGpb.13633$(E-Mail Removed) om:

> 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 ****ED. 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


 
Reply With Quote
 
Roose
Guest
Posts: n/a
 
      11-04-2003
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" <(E-Mail Removed)> wrote in message
news:Xns94294FC6D5EC9newspubwuggyorg@217.32.252.50 ...
> "Roose" <(E-Mail Removed)> wrote in
> news:3ZGpb.13633$(E-Mail Removed) om:
> > 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


 
Reply With Quote
 
nobody
Guest
Posts: n/a
 
      11-04-2003
"Roose" <(E-Mail Removed)> wrote in message
news:3ZGpb.13633$(E-Mail Removed) om...
> 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
> ****ED. 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.


 
Reply With Quote
 
nobody
Guest
Posts: n/a
 
      11-04-2003
"Roose" <(E-Mail Removed)> wrote in message
news:LoJpb.13669$(E-Mail Removed) om...
> 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).


 
Reply With Quote
 
Richard Bos
Guest
Posts: n/a
 
      11-04-2003
"Roose" <(E-Mail Removed)> 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
 
Reply With Quote
 
Ian Woods
Guest
Posts: n/a
 
      11-04-2003
"Roose" <(E-Mail Removed)> wrote in
news:LoJpb.13669$(E-Mail Removed) om:

> 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" <(E-Mail Removed)> wrote in message
> news:Xns94294FC6D5EC9newspubwuggyorg@217.32.252.50 ...
>> "Roose" <(E-Mail Removed)> wrote in
>> news:3ZGpb.13633$(E-Mail Removed) om:


<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
 
Reply With Quote
 
rihad
Guest
Posts: n/a
 
      11-04-2003
On Tue, 04 Nov 2003 09:12:51 GMT, "nobody" <(E-Mail Removed)> wrote:

>"Roose" <(E-Mail Removed)> wrote in message
>news:LoJpb.13669$(E-Mail Removed). com...
>> 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.

 
Reply With Quote
 
Joona I Palaste
Guest
Posts: n/a
 
      11-04-2003
Richard Bos <(E-Mail Removed)> scribbled the following:
> "Roose" <(E-Mail Removed)> 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 ((E-Mail Removed)) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Roses are red, violets are blue, I'm a schitzophrenic and so am I."
- Bob Wiley
 
Reply With Quote
 
 
 
Reply

Thread Tools

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

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


Similar Threads
Thread Thread Starter Forum Replies Last Post
pre-ansi to ansi c++ conversion? Frank Iannarilli C++ 2 07-21-2009 11:05 PM
Are there statistics packages in ANSI C and/or ANSI C++? lbrtchx@gmail.com C Programming 11 04-28-2008 03:00 AM
Are there statistics packages in ANSI C and/or ANSI C++? lbrtchx@gmail.com C++ 1 04-24-2008 06:44 PM
If I buy Linksys Router in US, Is it universal compliance? GS Cisco 4 05-18-2005 08:20 PM
IEEE 1076.6 compliance cp VHDL 4 08-20-2004 08:20 AM



Advertisments