By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,666 Members | 1,784 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,666 IT Pros & Developers. It's quick & easy.

ANSI C compliance

P: n/a
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
Nov 13 '05 #1
Share this Question
Share on Google+
100 Replies


P: n/a
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 : bi****@eton.powernet.co.uk
"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
Nov 13 '05 #2

P: n/a
"Roose" <no****@nospam.nospam> wrote in
news:3Z******************@newssvr14.news.prodigy.c 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 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
Nov 13 '05 #3

P: n/a
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" <ne******@wuggyNOCAPS.org> wrote in message
news:Xn*****************************@217.32.252.50 ...
"Roose" <no****@nospam.nospam> wrote in
news:3Z******************@newssvr14.news.prodigy.c 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
Nov 13 '05 #4

P: n/a
"Roose" <no****@nospam.nospam> wrote in message
news:3Z******************@newssvr14.news.prodigy.c 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
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 fuck 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.
Nov 13 '05 #5

P: n/a
"Roose" <no****@nospam.nospam> wrote in message
news:Lo******************@newssvr14.news.prodigy.c 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).
Nov 13 '05 #6

P: n/a
"Roose" <no****@nospam.nospam> wrote in
news:Lo******************@newssvr14.news.prodigy.c 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" <ne******@wuggyNOCAPS.org> wrote in message
news:Xn*****************************@217.32.252.50 ...
"Roose" <no****@nospam.nospam> wrote in
news:3Z******************@newssvr14.news.prodigy.c 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
Nov 13 '05 #7

P: n/a
"Roose" <no****@nospam.nospam> 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
Nov 13 '05 #8

P: n/a
On Tue, 04 Nov 2003 09:12:51 GMT, "nobody" <no****@nowhere.non> wrote:
"Roose" <no****@nospam.nospam> wrote in message
news:Lo******************@newssvr14.news.prodigy. 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.

Nov 13 '05 #9

P: n/a
Richard Bos <rl*@hoekstra-uitgeverij.nl> scribbled the following:
"Roose" <no****@nospam.nospam> 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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Roses are red, violets are blue, I'm a schitzophrenic and so am I."
- Bob Wiley
Nov 13 '05 #10

P: n/a
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:
Richard Bos <rl*@hoekstra-uitgeverij.nl> scribbled the following:
"Roose" <no****@nospam.nospam> 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
Nov 13 '05 #11

P: n/a
Richard Bos <rl*@hoekstra-uitgeverij.nl> scribbled the following:
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:
Richard Bos <rl*@hoekstra-uitgeverij.nl> scribbled the following:
> "Roose" <no****@nospam.nospam> 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 (pa*****@cc.helsinki.fi) ------------- 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
Nov 13 '05 #12

P: n/a
"Roose" <no****@nospam.nospam> wrote in message news:<3Z******************@newssvr14.news.prodigy. com>...
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,
Nov 13 '05 #13

P: n/a
"Roose" <no****@nospam.nospam> 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/bchambl...me_to_clc.html

FAQ-list for comp.lang.c, maintained by Steve Summit:
http://www.eskimo.com/~scs/C-faq/top.html
Regards
--
Irrwahn
(ir*******@freenet.de)
Nov 13 '05 #14

P: n/a
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
Nov 13 '05 #15

P: n/a
On Tue, 04 Nov 2003 08:26:19 GMT, "Roose" <no****@nospam.nospam>
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
re************************@att.net
Nov 13 '05 #16

P: n/a

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
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.
Nov 13 '05 #17

P: n/a
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 : bi****@eton.powernet.co.uk
"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
Nov 13 '05 #18

P: n/a
Richard Heathfield <do******@address.co.uk.invalid> 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 13 '05 #19

P: n/a

<te*********@BUSThotmailE.Rcom> wrote in message
news:1g3wkq0.3eq4hm1rxni40N%te*********@BUSThotmai lE.Rcom...
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
Nov 13 '05 #20

P: n/a
Roose wrote:
"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
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.


Since no implementation is required by the Standard to accept a void main
program, it would be folly to write such a program (freestanding
implementations notwithstanding).

--
Richard Heathfield : bi****@eton.powernet.co.uk
"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
Nov 13 '05 #21

P: n/a
te*********@BUSThotmailE.Rcom wrote:
Richard Heathfield <do******@address.co.uk.invalid> 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"."


Yes, correct. But notice this: you will never (okay, never say never, but
you know what I mean) see a regular contributor /begin/ a thread with an
off-topic article. Topicality is important to this newsgroup, and we do
strive to remain topical. Nevertheless, sometimes the conversation drifts
off-topic, but as long as it remains interesting to the group, it can
survive. When regular contributors start to complain about the topicality
of a drifting thread, it isn't long before the regular contributors stop
posting to that thread. In any event, as Kaz once said, posting clueful,
well-thought-out contributions to topical discussions here is like putting
pennies in the bank, and posting off-topic articles is like taking out
dollars. The trick is not to get overdrawn (although I must admit I
wouldn't insist on a 100-1 ratio).
Why do you deny the truth now?
I don't, but I'll gladly qualify what I said. Yes, we do sometimes get into
interesting side-tracks. That doesn't mean we are prepared to throw the
doors wide open and see this newsgroup go down the same spiral into chaos
that nearly sank comp.lang.c++ a few years ago.
By your own statement, you _do_ discuss things here that exist apart
from C.


C has to be the start point, though.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"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
Nov 13 '05 #22

P: n/a
te*********@BUSThotmailE.Rcom writes:
Richard Heathfield <do******@address.co.uk.invalid> 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"."


We (meaning the regulars) discuss things other than C very little
here. Someone (Chris Torek?) once formulated it along the lines
of "Every time you make an on-topic post, that's like depositing
one cent ($0.01). Every time you make an off-topic post, that's
like withdrawing a dollar ($1.00). Try to keep your balance
positive."
--
"...deficient support can be a virtue.
It keeps the amateurs off."
--Bjarne Stroustrup
Nov 13 '05 #23

P: n/a
(oh dear...I'm top-posting..)

Hey, Roose, isn't it fun to catch these people in a blatant lie which
was designed to attack and vilify and then watch them wiggle and squirm
to get out of it?

I find it fascinating that Richard begins his defense of one lie with
another:

"you will never see a regular contributor /begin/ a thread with
an off-topic article."

Of course, he does try to explain away this one with his lame 'never say
never' comment...but if he really meant this, he would have said
something like:

You will almost never see a regular contributor begin a thread with
an off-topic article.

or

You will rarely see a regular contributor begin a thread with
an off-topic article.

or nearly an infinite number of other possible, and truthful, wordings.

Various regulars have, of course, started totally off-topic threads in
the past...it's rare, but it does occur, and, as Richard admits, without
the vilification that they will heap onto others outside their little
circle.
Richard Heathfield <do******@address.co.uk.invalid> wrote:
te*********@BUSThotmailE.Rcom wrote:
Richard Heathfield <do******@address.co.uk.invalid> 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"."


Yes, correct. But notice this: you will never (okay, never say never, but
you know what I mean) see a regular contributor /begin/ a thread with an
off-topic article. Topicality is important to this newsgroup, and we do
strive to remain topical. Nevertheless, sometimes the conversation drifts
off-topic, but as long as it remains interesting to the group, it can
survive. When regular contributors start to complain about the topicality
of a drifting thread, it isn't long before the regular contributors stop
posting to that thread. In any event, as Kaz once said, posting clueful,
well-thought-out contributions to topical discussions here is like putting
pennies in the bank, and posting off-topic articles is like taking out
dollars. The trick is not to get overdrawn (although I must admit I
wouldn't insist on a 100-1 ratio).
Why do you deny the truth now?


I don't, but I'll gladly qualify what I said. Yes, we do sometimes get into
interesting side-tracks. That doesn't mean we are prepared to throw the
doors wide open and see this newsgroup go down the same spiral into chaos
that nearly sank comp.lang.c++ a few years ago.
By your own statement, you _do_ discuss things here that exist apart
from C.


C has to be the start point, though.

--
Nov 13 '05 #24

P: n/a
te*********@BUSThotmailE.Rcom wrote:
I find it fascinating that Richard begins his defense of one lie with
another:
It's unfortunate that you choose the word "lie" to describe a poor choice of
wording, but c'est la vie.

"you will never see a regular contributor /begin/ a thread with
an off-topic article."

Of course, he does try to explain away this one with his lame 'never say
never' comment...but if he really meant this, he would have said
something like:

You will almost never see a regular contributor begin a thread with
an off-topic article.
I will cheerfully accept the alternative wording, but do you have an actual
example of an OT comp.lang.c thread started by a regular contributor?
Various regulars have, of course, started totally off-topic threads in
the past...
Example, please.
it's rare, but it does occur, and, as Richard admits, without
the vilification that they will heap onto others outside their little
circle.


I would hope that (in the general case) those who innocently start OT
threads are not vilified, but merely redirected. It is unfortunately the
case that some people are rather aggressive in their defence of topicality,
and I don't deny that I have been guilty of this myself in the past. I try,
nowadays, to be less vehement when dealing with ignorance (as opposed to
wilful dontgiveadamnness). I think I have succeeded.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"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
Nov 13 '05 #25

P: n/a
In article <ff**************************@posting.google.com >,
ru**@webmail.co.za says...
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.


To me, that is the primary value of this newsgroup. If you need
to know if a particular construct is portable across a wide range
of platforms, you need not bother ask that question in one of
the OS, H/W platform or compiler specific newsgroups. Come here.
The range of knowledge, across an incredibly wide range of
development environments is staggering. If you want to know
how to get a far pointer to the video adapter memory under DOS
using MSVC 1.52, go elsewhere.

Neat little stories about how Roose could manage to take standard
ISO C and turn it into something platform-dependent so he won't
get fired by his off should be left for something like
alt.folklore.computers instead.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 13 '05 #26

P: n/a
On Tue, 4 Nov 2003 19:45:58 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

Ben Pfaff wrote:
Someone (Chris Torek?) once formulated it along the lines
of "Every time you make an on-topic post, that's like depositing
one cent ($0.01). Every time you make an off-topic post, that's
like withdrawing a dollar ($1.00). Try to keep your balance
positive."
Richard Heathfield wrote:
In any event, as Kaz once said, posting clueful,
well-thought-out contributions to topical discussions here is like putting
pennies in the bank, and posting off-topic articles is like taking out
dollars. The trick is not to get overdrawn (although I must admit I
wouldn't insist on a 100-1 ratio).


Okay, who was it: Kaz Kylheku OR Chris Torek? :)
Nov 13 '05 #27

P: n/a
In article <np********************************@4ax.com>,
rihad <ri***@mail.ru> wrote:
Okay, who was it: Kaz Kylheku OR Chris Torek? :)


Quoth Google:
http://groups.google.com/groups?selm...FootPrints.net

So it looks like it was Kaz.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
To anyone who has seen LISP-ish rightward binary trees, this is perfectly
clear. Although one might wonder what such a person is doing writing C.
--David Thompson in comp.lang.c
Nov 13 '05 #28

P: n/a
Roose wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
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.


Your example makes no sense.
A conforming compiler is allowed to accept void main().
A confroming compiler is allowed to reject void main().
The standard says neither compiler is wrong.

On the other hand, and to the point,
the standard says that all conforming compilers must accept
int main(void).
int main(void) is portable code.
int main(void) will work on your compiler, regardless
of whether your compiler accepts void main() or not.

Your void main() code is not portable. The problem is your code.

Like I said:
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.

Nov 13 '05 #29

P: n/a
On Tue, 04 Nov 2003 08:26:19 GMT, in comp.lang.c , "Roose"
<no****@nospam.nospam> 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.


Ian Woods is someone else who you might we well advised to do a
websearch for, before dismissing his arguments.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #30

P: n/a
On Tue, 4 Nov 2003 15:03:34 -0500, in comp.lang.c ,
te*********@BUSThotmailE.Rcom wrote:
(oh dear...I'm top-posting..)

Hey, Roose, isn't it fun to catch these people in a blatant lie which
was designed to attack and vilify and then watch them wiggle and squirm
to get out of it?
Yeah., whatever. Welcome to the bitbucket,
I find it fascinating that Richard begins his defense of one lie with
another:


Fuckwit.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #31

P: n/a
On Tue, 04 Nov 2003 05:40:15 GMT, in comp.lang.c , "Roose"
<no****@nospam.nospam> wrote:
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"
This is a stupid statement. In the Real World, which you seem not to
inhabit, computer programs interact with their surroundings. This
interaction is by definition Implementation Specific, and consequently
not part of the C language. Naturally there are parts of what we all
write that are not C. So what?
We are discussing whether this newsgroup should focus on 100% ANSI C or
simply topics related to the C language in the real world.


The C language is defined by ANSI (more accurately ISO). so your
statement is meaningless. But to interpret it as you probably meant,
the answer is simple - you want to discuss gcc. pop over to the gcc
group. You want to discuss MSVC, you know where the microsoft gruops
are.

Bye now.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 13 '05 #32

P: n/a
Roose wrote:
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.
Sure, but none of us -- you, I, or Ian -- is talking to or about
that earlier programmer. We're talking about us -- you, me, and
anyone else who happens to be listening, who we'd like to convince
to do better than the earlier programmer.
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?
If I cared about the long-term maintainability of the company's
code base, and if my programmers were insufficiently competent to
so maintain it, I might schedule some time for those programmers
to learn the necessary skills.
Point taken, but I still contend that portability is a feature.
It costs extra to make code ANSI compliant.


The same can be said about any feature, meaning that the way to
save the most money is presumably not to try to write the code at
all.

If the short-term costs of coding portably truly don't promise
any long-term benefits, or if you're trapped by deadline
pressures under which you don't have time to do things right
(though you might have time to do them again), you might decide
you can't afford the portability.

But for those of us who are used to doing it, the short-term cost
of the kinds of portability we're talking about here is zero.
The nicely portable code flows out of our fingers as easily
as the nonportable code, that you seem to be trying to condone,
fumbles out of the fingers of those hypothetical earlier
programmers. The question is -- which kind of programming are
we trying to encourage? And if we constantly give everyone carte
blanche to write code which falls down on the various software
virtues -- portability, maintainability, correctness, repeatability,
predictability, efficiency -- if every day we let them get away
with that which is merely expedient, when will we collectively
ever learn to do better?

The expediency you seem to be condoning is responsible for many
of the ills in software development. I understand that you're
willing to make tradeoffs in favor of expediency at the expense
of other virtues, but what always puzzles me is why you and so
many posters before you keep coming in here and insisting that
the rest of us are wrong for making, or advocating, a different
set of tradeoffs.

Software engineering is still a pretty flimsy discipline.
For the most part, we're all slogging along through the mud,
often waist deep, often falling on our faces in it. Yet when one
of the sloggers dares to suggest that we invent paved roads, and
wheeled vehicles to move swiftly and easily on them, someone else
derides this vision as an ivory-tower fantasy, ungrounded in the
real world. 'Tis sad.

Steve Summit
sc*@eskimo.com
Nov 13 '05 #33

P: n/a
Roose wrote:
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.


Please don't tar everyone with the same brush. I don't know all
the "regulars" here and I don't speak for them any more then they
speak for me, but when *I* advocate portable programming practices,
or the other practices I believe in, I can assure you I'm not
"whacking off". The practices I advocate are the ones I try to
use myself, and where I use them is not in some dusty ivory
tower, but rather in the rough-and-tumble world of real-life
software development, where the people I work for are pleased
that I do not trouble them with design decisions like "how
portably should I write this?" (which are arguably mine as an
engineer to make), but rather deliver code that works, on time,
and that adapts well to its changing requirements, and that
doesn't need lots of hands-on maintenance later.

The practice of focusing rather zealously on portability and
correctness, which I'm pleased to say I learned in large part
from the people who were regulars back when comp.lang.c was
called net.lang.c, is very much *not* an end in itself.
It's a practice which brings so many real benefits to the
programs I write that I can't even remember them all just now.
What's more, plenty of them are benefits which I can enjoy right
away, i.e., I don't even have to wait patiently for some far-off
long-term benefit.

You'll probably say, "Wait a minute, where did correctness come
in, no argument there, we were talking about portability."
But to me, programming portably is so important (and comes so
easily) that it's actually become part of correctness. I don't
"port" code any more; what I do (if anything) while recompiling
code in a different environment is to fix the portability bugs
it had all along but which I have only just now discovered.

Steve Summit
sc*@eskimo.com
Nov 13 '05 #34

P: n/a
Roose wrote:
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 you stop to think about it, this is a pretty meaningless
statement. Take out the words "truly standard C as valued by the
regulars in this newsgroup" and replace them by any positive
attribute of code you can think of:

Writing functional code is time-consuming if you're not experienced.
Writing maintainable code is time-consuming if you're not experienced.
Writing compact code is time-consuming if you're not experienced.
Writing efficient code is time-consuming if you're not experienced.
Writing correct code is time-consuming if you're not experienced.

Are all of these, then, "not considered good practice" in the
business world?

The obvious solution here is to work on gaining some good
experience, so that good code (by any metric) doesn't have to be
so time-consuming to write.
There is a notion called "speculative generality"... This is
basically when you write code that speculates on what you may...
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.
And this is a very tricky set of ideas to think properly about.
Yes, sometimes when you overengineer something you're wasting
resources which could be better spent elsewhere, no question.
But other times, a certain level of overengineering is not just
good practice, it's mandatory. In the real world, for example,
it's not "overengineering" to build a structure to withstand a
severe storm. To build a house that can withstand exactly the
weather conditions you're experiencing today, but which falls
down during the first rain or windstorm, would be folly.
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...
I don't think anyone here is advocating always writing code which
tries to be portable to machines with 9 bit bytes. (Personally,
I don't even know how to.) Your other examples are even more
absurd, since no C program (let alone a portable one) can even
tell how many stacks there might be.
Writing 100% ANSI C when you are not in a special circumstance
(like the one I listed above) is considered speculative generality...
Even if you DO have a forseeable need for it, it is considered good
practice to solve _only the problem at hand_.
You keep saying, "is considered". Is considered by *who*?
By you? By the managers at the software companies that foist upon
the world laughably insecure, virus-infested operating systems,
and word processors that perform functions that no sane person
would require of them and ("Ford added savagely") go beep to tell
you when they've done it? They can have their opinions of what
"is considered" good practice, thank you; me, I think I'll use my own.
Business requirements are extremely volatile. Executives are fickle.


Programmers who let executives tell them how to write their code
are jointly responsible for the unmaintainable failures they go on
to create.

Steve Summit
sc*@eskimo.com
Nov 13 '05 #35

P: n/a
On Tue, 04 Nov 2003 05:40:15 GMT, "Roose" <no****@nospam.nospam> wrote
in comp.lang.c:
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"
I personally write few completely 100% strictly conforming programs on
the job. When the opportunity presents itself, I do, which occurs a
surprisingly large fraction of the time.
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
Your "real world" is most certainly not the same as my "real world".
One of the world's most used C compilers, gcc, has a command line
switch to compile FORTRAN. That's a "real world" use of a C compiler.
But it has nothing to do with the C language, which has one and only
one definition.
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.
Amazingly enough, I manage to write code that is non-standard
conforming that works as expected on multiple platforms. Because I
know enough about the C language and its implementation-defined
aspects.

For a current product I designed a communications protocol for an
internal CAN network. And I wrote code to implement that protocol.
That code is most certainly not 100% strictly conforming standard C.

But that somewhat non-standard code compiles and runs correctly on
four different processor types that interface to that bus:

1. An 8-bit big-endian microcontroller (8051 architecture). Chars
have 8 bits and plain char is signed.

2. A 16-bit big-endian microcontroller (Motorola HC11 architecture).
Chars have 8 bits and plain char is signed.

3. A 16/32 bit little endian DSP (Texas Instruments 28xx
architecture). Chars have 16 bits and plain char is signed.

4. A 32 bit little-endian RISC processor (ARM9). Chars have 8 bits
and plain char is unsigned.

Now I won't say there wasn't a little debugging involved, but I knew
when I wrote it that the entire code for protocol, including parse
tables, parameter packing and unpacking from CAN packet octet streams,
and all the rest, would work on all four of these architectures when I
wrote it.

The routine that converts between individual octets and 8, 16, and 32
bit signed or unsigned variables runs unchanged on all four platforms,
even the DSP which actually can't address memory in less than 16 bit
chunks.
What percent of non-trivial programs are completely ANSI C (i.e. they work
You entirely miss the point. What percentage of all trivial and
non-trivial C program, no matter how platform specific they are, could
be written in completely standard C? I doubt if you would ever find a
non-trivial program where this figure is less than 50%. Even in many
large programs with loads of extensions, if is frequently above 90%.
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.
Again you have it wrong. The question is not what fraction of
programs are nothing but 100% strictly conforming C. The question is
the average part of all programs that is, or could be, standard C.
And that fraction is very high indeed.
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
One who is not sufficiently experienced in writing C programs properly
should not be employed to do so, except perhaps as an apprentice, and
should not claim to be a professional C programmer.
time to accumulate the knowledge necessary to do so. Thus, in the business
world, it is not considered good practice, since time = money.
Yes, the biggest problem with software in general is not C or C++ or
Pascal or Visual Basic or any other programming language. It is
programmers who believe like you, that business is served by shoddy
guesses and half-baked efforts.

Would you want to fly on an airliner engineered by aviation engineers
who had their attitude about learning their discipline and doing
design work that you express toward writing software?

Would you want to be operated on by a surgeon who decided that
performing quality surgery is too time-consuming to learn, and
couldn't be bothered to take the time to accumulate the knowledge
necessary, because "it is not considered good practice, since time =
money".
There is a field of study you might call "software development", which is


There is a field of study that is called "software engineering", and
there is extensive research, much of it headed up by the US government
funded Software Engineering Institute at Carnegie-Melon University.

Engineering is a discipline, and there is sadly far too little
discipline in software development. The field is too new, the growth
too fast.

[snip]

This is very far afield from the main thrust of your post, however.

You think there is value in diluting comp.lang.c to throw in
discussions about anything anyone is trying to do with any C compiler
anywhere. I, and many of other the regulars, disagree.

It makes no difference whether you are writing C for a PIC
microcontroller, a Cray supercomputer, a game console, or an
"ordinary" Windows or Macintosh PC. A large percentage of the code
should be or at least could be perfectly standard legal C. And aside
from platform-specific issues that have nothing to do with the topic
of this group, that is the C language, a certain percentage of the
problems in even the most platform-specific program will be C language
issues.

Usenet groups that can't stay focused on a topic die. Our "sister"
group comp.lang.c++ nearly had that experience about five years ago,
where swarms of MFC and Windows specific newbies caused many of the
most knowledgeable regulars to leave. Fortunately, a group of
determined regulars turned back the tide barely in time, and
comp.lang.c++ is a valuable resource for C++ programmers today.

In point of fact, some of the regulars in comp.lang.c are among the
most knowledgeable C programmers in the world, at least among those
who chose to offer aid and advice publicly for free. Destroy the
topicality of the group, and you drive away that expertise.

So if you want to discuss platform-specific aspects of your code, take
it to the appropriate platform-specific support group. But when you
have a truly complex C language issue, be glad this group is here for
you to post it, because if it is really difficult you have a better
chance of correct help here than anywhere else on Earth.

And keeping this group on-topic is the best way to ensure that this
resource remains available.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Nov 13 '05 #36

P: n/a
On Tue, 4 Nov 2003 19:35:23 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote in comp.lang.c:
Roose wrote:
"pete" <pf*****@mindspring.com> wrote in message
news:3F***********@mindspring.com...
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.


Since no implementation is required by the Standard to accept a void main
program, it would be folly to write such a program (freestanding
implementations notwithstanding).


I have to disagree with your parenthetical comment.

"int main()" works, and "void main()" may or may not, on a conforming
hosted environment, because the behavior of calling a function is
undefined if the signature, which includes both arguments and return
type, does not match between caller and callee.

There happen to be quite a few compilers for embedded systems which
come under the category of free-standing implementations. It is not
uncommon for such implementations to specify that the user-written
start-up function signature should be "void main()", generally "void
main(void)", as there are never anything like command line arguments
in such environments.

If such a compiler specifies that user programs should start with
"void main()", then starting one with "int main()" is just as much
incorrect as using "void main()" instead of "int main()" in a hosted
environment.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Nov 13 '05 #37

P: n/a
Jack Klein wrote:
On Tue, 4 Nov 2003 19:35:23 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote in comp.lang.c:
Roose wrote:
> "pete" <pf*****@mindspring.com> wrote in message
> news:3F***********@mindspring.com...
>> 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.
Since no implementation is required by the Standard to accept a void main
program, it would be folly to write such a program (freestanding
implementations notwithstanding).


I have to disagree with your parenthetical comment.


Well, you might just be disagreeing with the word "notwithstanding", which
-as a quick check of the dictionary reveals - doesn't mean quite what I
thought it meant. :-% I intended it to mean "not being included in my
sweeping generalisation". English was never my strong point.

There happen to be quite a few compilers for embedded systems which
come under the category of free-standing implementations. It is not
uncommon for such implementations to specify that the user-written
start-up function signature should be "void main()", generally "void
main(void)", as there are never anything like command line arguments
in such environments.
Yes, and I was /trying/ to exclude such implementations from my more
sweeping comment. That is, I believe that we...
If such a compiler specifies that user programs should start with
"void main()", then starting one with "int main()" is just as much
incorrect as using "void main()" instead of "int main()" in a hosted
environment.


....no, I am now /sure/ that we are in agreement.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"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
Nov 13 '05 #38

P: n/a
On Wed, 5 Nov 2003 04:39:05 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote in comp.lang.c:
Jack Klein wrote:


[snip]
I have to disagree with your parenthetical comment.


Well, you might just be disagreeing with the word "notwithstanding", which
-as a quick check of the dictionary reveals - doesn't mean quite what I
thought it meant. :-% I intended it to mean "not being included in my
sweeping generalisation". English was never my strong point.


You Brits never could write (or speak) no good 'Nited States!

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
Nov 13 '05 #39

P: n/a
Let me thank you first for making a reasoned argument. My time is not
unlimited, so let me ignore the vast majority of responses and focus on the
ones such as this that rely logical argument -- AND acknowledge the
existence of life outside the newsgroup.

"Steve Summit" <sc*@eskimo.com> wrote in message
news:bo**********@eskinews.eskimo.com...
Roose wrote:
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.
Sure, but none of us -- you, I, or Ian -- is talking to or about
that earlier programmer. We're talking about us -- you, me, and
anyone else who happens to be listening, who we'd like to convince
to do better than the earlier programmer.


OK, I think the real point was lost somewhere there, but my contention is
that ANSI C being "better" is dependent on the situation, and not an
absolute fact.
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?


If I cared about the long-term maintainability of the company's
code base, and if my programmers were insufficiently competent to
so maintain it, I might schedule some time for those programmers
to learn the necessary skills.


Right, let me suggest that if you were a manager -- with limited budget as
always -- that training programmers to write ANSI C and converting old code
to ANSI C would often be on your cut list. Also, if you were a hiring
manager, I would suggest that it is often the case that one programmer who
does not "care" about ANSI C would often suit your purposes better than
another that does.
Point taken, but I still contend that portability is a feature.
It costs extra to make code ANSI compliant.


The same can be said about any feature, meaning that the way to
save the most money is presumably not to try to write the code at
all.


Also correct, but my contention is that other features fair better in a
cost/benefit analysis than (often speculative) portablity. Other features
cost money as well, but they also generate money. Writing ANSI C for a
single device does not, in general, generate any money.
If the short-term costs of coding portably truly don't promise
any long-term benefits, or if you're trapped by deadline
pressures under which you don't have time to do things right
(though you might have time to do them again), you might decide
you can't afford the portability.
I think this decision is made fairly often in the business world. But if
you have experience that demonstrates otherwise, I'd be interested to hear
about it.
But for those of us who are used to doing it, the short-term cost
of the kinds of portability we're talking about here is zero.
What percentage of programmers do you think are used to doing it?
(Honestly, I am not sure of the answer). If you were a hiring manager,
wouldn't this unnecessarily limit your pool of applicants if you were to
insist on it?
The nicely portable code flows out of our fingers as easily
as the nonportable code, that you seem to be trying to condone,
fumbles out of the fingers of those hypothetical earlier
programmers. The question is -- which kind of programming are
we trying to encourage? And if we constantly give everyone carte
blanche to write code which falls down on the various software
virtues -- portability, maintainability, correctness, repeatability,
predictability, efficiency -- if every day we let them get away
with that which is merely expedient, when will we collectively
ever learn to do better?
I would say that the last 4 virtues you mention are _absolute_ virtues,
while the former is a business decision. I completely agree that we should
strive to do better -- but our time is limited, and focusing on one thing
comes at the expense of others. I would much rather (and my boss would much
rather me) learn a new rendering technique, rather than study the ANSI C
standard. I would much rather write a unit test than make my code ANSI
compliant.
The expediency you seem to be condoning is responsible for many
of the ills in software development. I understand that you're
willing to make tradeoffs in favor of expediency at the expense
of other virtues, but what always puzzles me is why you and so
many posters before you keep coming in here and insisting that
the rest of us are wrong for making, or advocating, a different
set of tradeoffs.
I'm not saying you're wrong, but rather I'm objecting to the extremely
narrow focus demonstrated in this newsgroup. The posts come at the expense
of the larger question -- in recent threads the larger questions being
answering an interview question (so as to demonstrate knowledge), and also
helping a newbie learn C. Many people have already stated that newbies are
welcomed here. In that case, it would be prudent to address them in a
manner that they can understand, rather than turning them off to the C
language with nitpicking. I would also contend that learning strict ANSI C
is not the first step for a beginning C programmer. There is enough
challenge in getting a working program together.
Software engineering is still a pretty flimsy discipline.
For the most part, we're all slogging along through the mud,
often waist deep, often falling on our faces in it. Yet when one
of the sloggers dares to suggest that we invent paved roads, and
wheeled vehicles to move swiftly and easily on them, someone else
derides this vision as an ivory-tower fantasy, ungrounded in the
real world. 'Tis sad.


Completely agree. However, I would say that the line-by-line deficiencies
in code (e.g. non-ANSI code) are completely and utterly overshadowed by the
lack of design knowledge by the average programmer. Attack the worst of the
ills first. And the one that has the most effect on maintainability and
understandability of code is the fact that your average codebase is filled
with faulty abstractions, or, sadly, none at all.

Roose
Nov 13 '05 #40

P: n/a
Mark McIntyre <ma**********@spamcop.net> scribbled the following:
On Tue, 04 Nov 2003 05:40:15 GMT, in comp.lang.c , "Roose"
<no****@nospam.nospam> wrote:
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"

This is a stupid statement. In the Real World, which you seem not to
inhabit, computer programs interact with their surroundings. This
interaction is by definition Implementation Specific, and consequently
not part of the C language. Naturally there are parts of what we all
write that are not C. So what?


I actually find that statement quite funny. Roose's boss would fire him
if he wrote 100% ANSI C code? I.e. Roose's boss is *forcing* him to be
non-portable? Out of practical reasons, or out of principle?
If it's the latter, then I can imagine some quite funny situations:

Roose's boss: "Roose, I just found out that you wrote this program:
#include <stdio.h>
int main(void) {
unsigned long l=0;
while (getchar()!=EOF) l++;
printf("%ul\n", l);
return 0;
}
to count the number of bytes in a file. Don't you see it's 100%
ANSI C code?"
Roose: "Oh, sorry, boss. I'll change that to void main(void)."
Roose's boss: "Thanks."

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates
Nov 13 '05 #41

P: n/a
Joona I Palaste wrote:
Mark McIntyre <ma**********@spamcop.net> scribbled the following:
On Tue, 04 Nov 2003 05:40:15 GMT, in comp.lang.c , "Roose"
<no****@nospam.nospam> wrote:
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"

<snip>
I actually find that statement quite funny. Roose's boss would fire him
if he wrote 100% ANSI C code? I.e. Roose's boss is *forcing* him to be
non-portable? Out of practical reasons, or out of principle?
If it's the latter, then I can imagine some quite funny situations:

Roose's boss: "Roose, I just found out that you wrote this program:
#include <stdio.h>
int main(void) {
unsigned long l=0;
while (getchar()!=EOF) l++;
printf("%ul\n", l);
return 0;
}
to count the number of bytes in a file. Don't you see it's 100%
ANSI C code?"
Roose: "Oh, sorry, boss. I'll change that to void main(void)."
Roose's boss: "Thanks."


Roose's correct response would be "No, boss, sorry to contradict you but
look at the printf! See?" I'm passing in an unsigned long, but the format
specifier is %ul instead of %lu; I reckon that's got to be an
implementation-defined at best, and quite possibly a genuine undefined!"

--
Richard Heathfield : bi****@eton.powernet.co.uk
"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
Nov 13 '05 #42

P: n/a
> If you stop to think about it, this is a pretty meaningless
statement. Take out the words "truly standard C as valued by the
regulars in this newsgroup" and replace them by any positive
attribute of code you can think of:

Writing functional code is time-consuming if you're not experienced.
Writing maintainable code is time-consuming if you're not experienced.
Writing compact code is time-consuming if you're not experienced.
Writing efficient code is time-consuming if you're not experienced.
Writing correct code is time-consuming if you're not experienced.

Are all of these, then, "not considered good practice" in the
business world?
As I said in the previous post, in many environments, it doesn't produce
benefits that are proportional to the time it takes, or the cost of hiring
people who can do it with no additional time involved.

The other positives are of course worth their cost in all situations. Or at
least, they can be evaluated by the same metric... e.g. if I spend time
optimizing this code, what real benefit do I get? Does it matter?
There is a notion called "speculative generality"... This is
basically when you write code that speculates on what you may...
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.


And this is a very tricky set of ideas to think properly about.
Yes, sometimes when you overengineer something you're wasting
resources which could be better spent elsewhere, no question.


Yes, thanks for acknowledging at least a basic point from me, which many
others have been loathe to do.
But other times, a certain level of overengineering is not just
good practice, it's mandatory. In the real world, for example,
it's not "overengineering" to build a structure to withstand a
severe storm. To build a house that can withstand exactly the
weather conditions you're experiencing today, but which falls
down during the first rain or windstorm, would be folly.
Well, of course this is subject to individual programmer discretion,
unfortunately. If only there were an objective set of criteria to determine
if something is overengineered. Personally though, most people think my
code is a little overengineered, and I think theirs is underengineered. But
it falls within the domain of "reasonable", where reasonable developers can
agree, where as strict ANSI C as promoted by this newsgroup sometimes does
not.
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...


I don't think anyone here is advocating always writing code which
tries to be portable to machines with 9 bit bytes. (Personally,
I don't even know how to.) Your other examples are even more
absurd, since no C program (let alone a portable one) can even
tell how many stacks there might be.


Well, the claim here has been that if you write strict ANSI C, then it will
be portable to a machine with 9 bit bytes or no stack, with no additional
effort. No?
Writing 100% ANSI C when you are not in a special circumstance
(like the one I listed above) is considered speculative generality...
Even if you DO have a forseeable need for it, it is considered good
practice to solve _only the problem at hand_.


You keep saying, "is considered". Is considered by *who*?
By you? By the managers at the software companies that foist upon
the world laughably insecure, virus-infested operating systems,
and word processors that perform functions that no sane person
would require of them and ("Ford added savagely") go beep to tell
you when they've done it? They can have their opinions of what
"is considered" good practice, thank you; me, I think I'll use my own.


My first statement is what we're disputing, which you have given good
arguments for. My second, I would say "is considered" so by capable
experts.
Business requirements are extremely volatile. Executives are fickle.


Programmers who let executives tell them how to write their code
are jointly responsible for the unmaintainable failures they go on
to create.


I agree, but in a different context. As I said in the previous post, the
lack of high-level design contributes much more to unmaintainability than
the failure to write ANSI C. This is a huge problem where I work. The
schedule pressures force hacks upon hacks, rather than rethinking the
original design to meet new requirements. ANSI C is not even on the table.

Roose
Nov 13 '05 #43

P: n/a
Richard Heathfield <do******@address.co.uk.invalid> scribbled the following:
Joona I Palaste wrote:
I actually find that statement quite funny. Roose's boss would fire him
if he wrote 100% ANSI C code? I.e. Roose's boss is *forcing* him to be
non-portable? Out of practical reasons, or out of principle?
If it's the latter, then I can imagine some quite funny situations:

Roose's boss: "Roose, I just found out that you wrote this program:
#include <stdio.h>
int main(void) {
unsigned long l=0;
while (getchar()!=EOF) l++;
printf("%ul\n", l);
return 0;
}
to count the number of bytes in a file. Don't you see it's 100%
ANSI C code?"
Roose: "Oh, sorry, boss. I'll change that to void main(void)."
Roose's boss: "Thanks."
Roose's correct response would be "No, boss, sorry to contradict you but
look at the printf! See?" I'm passing in an unsigned long, but the format
specifier is %ul instead of %lu; I reckon that's got to be an
implementation-defined at best, and quite possibly a genuine undefined!"


Damn. s/ul/lu/ then. I hope I got my point across nonetheless. I *knew*
someone would make a point like that. Writing 99.999999999999999999999%
ANSI C code is easy, all you really have to do (once you're a good
programmer) is avoid anything that smells of hardware, or OS specifics.
But writing *100%* ANSI C code is surprisingly tricky.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd
Nov 13 '05 #44

P: n/a

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bo**********@oravannahka.helsinki.fi...
Roose's boss: "Roose, I just found out that you wrote this program:
#include <stdio.h>
int main(void) {
unsigned long l=0;
while (getchar()!=EOF) l++;
printf("%ul\n", l);
return 0;
}
to count the number of bytes in a file. Don't you see it's 100%
ANSI C code?"
Roose: "Oh, sorry, boss. I'll change that to void main(void)."
Roose's boss: "Thanks."
Roose's correct response would be "No, boss, sorry to contradict you but
look at the printf! See?" I'm passing in an unsigned long, but the

format specifier is %ul instead of %lu; I reckon that's got to be an
implementation-defined at best, and quite possibly a genuine undefined!"


Damn. s/ul/lu/ then. I hope I got my point across nonetheless. I *knew*
someone would make a point like that. Writing 99.999999999999999999999%
ANSI C code is easy, all you really have to do (once you're a good
programmer) is avoid anything that smells of hardware, or OS specifics.
But writing *100%* ANSI C code is surprisingly tricky.


Yes, thank you for providing a great example of what I'm taking about. To
all those responded with reasoned responses, this is what I claim is not
reasonable from a business perspective. Again I claim if I went through my
code looking for %ul and replacing it with %lu, it would not be looked upon
highly.

Roose
Nov 13 '05 #45

P: n/a

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:d2********************************@4ax.com...
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

Your "real world" is most certainly not the same as my "real world".
One of the world's most used C compilers, gcc, has a command line
switch to compile FORTRAN. That's a "real world" use of a C compiler.
But it has nothing to do with the C language, which has one and only
one definition.
Not sure what the point of the fortran example is exactly, but I'm talking
about people who, at the expense of answering anyone's _real_ question,
ignore anything not related strictly to ANSI C, and instead inundate them
with irrelevant details about ANSI C. Again my claim is that -- regardless
of whether they are right to come here -- a lot of newbies do, and get
turned off to the C language. Yes, I've already heard all the responses
about reading the FAQ and such, and I maintain my position regardless.
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.


Amazingly enough, I manage to write code that is non-standard
conforming that works as expected on multiple platforms. Because I
know enough about the C language and its implementation-defined
aspects.


I do that too, and I suspect many others do. Which is why the extremely
narrow focus on ANSI C limits the utility of this newsgroup for your average
C programmer. As I said, in the game I'm working is portable across PS2,
GameCube, and Xbox, but it is decidely not ANSI C. We use non-standard
extensions like 0-length arrays and such.

I don't know for sure how common this extension is, but I think it is
extremely common, since it seems to be a case that would just "fall out" of
a compiler, requiring no extra code. If not, replace it with something else
that is not standard but nearly universal. (If there is no such thing,
suppose there is such a thing).

Then I claim that using such a thing is fine business practice, its ANSI
compliance notwithstanding. (Oh let the flames begin, again...) Contrary
to what seems to be espoused on this newsgroup, someone who uses such an
extension, is not ignorant or stupid or contributing to the
unmaintainability of his codebase.

If an extension provides a reasonable benefit, and is reasonably common,
then it in effect a useful part of a _de facto standard_ (*gasp* : ) ). I
suggest that one might use such an extension and get the benefit, while
incurring the cost of removing it when business dictates that you port to a
platform that doesn't support it (which may or may not ever happen).
For a current product I designed a communications protocol for an
internal CAN network. And I wrote code to implement that protocol.
That code is most certainly not 100% strictly conforming standard C.

But that somewhat non-standard code compiles and runs correctly on
four different processor types that interface to that bus:

1. An 8-bit big-endian microcontroller (8051 architecture). Chars
have 8 bits and plain char is signed.
Sounds cool.
What percent of non-trivial programs are completely ANSI C (i.e. they work
You entirely miss the point. What percentage of all trivial and
non-trivial C program, no matter how platform specific they are, could
be written in completely standard C? I doubt if you would ever find a
non-trivial program where this figure is less than 50%. Even in many
large programs with loads of extensions, if is frequently above 90%.
OK, point taken. I will discuss the proportions of code in a project that
is ANSI C from now on.
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
One who is not sufficiently experienced in writing C programs properly
should not be employed to do so, except perhaps as an apprentice, and
should not claim to be a professional C programmer.
See my responses to Steve Summit... if you were a hiring manager, would you
limit your applicant pool in such a way, when it is clear that people who
are not completely familiar with strict ANSI C would be capable of meeting
the business objectives?
time to accumulate the knowledge necessary to do so. Thus, in the business world, it is not considered good practice, since time = money.


Yes, the biggest problem with software in general is not C or C++ or
Pascal or Visual Basic or any other programming language. It is
programmers who believe like you, that business is served by shoddy
guesses and half-baked efforts.


I don't see how this follows. Because I don't place high importance on ANSI
C does not mean I advocate "shoddy guesses and half-baked efforts". As I
have written elsewhere, I write for specific platforms, and choose to spend
my time on more important considerations like program architecture, rather
than the line-by-line details of individual pieces of code.
Would you want to fly on an airliner engineered by aviation engineers
who had their attitude about learning their discipline and doing
design work that you express toward writing software?

Would you want to be operated on by a surgeon who decided that
performing quality surgery is too time-consuming to learn, and
couldn't be bothered to take the time to accumulate the knowledge
necessary, because "it is not considered good practice, since time =
money".
These arguments don't mean much to me. As I said, time spent in one place
is not spent in another. I claim that, in many typical business situations,
when you are writing for specific platforms, ANSI C is not worth the time.
The time is much better spent learning your domain, whether it is airliner
hardware or medical equipment. Also, as I said, there much more important
general software development considerations, like writing unit tests,
improving your build process, training engineers in design principles, etc.

I am very doubtful of the methodology of preventing bugs a priori by using
ANSI C, as contrasted with spending the resources on proper QA, which many
organizations fail to do. Indeed, I would suspect that you asked
programmers of airliners and medical equipment, they would say their
_quality bottleneck_ is in QA and unit testing, rather than in ANSI C
conformance.

So where do you think the bottleneck typically is?
There is a field of study you might call "software development", which

is
There is a field of study that is called "software engineering", and
there is extensive research, much of it headed up by the US government
funded Software Engineering Institute at Carnegie-Melon University.

Engineering is a discipline, and there is sadly far too little
discipline in software development. The field is too new, the growth
too fast.
Agreed.
This is very far afield from the main thrust of your post, however.

You think there is value in diluting comp.lang.c to throw in
discussions about anything anyone is trying to do with any C compiler
anywhere. I, and many of other the regulars, disagree.

It makes no difference whether you are writing C for a PIC
microcontroller, a Cray supercomputer, a game console, or an
"ordinary" Windows or Macintosh PC. A large percentage of the code
should be or at least could be perfectly standard legal C. And aside
from platform-specific issues that have nothing to do with the topic
of this group, that is the C language, a certain percentage of the
problems in even the most platform-specific program will be C language
issues.

Usenet groups that can't stay focused on a topic die. Our "sister"
group comp.lang.c++ nearly had that experience about five years ago,
where swarms of MFC and Windows specific newbies caused many of the
most knowledgeable regulars to leave. Fortunately, a group of
determined regulars turned back the tide barely in time, and
comp.lang.c++ is a valuable resource for C++ programmers today.


I agree with many of your points in this argument, but let me also mention
all the newbies who get jumped on by the regulars. This is not a few
people -- pretty much in any screenful of threads, I see it happening.

But let me say that this is not as interesting a discussion as the first
point about whether the value of ANSI C compliance is extremely dependent on
business objectives, and not an end in itself. I acknowledge your points,
and suggest that there should be a group called comp.lang.ansi-c or
whatever, but I will admit with the attitude here, that is not likely to
happen. ANSI C is a limited part of C in the real world, and thus the name
comp.lang.c is misleading, which is (part of the reason) why there are so
many off-topic posts here. And I already suggested that there is already a
perfectly good group, CLC.moderated, that has a fine mechanism for
_enforcing_ topicality -- a much more efficient mechanism than regular
flamewars.

Roose
Nov 13 '05 #46

P: n/a
"Roose" <no****@nospam.nospam> writes:
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bo**********@oravannahka.helsinki.fi...
> Roose's boss: "Roose, I just found out that you wrote this program:
> #include <stdio.h>
> int main(void) {
> unsigned long l=0;
> while (getchar()!=EOF) l++;
> printf("%ul\n", l);
> return 0;
> }
> to count the number of bytes in a file. Don't you see it's 100%
> ANSI C code?"
> Roose: "Oh, sorry, boss. I'll change that to void main(void)."
> Roose's boss: "Thanks."

Roose's correct response would be "No, boss, sorry to contradict
you but look at the printf! See?" I'm passing in an unsigned long,
but the format specifier is %ul instead of %lu; I reckon that's
got to be an implementation-defined at best, and quite possibly
a genuine undefined!"


Damn. s/ul/lu/ then. I hope I got my point across nonetheless. I *knew*
someone would make a point like that. Writing 99.999999999999999999999%
ANSI C code is easy, all you really have to do (once you're a good
programmer) is avoid anything that smells of hardware, or OS specifics.
But writing *100%* ANSI C code is surprisingly tricky.


Yes, thank you for providing a great example of what I'm taking about. To
all those responded with reasoned responses, this is what I claim is not
reasonable from a business perspective. Again I claim if I went through my
code looking for %ul and replacing it with %lu, it would not be looked upon
highly.


Why not? Don't you believe in fixing bugs?

Are you assuming that "%ul" happens to work as a format for unsigned
long on most implementations, and converting it to the more
standard-compliant "%lu" would be a waste of time?

In fact, "%ul\n" is a valid printf format; the "%u" converts an
unsigned int, and the "l" is a literal lower case letter L.
The statement

printf("%ul\n", l);

if l is equal to 42, will print "42l" followed by a newline. The bug
might even be missed in testing if it's misread as 421.

I'm just making a guess about what you were assuming; if I was
mistaken, can you clarify your point?

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 13 '05 #47

P: n/a
Keith Thompson <ks*@cts.com> scribbled the following:
"Roose" <no****@nospam.nospam> writes:
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bo**********@oravannahka.helsinki.fi...
> >> Roose's boss: "Roose, I just found out that you wrote this program:
> >> #include <stdio.h>
> >> int main(void) {
> >> unsigned long l=0;
> >> while (getchar()!=EOF) l++;
> >> printf("%ul\n", l);
> >> return 0;
> >> }
> >> to count the number of bytes in a file. Don't you see it's 100%
> >> ANSI C code?"
> >> Roose: "Oh, sorry, boss. I'll change that to void main(void)."
> >> Roose's boss: "Thanks."
>
> > Roose's correct response would be "No, boss, sorry to contradict
> > you but look at the printf! See?" I'm passing in an unsigned long,
> > but the format specifier is %ul instead of %lu; I reckon that's
> > got to be an implementation-defined at best, and quite possibly
> > a genuine undefined!"
>
> Damn. s/ul/lu/ then. I hope I got my point across nonetheless. I *knew*
> someone would make a point like that. Writing 99.999999999999999999999%
> ANSI C code is easy, all you really have to do (once you're a good
> programmer) is avoid anything that smells of hardware, or OS specifics.
> But writing *100%* ANSI C code is surprisingly tricky.
Yes, thank you for providing a great example of what I'm taking about. To
all those responded with reasoned responses, this is what I claim is not
reasonable from a business perspective. Again I claim if I went through my
code looking for %ul and replacing it with %lu, it would not be looked upon
highly.


You have missed my point. You said "My boss would fire me if I wrote
100% ANSI C code". I asked if this is because he hates 100% ANSI C
code in itself, or he hates his workers trying to perfect their code
into 100% ANSI C.
I gave an example of the former, while your reply concerns the latter.
Which is it?
Why not? Don't you believe in fixing bugs? Are you assuming that "%ul" happens to work as a format for unsigned
long on most implementations, and converting it to the more
standard-compliant "%lu" would be a waste of time? In fact, "%ul\n" is a valid printf format; the "%u" converts an
unsigned int, and the "l" is a literal lower case letter L.
The statement printf("%ul\n", l); if l is equal to 42, will print "42l" followed by a newline. The bug
might even be missed in testing if it's misread as 421. I'm just making a guess about what you were assuming; if I was
mistaken, can you clarify your point?


If Roose's boss thinks there's no difference between "42l" and "42" (as
output strings), then good for him, but I don't want to work in that
company.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"To err is human. To really louse things up takes a computer."
- Anon
Nov 13 '05 #48

P: n/a
On 2003-11-05, Roose <no****@nospam.nospam> wrote:

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:bo**********@oravannahka.helsinki.fi...
>> Roose's boss: "Roose, I just found out that you wrote this program:
>> #include <stdio.h>
>> int main(void) {
>> unsigned long l=0;
>> while (getchar()!=EOF) l++;
>> printf("%ul\n", l);
>> return 0;
>> }
>> to count the number of bytes in a file. Don't you see it's 100%
>> ANSI C code?"
>> Roose: "Oh, sorry, boss. I'll change that to void main(void)."
>> Roose's boss: "Thanks."

> Roose's correct response would be "No, boss, sorry to contradict you but
> look at the printf! See?" I'm passing in an unsigned long, but the format > specifier is %ul instead of %lu; I reckon that's got to be an
> implementation-defined at best, and quite possibly a genuine undefined!"


Damn. s/ul/lu/ then. I hope I got my point across nonetheless. I *knew*
someone would make a point like that. Writing 99.999999999999999999999%
ANSI C code is easy, all you really have to do (once you're a good
programmer) is avoid anything that smells of hardware, or OS specifics.
But writing *100%* ANSI C code is surprisingly tricky.


Yes, thank you for providing a great example of what I'm taking about. To
all those responded with reasoned responses, this is what I claim is not
reasonable from a business perspective. Again I claim if I went through my
code looking for %ul and replacing it with %lu, it would not be looked upon
highly.


You mean your employer would accept the letter ell attached to the ends
of unsigned output?

BTW, the above is not a personal attack. It is an example of the kind
of pedantry that is practiced in comp.lang.c.

Actually, I would like to apologize if my "Princess Bride" parody
offended you (or anyone else reading the newsgroup). Half of it was
tongue-in-cheek, but perhaps it didn't come across that way. It may
have inadvertently fanned the flames, which I did not mean to do. The
serious point of the message was that perhaps you needed to spend some
more time reading through the kinds of posts in the newsgroup before
contributing. The humourous point (which may have been lost on you and
others due to not getting the reference) was that you were behaving like
a Humperdink.

The kind of battle you are waging now has been waged many times here in
the past. I imagine the old-timers on this newsgroup are quite frankly
tired of arguing the point yet again.

(http://groups.google.com/groups?q=to...%3Acomp.lang.c)

To me, at least, you are simply pointing out the obvious when you say
that most useful programs are not "100% ANSI C", and quite frankly
that point is a yawner. We already know that. It doesn't mean you
shouldn't try to write the code that is platform independent to be as
close to ANSI C as you know how. Steve Summit has already elucidated
the benefits. This newsgroup is great resource for learning how to do
it better.

As to beginners who are learning how to code in C, it is my belief that
it is very important that they understand Standard C before they learn
platform specific programming. This is because a programming language
is supposed to provide an abstraction over a platform, and to maintain
encapsulation, the beginner should be shielded from the platform.
This allows the beginner to apply the newly obtained C programming
knowledge on any platform.

When fresh graduates who are well-grounded in Standard C go off into the
real world to become neo-professional C programmers, their knowledge
will be applicable to any C programming job, modulo the platform
specific interfaces they need to know for the particular position they
are applying.

If you use a single particular platform (such as an x86 based PC)
to provide platform specific examples as a way of grounding the
abstractions, this creates a dangerous situation where students will
likely generalize with insufficient information. This can cause them to
go into the workforce woefully misinformed and unprepared, and you end
up having to retrain them both in C programming and in the platform
specific interfaces of their job.

Or worse, they can't obtain or hold a job.

Common problems from over generalizations:
* assumptions about the size of the int type.
* assumptions about the behavior of modifying a variable and reading
its value between two sequence points.
* assumptions about the order of evaluation of function parameters.

By advocating that programmers should simply hack away on their systems
paying little to no heed to portability (and pay the price of porting
later), you only further propogate the harm that generalizing with
insufficient information can do. When the code is later ported,
you also get the bonus problems of (1) less maintainable code, and
(2) introducing quirky problems that are not easily reproducible or
identifiable due to incorrect assumptions about what the code means.
(Both of the numbered problems above are of course avoided if of the
port effort also includes scheduled time to carefully paying attention
to standards and actually clean up the portability issues.)

Or worse, the buggy code gets shipped because the defect could not be
isolated, and the bug actually causes tangible harm to the consumer of
the software system.

Coding in Standard C will not alleviate all coding issues. But,
following the discipline helps train the programmer to think critically
about the program, and critical thinking is usually a good thing to
practice when the goal is a working software system.

In practical terms:

* do not write C code that invokes unspecified and undefined behaviors.
* be cognizant of utilizing implementation-defined and locale-specific
behaviors, and of utilizing common C language extensions. Isolate
them, and document their use so that future porting efforts are
reduced.

But in this newsgroup, I aim to provide solutions that do not require
implementation-defined behaviors. If there is no such solution, I may
discuss an implementation-defined solution, but I will also point out
the non-topicality of the thread and ask the OP to followup someplace
more appropriate.

-- James
Nov 13 '05 #49

P: n/a
Richard Heathfield wrote:
specifier is %ul instead of %lu;


Since becoming aware of my having made that mistake more than once,
I always call them "long unsigned"
instead of "unsigned long".

--
pete
Nov 13 '05 #50

100 Replies

This discussion thread is closed

Replies have been disabled for this discussion.