ANSI C compliance
Roose
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
Richard Heathfield
> 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 : bin...@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
Ian Woods
news:3ZGpb.13633$TH6....@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 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
Roose
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" <news...@wuggyNOCAPS.org> wrote in message
news:Xns94294FC6D5EC...@217.32.252.50...
> "Roose" <nos...@nospam.nospam> wrote in
> news:3ZGpb.13633$TH6....@newssvr14.news.prodigy.com:
> > 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
nobody
news:3ZGpb.13633$TH6....@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"
>
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暉損ar
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.
nobody
> 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).
Ian Woods
news:LoJpb.13669$uC.1...@newssvr14.news.prodigy.com:
> 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" <news...@wuggyNOCAPS.org> wrote in message
> news:Xns94294FC6D5EC...@217.32.252.50...
>> "Roose" <nos...@nospam.nospam> wrote in
>> news:3ZGpb.13633$TH6....@newssvr14.news.prodigy.com:
<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
Richard Bos
> 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
rihad
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.
Joona I Palaste
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 (pal...@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
Richard Bos
> Richard Bos <r...@hoekstra-uitgeverij.nl> scribbled the following:
> > "Roose" <nos...@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
Joona I Palaste
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 (pal...@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
goose
> 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,
Irrwahn Grausewitz
yet another irrelevant troll-post, filled with loads of non-arguments.
To whom it may concern
======================
Roose is an individual incapable of accepting the fact that his
attempts to take over comp.lang.c are futile. His posts are best
ignored, as they are either poor examples of usenet trolling or
contain misleading information, or both.
In order to get an idea what comp.lang.c is all about, it is strongly
suggested to read the following documents:
Welcome message for comp.lang.c, by Billy Chambless:
http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html
FAQ-list for comp.lang.c, maintained by Steve Summit:
http://www.eskimo.com/~scs/C-faq/top.html
Regards
--
Irrwahn
(irrw...@freenet.de)
pete
> 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
Alan Balmer
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
removebalmerc...@att.net
Roose
"pete" <pfi...@mindspring.com> wrote in message
news:3FA7B1...@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.
Richard Heathfield
> 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.
teken...@busthotmaile.rcom
> 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.
--
Tom St Denis
<teken...@BUSThotmailE.Rcom> wrote in message
news:1g3wkq0.3eq4hm1rxni40N%teken...@BUSThotmailE.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
Richard Heathfield
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
> Richard Heathfield <dont...@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.
Ben Pfaff
> Richard Heathfield <dont...@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
teken...@busthotmaile.rcom
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
> 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.
Randy Howard
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: postm...@sco.com
rihad
<dont...@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? :)
Dave Vandervies
rihad <ri...@mail.ru> wrote:
>Okay, who was it: Kaz Kylheku OR Chris Torek? :)
Quoth Google:
http://groups.google.com/groups?selm=slrn8pjb01.91v.kaz%40ashi.FootPrints.net
So it looks like it was Kaz.
dave
--
Dave Vandervies dj3v...@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
pete
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.
Mark McIntyre
<nos...@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 =---
Mark McIntyre
teken...@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
<nos...@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.
Steve Summit
> 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
s...@eskimo.com
Steve Summit
> 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
s...@eskimo.com
Steve Summit
> 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
s...@eskimo.com
Jack Klein
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
Jack Klein
<dont...@address.co.uk.invalid> wrote in comp.lang.c:
> Roose wrote:
> > "pete" <pfi...@mindspring.com> wrote in message
> > news:3FA7B1...@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.
Richard Heathfield
> On Tue, 4 Nov 2003 19:35:23 +0000 (UTC), Richard Heathfield
> <dont...@address.co.uk.invalid> wrote in comp.lang.c:
>
>> Roose wrote:
>> > "pete" <pfi...@mindspring.com> wrote in message
>> > news:3FA7B1...@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.
Jack Klein
<dont...@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!
Roose
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" <s...@eskimo.com> wrote in message
news:bo9l11$ig1$1...@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
Joona I Palaste
> On Tue, 04 Nov 2003 05:40:15 GMT, in comp.lang.c , "Roose"
> <nos...@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 (pal...@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
Richard Heathfield
> Mark McIntyre <markmc...@spamcop.net> scribbled the following:
>> On Tue, 04 Nov 2003 05:40:15 GMT, in comp.lang.c , "Roose"
>> <nos...@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!"
Roose
> 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
Joona I Palaste
> 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 (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd
Roose
"Joona I Palaste" <pal...@cc.helsinki.fi> wrote in message
news:boablh$88q$1...@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
Roose
"Jack Klein" <jack...@spamcop.net> wrote in message
news:d2ogqvok0csrpbiib...@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
Keith Thompson
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) k...@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"
Joona I Palaste
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 (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"To err is human. To really louse things up takes a computer."
- Anon
James Hu
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=topicality+group%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
pete
> 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
pete
> 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.
This newsgroup tends to assume "hosted" unless otherwise stated.
In free-standing implementations,
the main function, can be called anything.
I've worked on embedded, where the main function was called
"start_main_"
--
pete
Alan Balmer
>> 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.
Generalization does not always take extra time. In fact, I have found
that generalizing a problem often leads to a solution which is not
only extensible, but easier and cleaner to implement in the first
place.
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
Alan Balmer
wrote:
>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.
Sorry, wrong. Quality comes in the production of the product, not the
testing. I've not programmed for airliners, but I have programmed for
medical equipment, and I have done a great deal of programming for
mission- and life-critical process control. There's an excellent
chance that you are within reach of a plastic product produced in part
with my software, and to my knowledge, a PVC reactor hasn't exploded
for years.
It's a common saying that quality cannot be legislated by QA or tested
into a product by QC. Testing can show the presence of errors, but
cannot show the absence of errors.
ANSI/ISO C is not the be-all and end-all of quality programming, but
it's a valuable aid. While most programs in my world must use some
facilities that are outside the scope of the standard, it's no
problem, and no extra work, to write proper code for the 95% which can
be standard C. In fact, most of that other 5% is standardized as well,
conforming to POSIX, which has relatively high portability. I really
don't understand your contention that writing standard C where
possible costs more. In fact, for products with a reasonably long
lifetime, it's cheaper. In your limited world of game programming,
perhaps you just replace obsolete code. Most of us don't have that
luxury, and have to consider maintenance as part of the life-cycle
cost.
This is anecdotal, but I have done a great deal of C maintenance
programming, ever since the standard was approved (and written much
code we called C before that :-). and while doing that I have made a
lot of legacy code standard-conforming. Nearly every time I've done
that, I've uncovered bugs which would have been caught by a pedantic
compiler if the program had been written in standard C originally.
(Aside - it's amazing how customers will live with bugs for years and
how ingeniously they sometimes work around them. We've got 'em
trained.)
Bottom line is that this newsgroup discusses Standard C. That's what
we do here. It doesn't mean there aren't other things to discuss, it
just means that other things should be discussed in other places. If
you try that, you'll find than many of the folks here you've accused
of being narrow-minded and not knowing about the outside world also
participate in those other groups.
Have you looked at comp.programming, for example? They discuss much
wider issues than comp.lang.c.
Alan Balmer
wrote:
>and suggest that there should be a group called comp.lang.ansi-c or
>whatever,
Nope. C *is* ANSI-C. The standard is the very definition of C To me,
comp.lang means just that - discussions about the *language.* Not its
applications, not extensions to it, not libraries for it or algorithms
coded in it, but the language itself and its proper use. No confusion
there.
I think what you want is a group named comp.programming.c, and that
might actually be a good idea, though I wonder if the traffic would
justify subsetting comp.programming. You could work toward creating
such a group, and in the meantime, participate in its parent,
comp.programming (where you'll also find some of the c.l.c regulars,
being less pedantic ;-)
What you are *not* going to be able to do is hijack this newsgroup and
redefine it as what you want it to be. It is what it is.
Sheldon Simms
> Keith Thompson <k...@cts.com> scribbled the following:
>> "Roose" <nos...@nospam.nospam> writes:
>>>
>>> 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?
>
> 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.
No you misunderstand. Roose's boss wants bugs. That's the problem.
If Roose bothered to write correct code, then the development group
wouldn't fulfill their bug quota, and without a full bug quota the
testers wouldn't have anything do to, and the company might have to
release a product on time.
Roose
>
> 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?
Yes, that's what I was assuming, and I stand corrected. You mean you guys
don't test your code before posting it? : ) I will look for another
example of such a thing.
Roose
Mark Gordon
"Roose" <nos...@nospam.nospam> wrote:
> 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" <s...@eskimo.com> wrote in message
> news:bo9l11$ig1$1...@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.
Such instances are few and far between in my experience. Equally, my
experience is that writing code to be as portable as possible can often
save you time *BEFORE* you reach the deadline.
A REAL example:
Writing a significant chunk of embedded code. Since the code was as
portable as possible I ended up porting it to a Silicon Graphics
workstation and debugging it there because there were far better tools
available including the ability to read some aircraft attitude data and
the digitised video and overlay a line of the video indicating where my
software believed the horizon was. This saved a significant amount of
time on that particular project.
> > > 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,
Converting pre-ANSI code to ISO C is not required to write any
modifications in ISO C. By making such changes as you deal with the
relevant parts of the code you can gradually ease the burden of
maintenance without a significant bad effect on your immediate
timescales and budgets. I know this through personal experience just as
I know that gradually making the change can expose problems that only
occasionally cause the application to misbehave and allow you to fix
them.
> 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.
I would expect and good C programmer to be able to cope with pre-ANSI
code on a legacy project. I know this because I *AM* working on such a
project. I also know that the head of my SW department would far prefer
people who understand and care about standards compliant software than
those who don't care about it.
> > > 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 you know how to write portable code then my experience is that in
most cases it does not cost more than writing non-portable software.
> > 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.
See my comments above. All are based on real personal experience in the
defence and commercial worlds.
> > 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).
Anyone in the defence industry will have their code peer reviewed so it
only takes a few people for the word to slowly spread. Outside the
defence industry things are different.
Personally I learnt most of my C from K&R2 referring to the manuals for
the compiler when I needed to do something HW specific and *knowing*
that the HW specific stuff I was doing was specific to the
implementation as it was documented as such. This does not mean that I
did not introduce non-portable constructs by mistake in code I
considered to be portable, but it did bring things a long way towards
it.
> If you were a hiring
> manager, wouldn't this unnecessarily limit your pool of applicants if
> you were to insist on it?
As with everything, when recruiting you weigh the cost/benefit. If
someone is good enough and prepared to learn but does not know enough
about portable coding one might consider them just as one would reject
someone who could only write simple portable programs and was not
willing to learn.
> > 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.
Making your code ISO compliant can remove bugs you are not aware of and
your compiler can probably provide a lot of help in doing this and if
not you may be able to run it through gcc with maximal warnings to see
the issues. So you should at least try to see how close you are and
whether there is anything immediately critical that you can resolve as
*part* of your testing. Potentially you look through the optional
warnings s your compiler can generate and enable ones that are most
likely to show up real problems, such as -Wsequence-point on gcc.
You don't have to spend a lot of time/money in one go, 5 minutes per
day would be a start and could remove unexplained crashes that you
can't track down.
> > 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.
This group is about programming in C and not about implementation
specifics. If you don't like it then use another group. There are plenty
of places for discussing the specifics of any given implementation
where you will find a lot more expertise on that specific
implementation.
> 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.
A lot of helpful information was posted and people I know who *have*
been interviewers would have liked many of the answers.
> 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.
Accurate answers are given (and inaccurate ones corrected) and if
someone asks for further explanation it will be provided. Many people
*try* to pitch their answers at the apparent level of knowledge of the
person asking the question whilst still doing this.
> 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.
It is far easier to get a working program together if you set the
warning level on your compiler as high as possible and try to understand
and *resolve* the warnings (not just cast them away) than if you don't
do this. Such a method also leads you naturally in to producing ISO C
programs.
Also, trying to use libraries outside of those provided by the C
standard means you have *more* to learn and so makes the job harder.
However, we (or I at least) don't object to people new to see using the
simpler external libraries, it is just that we will direct them else
where for help with those libraries.
> > 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.
When I started my career I was not expected to do the design. Instead I
would be presented with the design (if there was any significant
complexity) and be asked to code it. Thus I was exposed to good design
at any given level before I was expected to do it, and when doing design
work or coding others would look at my work and provide help and advise
as required. IMHO this is a correct way to tackle the issue and allows
the learning of both good coding in ISO C and good design at the same
time.
I have also been in the position of mentoring fresh graduates and I
would gradually build up the complexity of what they were required to do
making sure they were heading in the right direction before letting them
loose.
> 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.
However, those ills are for other groups such as comp.unix.programmer,
although people do point out design flaws when reviewing code that is
posted here in order to move people in the right direction. Asking for
such help here is off topic, but providing it *whilst* dealing with the
C issues is considered acceptable based on what I've seen.
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.
Richard Heathfield
>> 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?
>
> Yes, that's what I was assuming, and I stand corrected.
Could you tell us about even one implementation on which %ul works as a
format for unsigned long? Or does your "I stand corrected" mean that you no
longer believe that /any/ implementations do this?
I ask merely for information.
> You mean you guys
> don't test your code before posting it? : ) I will look for another
> example of such a thing.
If you find a bug in code posted here, and no correction for that bug has
been posted, please do post a correction. You may be surprised by the
reaction. In fact, I urge you to look for bugs in code that I myself have
posted, partly for your own satisfaction, but also so that you can see the
kind of reaction that one can expect when posting a correction in this
newsgroup.
Part of the immense value of this newsgroup is the extraordinary attention
to detail displayed by its nit-pickers.
Richard Heathfield
<snip>
> 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.
The details are far from irrelevant in a C newsgroup. They might well be
considered irrelevant in a group such as comp.programming or sci.crypt.
> 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.
Doubtless you have independent and compelling statistical evidence to
support this assertion. Where is it?
<snip>
> 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?
I would consider hiring a person not familiar with C (which is my term for
what you call "strict ANSI C"), provided that they made up for this
deficiency in other relevant areas and provided that they were able to
demonstrate willingness to learn C.
<snip>
> 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.
Correct use of the C language sure beats the hell out of its incorrect use
when it comes to preventing bugs. And correct use of C is pretty much what
we discuss here.
<snip>
> ANSI C is a limited part of C in the real world,
Sure, if by "C in the real world" you mean "C together with a bunch of
libraries and extensions", but it's the core, the vital part of the
language, and it's essential to understand that core if one is to be an
effective C programmer.
> and thus the name comp.lang.c is misleading,
comp - computing
lang - language
C - C
I don't see anything misleading here. The key point is that C is defined by
an international standard, not by the misunderstandings and
platform-specific experiences of anyone who happens to drop into clc one
cold November evening when there's nothing good on television.
<snip>
Thomas Matthews
> On Wed, 05 Nov 2003 07:43:49 GMT
> "Roose" <nos...@nospam.nospam> wrote:
>
>
>>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" <s...@eskimo.com> wrote in message
>>news:bo9l11$ig1$1...@eskinews.eskimo.com...
>>
>>>Roose wrote:
>>>
> Such instances are few and far between in my experience. Equally, my
> experience is that writing code to be as portable as possible can often
> save you time *BEFORE* you reach the deadline.
>
> A REAL example:
> Writing a significant chunk of embedded code. Since the code was as
> portable as possible I ended up porting it to a Silicon Graphics
> workstation and debugging it there because there were far better tools
> available including the ability to read some aircraft attitude data and
> the digitised video and overlay a line of the video indicating where my
> software believed the horizon was. This saved a significant amount of
> time on that particular project.
>
In support, another Real World example:
I was working on code for an embedded laser printer. The task was
page control (sequencing, and resource aquisition). The code was
based on data input. Since resources were tight (i.e. 5 people shared
the same printer to work on), writing in ANSI C code allowed me to
debug the code on the PC using a debugger to single step through
the code (and setting appropriate variables). This debugging
process was often faster than trying to debug using the proprietary
debugger after waiting many hours for free time on a printer.
One note: Many of the real world programs have code that is platform
dependent. However, those portions can be confined to their own
modules and replaced by "stubs" for other platforms. In my case,
I used some stubs for platform specific functionality.
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
BruceS
"Richard Heathfield" <dont...@address.co.uk.invalid> wrote in message
news:bobjbl$63i$1...@sparta.btinternet.com...
> Roose wrote:
<snip>
> > 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.
>
> Doubtless you have independent and compelling statistical evidence to
> support this assertion. Where is it?
Statistical evidence is worthless in any scientific context. I have a much
better form---anecdotal, the second-best form. I can attest that, after
fifteen years of professional C programming, I started reading this group in
2001. I was a c.l.c. newbie although not a C newbie. I found, and continue
to find, c.l.c. to be a great source of information. Posters here have
corrected some of my misconceptions about C, that have led me to write far
too much code that works by accident. I'm sure c.l.c. has made me a better
programmer, and Richard is one of those (along with too many others to
mention, for fear of missing some) who has facilitated that. Even when I was
a C newbie, I found that getting correct information, even if it
contradicted my then-current understanding, was a benefit. What should scare
newbies away is the sheer volume of disinformation available here, requiring
a brief waiting period for corrections before accepting anything.
<snip>
Keith Thompson
> On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <nos...@nospam.nospam>
> wrote:
>
> >and suggest that there should be a group called comp.lang.ansi-c or
> >whatever,
>
> Nope. C *is* ANSI-C. The standard is the very definition of C To me,
> comp.lang means just that - discussions about the *language.* Not its
> applications, not extensions to it, not libraries for it or algorithms
> coded in it, but the language itself and its proper use. No confusion
> there.
Just to be pedantic, it's more accurate to refer to ISO C rather than
ANSI C. The 1989 ANSI standard was adopted, with some minor editorial
changes, as the 1990 ISO standard. The 1999 standard is
ISO/IEC 9899:1999. (I think it's also officially an ANSI standard;
ANSI is a member if ISO.)
The habit of referring to ANSI C (as opposed to K&R C, the language
defined in K&R 1st edition) originated when the ANSI standard was
being developed in the late 1980s. The term has stuck, but it's no
longer the most accurate one.
Mark McIntyre
<nos...@nospam.nospam> wrote:
>> 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 this is not the basic point you've been making at all. Steve is
talking about overengineering, You are claiming that ISO compliance is
a waste of time. ISO Compliance is not overengineering.
>> 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.
Hardly. Its subject to real world practicalities and cost benefit.
>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.
In your personal opinion. The majority of posters here happen to
disagree. Please refrain from posting your personal opinion as if it
were fact.
>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?
Yes. The C implementation should take care of that mess.
IMHO Steve's point was that writing code that specifically needs to
know if a byte is nine bits, is not recommended.
>> > 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*?
>
>I would say "is considered" so by capable experts.
Name some. I have seen no evidence to support this laughable claim.
Indeed my own experience (nearly 15 years commercial software
development in banking) is quite the reverse - you have to not only
solve today's problem, but think about future requirements.
If I only solved the problem at hand then today:
- I'd have hard-coded stuff I put in a database instead, thus being
unable to deal with the last-minute requirements change to have three
time bands instead of 2, and altering the threshold from 2cts to 3cts
for the top band.
- I'd have used ESQL to link to the Ingres database used by our
current trading system, instead of isolating the DB element via an
abstraction layer, and being able to handle the expected move to
Oracle that our new TS will use next year.
- I'd have used the API of the brokers directly, instead of using an
(expensive) 3rd party abastraction layer to isolate me from the
individual brokers, thus being forced to recompile my entire app next
week when one of the brokers issues a major upgrade.
By the way, around 75% of my code was ISO (C++ as it happens). The 25%
non-=ISO is nicely segregated in replaceable abstraction layers.
Go figure.
--
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 =---
Mark McIntyre
<nos...@nospam.nospam> wrote:
>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.
This is a red herring. You don't generally need to do anything to
convert pre-ANSI code to ISO, and if you did need to convert it, then
if you had to do it, you had to.
>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.
I /am/ a hiring manager and believe me, and candidate who said he
didn't care about standards would be leaving the interview empty
handed. Standards are /vital/ for quality control and maintainability,
and if your managers disagree, then say 'Hi' to Dilbert for me on your
way past his cubicle, and tell him the garbage man has some neat
device for getting his tie to lie flat.
>but my contention is that other features fair better in a
>cost/benefit analysis than (often speculative) portablity.
Writing ISO C is not merely about compatibility. Its about writing
safe, stable code that doesn't rely on platform specific tricks.
You should also consider that "porting" includes upgrading to a new
compiler eg MSVC5 to MSVC6, or to a new version of the same OS. For
example Win9x to WinNT to XP, or to a new version of the same hardware
eg IA32 to IA64. You don't think thats important to consider?
>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.
Using Oracle instead of Ingres doesn't generate money, it costs a heck
of a lot. But its still worth doing for other reasons.
And besides, writing safe, maintainable code, even for a single
device, saves money. Money saved is money earned. QED.
>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?
Alternatively, I hire applicants who have no clue about the actual
language, and think that how it works on (say) solaris is how it works
everywhere. No thanks.
Jack Klein
in comp.lang.c:
> Alan Balmer <alba...@att.net> writes:
> > On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <nos...@nospam.nospam>
> > wrote:
> >
> > >and suggest that there should be a group called comp.lang.ansi-c or
> > >whatever,
> >
> > Nope. C *is* ANSI-C. The standard is the very definition of C To me,
> > comp.lang means just that - discussions about the *language.* Not its
> > applications, not extensions to it, not libraries for it or algorithms
> > coded in it, but the language itself and its proper use. No confusion
> > there.
>
> Just to be pedantic, it's more accurate to refer to ISO C rather than
> ANSI C. The 1989 ANSI standard was adopted, with some minor editorial
> changes, as the 1990 ISO standard. The 1999 standard is
> ISO/IEC 9899:1999. (I think it's also officially an ANSI standard;
> ANSI is a member if ISO.)
>
> The habit of referring to ANSI C (as opposed to K&R C, the language
> defined in K&R 1st edition) originated when the ANSI standard was
> being developed in the late 1980s. The term has stuck, but it's no
> longer the most accurate one.
There was even a seven month period when 9899:1999 was the ISO/IEC
standard but not the ANSI one, from October 1999 to May 2000.
But this is one point hardly worth the pedantry. There is literally
no chance of eradicating the phrase "ANSI C" from common use.
--
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
Dim St Thomas
> teken...@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.
<http://groups.google.com/groups?threadm=3C59AAE4.10203C26%40yahoo.com>
Richard Heathfield
Yes, that's an excellent example (albeit perhaps not a very tactful one). In
fact, it perfectly illustrates that comp.lang.c is not only a newsgroup,
but also a *community*, with a community's conventions, dynamics, mores,
customs, and also a reasonable amount of friendship and compassion.
Randy Howard
nos...@nospam.nospam says...
> Again I claim if I went through my code looking for %ul and replacing it
> with %lu, it would not be looked upon highly.
OMG. You really are pretending to be a C programmer, aren't you?
--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: postm...@sco.com
Randy Howard
dimst...@yahoo.com says...
> <http://groups.google.com/groups?threadm=3C59AAE4.10203C26%40yahoo.com>
Well, aren't you the sick little troll? Surely you could have found
something more valuable to your argument?
Joona I Palaste
> In article <nS2qb.41$hF...@newssvr14.news.prodigy.com>,
> nos...@nospam.nospam says...
>> Again I claim if I went through my code looking for %ul and replacing it
>> with %lu, it would not be looked upon highly.
> OMG. You really are pretending to be a C programmer, aren't you?
Well, it *could* be that with the programs he's paid to write, "42" and
"42l" are considered the same output.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"C++ looks like line noise."
- Fred L. Baube III
Alan Balmer
<randy....@FOOmegapathdslBAR.net> wrote:
>In article <1e94d380.03110...@posting.google.com>,
>dimst...@yahoo.com says...
>> <http://groups.google.com/groups?threadm=3C59AAE4.10203C26%40yahoo.com>
>
>Well, aren't you the sick little troll? Surely you could have found
>something more valuable to your argument?
Why do you think they call him Dim?
Alan Balmer
>Alan Balmer <alba...@att.net> writes:
>> On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <nos...@nospam.nospam>
>> wrote:
>>
>> >and suggest that there should be a group called comp.lang.ansi-c or
>> >whatever,
>>
>> Nope. C *is* ANSI-C. The standard is the very definition of C To me,
>> comp.lang means just that - discussions about the *language.* Not its
>> applications, not extensions to it, not libraries for it or algorithms
>> coded in it, but the language itself and its proper use. No confusion
>> there.
>
>Just to be pedantic, it's more accurate to refer to ISO C rather than
>ANSI C. The 1989 ANSI standard was adopted, with some minor editorial
>changes, as the 1990 ISO standard. The 1999 standard is
>ISO/IEC 9899:1999. (I think it's also officially an ANSI standard;
>ANSI is a member if ISO.)
>
Quite true, but I'm afraid you have a losing battle, especially with
Americans ;-)
In this case, I didn't want to first explain that Roose had made an
error in naming his proposed group, then make my point.
I admit that I have a tendency to be wishy-washy and write "ANSI/ISO",
because hardly anyone I deal with on a daily basis (other than the
fine folks here) uses "ISO" to refer to the standard.
Richard Heathfield
> Randy Howard <randy....@foomegapathdslbar.net> scribbled the following:
>> In article <nS2qb.41$hF...@newssvr14.news.prodigy.com>,
>> nos...@nospam.nospam says...
>>> Again I claim if I went through my code looking for %ul and replacing it
>>> with %lu, it would not be looked upon highly.
>
>> OMG. You really are pretending to be a C programmer, aren't you?
>
> Well, it *could* be that with the programs he's paid to write, "42" and
> "42l" are considered the same output.
There's no particular reason why the code should print 42l. It would not be
difficult to come up with an architecture in which it would print 0l
instead. (For example, I16L32, MSB on left.)
Joona I Palaste
> Joona I Palaste wrote:
>> Randy Howard <randy....@foomegapathdslbar.net> scribbled the following:
>>> In article <nS2qb.41$hF...@newssvr14.news.prodigy.com>,
>>> nos...@nospam.nospam says...
>>>> Again I claim if I went through my code looking for %ul and replacing it
>>>> with %lu, it would not be looked upon highly.
>>
>>> OMG. You really are pretending to be a C programmer, aren't you?
>>
>> Well, it *could* be that with the programs he's paid to write, "42" and
>> "42l" are considered the same output.
> There's no particular reason why the code should print 42l. It would not be
> difficult to come up with an architecture in which it would print 0l
> instead. (For example, I16L32, MSB on left.)
So let me check if I understand this correctly. Suppose you're on an
architecture where sizeof(unsigned long)==4 and sizeof(unsigned int)==
sizeof(int)==2, and it stores multi-byte integers in a big-endian
fashion.
When you write:
unsigned long l=42;
printf("%ul\n", l);
Then the code within printf() is looking at the % sign, and trying to
find out which designator it is. It finds "%u" and treats the "l" that
follows it as normal literal text.
"%u" means "unsigned int" to printf(). So it calls code to fetch
sizeof(unsigned int) bytes from wherever the arguments are stored,
when there really are sizeof(unsigned long) bytes there.
So the argument byte string looks like this: 00 00 00 2A
But printf() is only fetching the first two 00's, and constructing
an integer from them. Well, in big-endian, 00 00 equals 0. So it
prints the 0, and then goes to dutifully print the literal "l",
resulting in an output of:
0l
So this means that printf() will print "0l" for *ANY* unsigned long
that is less than 65536. For any unsigned long that is at least
65536 but less than 131072 it will print "1l" and so on.
If this is so, then there is *all the more reason* for Roose to go
through his code and change "%ul" to "%lu". Not to make us pedants
happy - *TO MAKE HIS CODE WORK RIGHT*! Making us pedants happy is a
free bonus.
If Roose's boss is happy to pay him for writing code that doesn't
work right, then he can be my guest, but I don't want to use that
software.
After all, who knows what strange bugs might happen due to a piece of
software thinking that anything taking up less than 64 kilobytes of
space actually takes up no space at all?
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"He said: 'I'm not Elvis'. Who else but Elvis could have said that?"
- ALF
Keith Thompson
> In article <nS2qb.41$hF...@newssvr14.news.prodigy.com>,
> nos...@nospam.nospam says...
> > Again I claim if I went through my code looking for %ul and replacing it
> > with %lu, it would not be looked upon highly.
>
> OMG. You really are pretending to be a C programmer, aren't you?
To be fair to Roose, he's already acknowledged his incorrect
assumption (that "%ul" is commonly equivalent to "%lu"). I'd say it
was a mistake comparable to writing "%ul" in the first place.
Mark McIntyre
<pal...@cc.helsinki.fi> wrote:
>If Roose's boss is happy to pay him for writing code that doesn't
>work right, then he can be my guest,
Hmm,its about time I found out where he works - I have an infinite
quantity of monkeys outside huddled round a really strong cup of tea,
and maybe I could raise a little extra cash by renting them out in
between producing shakespeare plays...
Ian Woods
news:0tolqv4jektlrb7uo...@4ax.com:
> On 6 Nov 2003 18:46:28 GMT, in comp.lang.c , Joona I Palaste
> <pal...@cc.helsinki.fi> wrote:
>
>>If Roose's boss is happy to pay him for writing code that doesn't
>>work right, then he can be my guest,
>
> Hmm,its about time I found out where he works - I have an infinite
> quantity of monkeys outside huddled round a really strong cup of tea,
> and maybe I could raise a little extra cash by renting them out in
> between producing shakespeare plays...
I think you might be a bit more successful if you used a really hot cup of
tea... it's the Brownian motion which is important IIRC. :)
Ian Woods
Steve Summit
> On 5 Nov 2003 01:56:01 GMT, s...@eskimo.com (Steve Summit) wrote:
>>> 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.
>
> Generalization does not always take extra time. In fact, I have found
> that generalizing a problem often leads to a solution which is not
> only extensible, but easier and cleaner to implement in the first
> place.
I didn't write the text you quoted -- that was Roose -- but I'm
glad you followed up, because I agree with your point 1000%.
(The trick, of course, that "often" is not "always".
The challenge is therefore -- and *so* many problems boil down
to this! -- to decide when to apply the "generalizing a problem
is easier" rule, and when not to.)
Steve Summit
s...@eskimo.com
Kelsey Bjarnason
On Wed, 05 Nov 2003 07:54:11 +0000, Joona I Palaste wrote:
> I actually find that statement quite funny. Roose's boss would fire him
> if he wrote 100% ANSI C code?
Not surprising in the least.
Boss: "Roose, we're going to roll out the latest thing in advanced gaming
software - multiplayer, strong AI, the works. You're in charge of the UI."
Roose: "Oh, goodie! A new game! Lessee... I could write ANSI C code,
using putchar and fgets and the like for the UI... or I could use OpenGL
or DirectX, provide support for mice, keyboards, multi-function joysticks,
force chairs and the like and give the user an impressive 3D immersion
experience. I wonder which way I should go."
Frankly, if I were his boss and he came up with a 100% ANSI C interface,
I'd fire his butt for sheer gross incompetence.
Joona I Palaste
This depends on how you interpret Roose's words "if he wrote 100%
ANSI C". Your example depicts the interpretation "if he always wrote
100% ANSI C". I interpreted it as "if he ever wrote 100% ANSI C".
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Bad things only happen to scoundrels."
- Moominmamma
Keith Thompson
It's a matter of what we mean by "100% ANSI^H^H^H^H ISO C". ISO C
defines function calls. I'm not familiar with OpenGL or DirectX, but
there's probably no need for any code that uses them to use any
features not defined by the ISO C standard, other than the libraries
themselves. The non-portable code is already written; all Roose has
to do is call it.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Mark McIntyre
<news...@wuggyNOCAPS.org> wrote:
>Mark McIntyre <markmc...@spamcop.net> wrote in
>news:0tolqv4jektlrb7uo...@4ax.com:
>
>I think you might be a bit more successful if you used a really hot cup of
>tea... it's the Brownian motion which is important IIRC. :)
Rats. My copy is down two flights of stairs, and I'm currently
listening to episode 6 on my mp3 player, or I would not have made such
an elementary mistake...
Mark McIntyre
<kel...@xxnospamyy.lightspeed.bc.ca> wrote:
>[snips]
>
>Frankly, if I were his boss and he came up with a 100% ANSI C interface,
>I'd fire his butt for sheer gross incompetence.
Frankly, if his boss was so idiotic as to not specify the required
features of this UI, then if he fired the programmer for using ISO C
only, it would be a prima facie case of constructive dismissal, and
the ex-employee would be sitting on a large pile of cash. I'm
comfortable with this idea. You write the bad spec, I'll code it :-)
Ben Pfaff
> On Fri, 7 Nov 2003 11:31:59 +0000 (UTC), in comp.lang.c , Ian Woods
> <news...@wuggyNOCAPS.org> wrote:
>
> >Mark McIntyre <markmc...@spamcop.net> wrote in
> >news:0tolqv4jektlrb7uo...@4ax.com:
> >
> >I think you might be a bit more successful if you used a really hot cup of
> >tea... it's the Brownian motion which is important IIRC. :)
>
> Rats. My copy is down two flights of stairs,
...in a disused lavatory, past a sign warning "Beware of the
Leopard," ...
--
(Unfortunately I probably got part of that wrong too.)
Richard Heathfield
> Mark McIntyre <markmc...@spamcop.net> writes:
>
>> On Fri, 7 Nov 2003 11:31:59 +0000 (UTC), in comp.lang.c , Ian Woods
>> <news...@wuggyNOCAPS.org> wrote:
>>
>> >Mark McIntyre <markmc...@spamcop.net> wrote in
>> >news:0tolqv4jektlrb7uo...@4ax.com:
>> >
>> >I think you might be a bit more successful if you used a really hot cup
>> >of tea... it's the Brownian motion which is important IIRC. :)
>>
>> Rats. My copy is down two flights of stairs,
>
> ...in a disused lavatory, past a sign warning "Beware of the
> Leopard," ...
>
> (Unfortunately I probably got part of that wrong too.)
You weren't far off.
"But the plans were on display ..."
"On display? I eventually had to go down to the cellar to find them."
"That's the display department."
"With a torch."
"Ah, well the lights had probably gone."
"So had the stairs."
"But look, you found the notice didn't you?"
"Yes," said Arthur, "yes I did. It was on display in the bottom of a locked
filing cabinet stuck in a disused lavatory with a sign on the door saying
Beware of the Leopard."
Douglas Adams, "The Hitch-hiker's Guide to the Galaxy"
Ian Woods
<snip>
> You weren't far off.
>
> "But the plans were on display ..."
> "On display? I eventually had to go down to the cellar to find them."
> "That's the display department."
> "With a torch."
> "Ah, well the lights had probably gone."
> "So had the stairs."
> "But look, you found the notice didn't you?"
> "Yes," said Arthur, "yes I did. It was on display in the bottom of a
> locked filing cabinet stuck in a disused lavatory with a sign on the
> door saying Beware of the Leopard."
>
> Douglas Adams, "The Hitch-hiker's Guide to the Galaxy"
Oddly enough, it was this bit (err, right at the beginning) I read
lastnight before I went to sleep! I figured it's about time I reread it.
Ian Woods
Steve Summit
common decency I'd leave it that way, rather than posting this
followup which I started composing back in the midst of it but
didn't manage to finish until now...]
Roose wrote:
> 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.
My time is also not unlimited, so I probably won't manage to
reply to all the fascinating subpoints in this thread that I
might. Thank you for favoring me as being worthy of a "real
world" dialog, although in the interests of strict intellectual
honesty I have to confess that the plane I'm arguing from is not
always as real-world as I might have made it sound. In fact, I
go to considerable lengths to maintain the self-imposed delusion
that I live in a fantasy world, one in which software is easy
and fun to write, and works right the first time; in which new
features and other improvements are easy to make; in which
debugging is a rare pastime.
It's also important to emphasize that we're talking about a lot
more than "ANSI C compliance" here. In fact -- and I shouldn't
say this, because I'm liable to be quoted out of context -- ANSI
C compliance is in some sense a red herring. It's nevertheless
at least an *important* red herring, however; more on this anon.
While I'm listing prefatory disclaimers, I'll also admit -- and I
don't mean this in any snide way -- that I don't expect to fully
convince you. Several of the ideas you've expressed have met
with instant disfavor here in comp.lang.c, but you (and those
ideas) are in very good company out there in the real world,
albeit it's that same real world where for whatever reason
software is painful and expensive to write, where programs
never work correctly the first time and in many cases never work
perfectly at all, where bugs and gratuitous complexity tend
inexorably to become so ossified that it's impossible to fix them
or to add new features without adding yet more bugs, and where
debugging tends to account for far more time than actually
writing code. Maybe I'm crazy, but I'd like to think we can
do better...
* * *
First of all, although this point has been amply made elsewhere,
no one is claiming that 100% of every useful program must be
written in 100% strictly conforming ANSI/ISO C. The claims are
merely that as much as possible should be written in ANSI/ISO C,
that the system-dependent portions which cannot be written
portably should be very cleanly separated, and finally that the
proportion of system-independent to system-dependent code can be
much larger than is necessarily always acknowledged.
* * *
Several others have made this point, but even when portability is
no market requirement, it can be hugely advantageous to write a
program portably, anyway, if it makes the development easier.
I was once hired to make extensions to a piece of embedded
software, and the first thing I did was to port it from its
native environment (a stripped-down version of MS-DOS) to Linux,
and write a quick-and-dirty curses-based replacement for its
original machine-dependent user interface. That port probably
cost me a day or two of work, but the payback was handsome and
immediate, because it made *everything* else so much easier; I'm
sure I worked 2-3 times as efficiently during the 6-8 weeks that
the rest of the project lasted as I could have if I'd tried to do
all my development under MS-DOS and all my testing on the actual
embedded device.
This is another of those arguments which I'm sure seems utterly
unconvincing (because it's so unbelievable) to many observers out
there in the real world where software is painful and expensive
to write. If every line of code comes dear, it might seem
inconceivable to spend time writing an entire Unix-compatible
curses-based user interface for an embedded program, when that
interface will be thrown away when the coding is complete, never
to be seen by a paying customer. "Why would you even think of
wasting time writing it, when we're already so far behind on all
the product-specific code we *have* to write? And what do you
really need it for, anyway? DOS isn't that bad a development
environment, and anyway we should be doing all of our testing
there since that's where the end users will be using it. Why are
you so het up about trying to do your development under Unix?
Are you one of those Unix bigots or something? I think you're
just too lazy and set in your ways to learn how to program in
DOS."
Those counterarguments aren't completely invalid, and I'm probably
poking a bit more fun at them here than is strictly fair, but
they're made by people who don't understand the difference that
a development environment can make, who don't appreciate the
orders-of-magnitude differences in productivity between mediocre
programmers using mediocre development environments versus good
programmers using great ones. (And, incidentally, they don't
understand that a certain kind of motivated, directed laziness
is a very great virtue in programming. Me, I'll bend 'way over
backwards, and run around the barn three times, and stay up all
night coding, if it'll let me be completely slack-off lazy for
the entire rest of the project.)
* * *
Up above I admitted that ANSI C compliance was in some sense a red
herring, albeit an important one. Now I'll start trying to
explain what I meant.
"ANSI C" is partly a code-word for "the high-quality code we
advocate here, as opposed to the junk everybody else puts up with."
You're right -- strictly speaking, ANSI C compliance might not
seem to be nearly as much of a "hard" market requirement as the
"really important" market imperatives such as efficiency and
featurefulness. But there are a number of things that thinking
about ANSI C compliance forces you to do.
One is that it forces you to cleanly separate those parts of your
program that can be portable from those that can't be. And it
turns out that this is quite often a *really* *good* exercise to
go through anyway, even if the can-be-portable part never ends up
being ported off of its initial development environment at all.
The reason is that although everyone understands that Modularity
is Good, not everyone always manages to actually write code that
is particularly well modularized. The user interface code tends
to end up being tightly intertwined with the data processing
code, and the data processing code tends to get all tangled up
with the OS- or database-access code. And the result is that
there end up being all sorts of things that would be "nice"
to do, that you can't. You can't write a noninteractive test
harness that exercises the 80-90% of the program that does
involve data processing but doesn't involve the user interface,
because you can't separate that portion of the program from the
user interface. When the database access code isn't working,
you can't put in a single, simple debug printout at the one spot
where all database access calls funnel through, because there
isn't that one spot, because ad-hoc database access calls are
scattered all over. When focus group testing shows that the
workflow implied by the existing user interface is awkward and
confusing to users and should be significantly reworked, you
can't afford to, because it would require rewriting too much of
the intertwined, non-user-interface, data processing code as
well. And so on.
If, on the other hand, a project is developed with a "do as much
of it as possible in ANSI C" mantra, it goes hand in hand with a
"modularize it properly" mantra, because for the most part the
pure data processing code, that it would be nice to keep
separated from the User interface and the OS interface, is
precisely the part that can be written strictly portably.
Abilities like bolting on an alternative, noninteractive user
interface "just for testing", or tracing all database access
calls "just for convenience during debugging", might seem like
luxuries, or mere niceties. But in successful projects,
"luxuries" like these are easy to come by, because they're
synergistic with -- simultaneously enabled by and further
contributing to -- the very same high qualities that are making
the project successful.
* * *
Though I hope it was at least somewhat convincing, the preceding
argument has a bit of a disciplinarian, drink-your-cod-liver-oil-
it's-good-for-you feel to it. Dusty crusty academicians come up
with all sorts of reasons why learning Latin is Good For You
because it Clarifies your Thought Processes even though nobody
speaks it any more. Me, I don't know any Latin, but I'm afraid
I might sound about as crusty for claiming that writing ANSI C
is beneficial even if you don't care about portability, just
because it will force you to write better, more modular code.
Here's a perhaps more compelling argument.
Assume we agree that we care most about ANSI C compliance in
those parts of the program that can be made portable, and that we
have gone through the exercise of cleanly separating those parts
of the program that can be made portable from those that can't
be. Now, what sorts of strict ANSI C violations, or other
nonportabilities, is our program likely to contain?
Obviously, the can't-be-made-portable portions of the program
will be full of nonportabilities, that's the whole point.
In those parts of the code, for each noncompliant aspect that
a nitpicker or naysayer might point at, there isn't an ANSI C
alternative, so it's hardly worth complaining.
But in the allegedly-portable parts of the program, when there
are two or more ways of writing some piece of code, what can we
say about the possibilities, and about our preferences for
writing one over the other? If one of the ways is not ANSI
conforming, here we will usually find that it *does* have a
conforming alternative, and the arguments in favor of the
nonconforming option basically reduce to: ignorance. If you
don't know about the conforming alternative, that's one thing,
but having been presented with it, if you insist on continuing
to do it your old way, because it's "more efficient" or "what
you're used to" or because the resulting alleged nonportability
"doesn't matter in this case", you're probably being willfully
stubborn.
But it's even worse than that. In the nonportable parts of the
program, you had no choice but to go with the system-dependent
implementations; there were no alternatives. Having gone with
the necessarily system-dependent, unavoidably unportable
alternative, the potential failure mode is only the one we
already knew about: it's not portable.
In the nominally portable parts of the program, on the other
hand, anything nonstandard you're making use of -- that is,
any departure from Standard-conforming C -- is likely to be
a compiler extension or an instance of undefined behavior.
(Actually, by one definition they're the same thing.)
You might make an informed decision to adopt and depend on a
compiler extension, but far more worrisome are those instances
of undefined behavior.
That instance of undefined behavior, that you thought you could
live with, that worked fine for you last week, might stop working
next week, for no reason at all, or because you installed a new
release of the compiler, or changed a compilation option, or
switched to daylight saving time, or tried to run the program on
a bigger problem, or with more or less memory available to it,
or for a million other but-what-difference-can-that-make reasons.
That quirky aspect of C that you weren't sure about, that you
empirically determined worked a certain way based on a quick test
program that you wrote, and that you then made use of in 37
different places in the larger system that you can't remember all
of and can't definitively grep for, turns out not to always work
the way you thought it did, after all, because your empirical
testing was unwittingly incomplete.
(Me, I tend to be pretty paranoid about those nifty-keen but
utterly nonstandard vendor extensions, too, because the more
enticing and compelling they are, the easier it is for them to be
be twisted by the vendor into a shackle that forces you to keep
using that vendor after they've incongruously become Totally
Evil, and you find you'd rather wean yourself from them after
all, except now you can't.)
In any case, the point here is that when a departure from
Standard conformance is an instance of undefined behavior, the
potential failure mode is reasonably dire: the program could stop
working tomorrow, for whatever reason, even though it seemed to
pass its test suite with flying colors today, inspiring us to to
release it to the customers tonight. And it seems to me that if
you say you don't care about the Standard and that you can live
with departures from it, many of your departures will end up in
this category.
* * *
Finally, here's the other half of the "red herring" explanation.
To some extent, talking about ANSI C compliance is a shibboleth.
There's a worrisome sort of class distinction in programming
between programmers who are satisfied with code that seems to
work, versus programmers who insist on code that works *for the
right reasons*. Unfortunately, of course, code that merely seems
to work today can just as easily stop working tomorrow, leading
to neverending bug-chasing. Code that works for the right reasons,
on the other hand, has some decent chance of continuing to work
properly tomorrow and next week and next month and next year,
*without* continual hands-on maintenance (meaning among other
things that the programmers involved are free to move on to new
and different projects).
Here's what I mean by the shibboleth: programmers who insist
that code work for the right reasons can't help but be zealous
advocates of the ANSI C Standard, because it's unquestionably
the biggest and strongest Right Reason that there is for code
to work. So programmers who care that code works for the right
reasons also care about (and think about, and talk about)
the C Standard, whether or not they have portability as a job
requirement. Programmers who are looking for excuses to ignore
the Standard, on the other hand (because, they claim, it's
irrelevant to their work), are likely to be the ones who are
satisfied with code that seems to work at the end of the day --
but that's an attitude that ends up causing all sorts of other
problems, too.
> ...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...
[and in another 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.
To my way of thinking, the two are much more related than you
might think. Code which is sullied by hacks upon hacks, or which
suffers from a lack of coherent design, is code which someone
tried to get working by hook or by crook, and where the definition
of "working" was probably "seems to work at the end of the day".
The only way I know of to get out of that trap is to start paying
attention to coding styles and development attitudes which
feature the virtue of code that works for the right reasons --
and ANSI C is very much on that table.
* * *
>> 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).
The percentage is probably pitifully small.
> If you were a hiring manager, wouldn't this unnecessarily limit
> your pool of applicants if you were to insist on it?
It depends on what you mean by "unnecessarily limit". The
percentage of truly excellent programmers is also on the small
side. You might say it limited your pool if you were to insist
on finding a truly excellent programmer, and you might very well
not be able to find one, but neither of these realities implies
that this kind of excellence is unimportant or not worth striving
for.
* * *
I'm sorry that we here in comp.lang.c tend to come across as
Standard-thumping fundamentalists, continuing to insist, with
ramrod-straight demeanor, that all code be strictly conforming,
as if it's only important for its own sake. But the insistence
is *not* merely for its own sake: much more importantly, it's for
the sake of code that's *correct*, not just in the ANSI C Standard
sense, but in the much more important "works reliably in the real
world" sense. As I had occasion to write once before when this
issue came up, "I'm not a Standard-thumping fundamentalist who
worships at the altar of X3J11 because I'm an anal-retentive
dweeb who loves pouncing on people who innocently post code
containing void main() to comp.lang.c; I'm a Standard-thumping
fundamentalist who worships at the altar of X3J11 because it
gives me eminently useful guarantees about the programs I write
and helps me ensure that they'll work correctly next week and
next month and next year, in environments I haven't heard of or
can't imagine or that haven't been invented yet, and without
continual hands-on bugfixing and coddling by me."
Steve Summit
s...@eskimo.com
Steve Summit
> ...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.
It's interesting you should mention game programming. It's
commonly believed that graphics-intensive games don't have to,
and can't, be written portably. In fact, in a memorable thread
from 1994, a poster contesting the newsgroup's extreme ANSI
focus made exactly this point:
Who cares about ANSI! ...
Let's C great games like DOOM and Wolfenstein written
using ANSI standard. Yeah! It ain't gonna work! ANSI
is only good for stupid text and standard file I/O operations.
[from <http://groups.google.com/groups?selm=14.19276.711%40sourcebbs.com>]
Others were quick to point out, however, that one of the
biggest games of 1994, Doom, *was* in fact written almost
completely in portable, ANSI-compatible C. And there was a
delicious postscript to that tangent of the thread when none
other than Dennis Ritchie posted an article which I am not
going to reproduce here, but which I encourage you to go over
to groups.google.com to read:
<http://groups.google.com/groups?as_umsgid=Cys3oL.C6y%40research.att.com>
"Portability often pays off in unexpected ways", indeed!
Steve Summit
s...@eskimo.com
Richard Heathfield
> [This thread seems to have completely died down, and if I had any
> common decency I'd leave it that way, rather than posting this
> followup which I started composing back in the midst of it but
> didn't manage to finish until now...]
<300+ lines reluctantly snipped>
An excellent article. With a little editing (to generalise it into essay
format rather than "reply" format), it would make an excellent Web
reference page to which denizens of clc could justly point when the subject
comes up again.
Mike Wahler
news:2003Nov17.0...@box16.scs.ndip.eskimo.net...
[snip]
> Here's what I mean by the shibboleth: programmers who insist
> that code work for the right reasons can't help but be zealous
> advocates of the ANSI C Standard, because it's unquestionably
> the biggest and strongest Right Reason that there is for code
> to work. So programmers who care that code works for the right
> reasons also care about (and think about, and talk about)
> the C Standard, whether or not they have portability as a job
> requirement. Programmers who are looking for excuses to ignore
> the Standard, on the other hand (because, they claim, it's
> irrelevant to their work), are likely to be the ones who are
> satisfied with code that seems to work at the end of the day --
> but that's an attitude that ends up causing all sorts of other
> problems, too.
[Honesty dictates that I admit I had to look up the word
'shibboleth' :-) ]
I suppose I've always been different from these 'standards ignorers'
in that it's always been the case that I lose sleep just as readily
when I have code that 'works' but I don't know *why*, as when I have
code that doesn't work. I certainly don't release it.
Thanks for your excellent article. I second Richard's idea about
converting it into 'essay' format and posting it somewhere, with
perhaps a link to it from the FAQ.
I also have a perspective I suppose is somewhat 'unique' among
the 'younger' folks here: I learned to program in C (and used it
on more than one platform) before there was a standard. This of
course meant I had to learn the idiosyncracies of each implementation
I used, a very time-costly proposition. The advent of the standard was
a Great Day in my life, that's for sure.
$.02,
-Mike
Steve Summit
newsgroup's focus on the importance of portability and ANSI C
compliance. In response, Richard Heathfield wrote:
> An [adjective deleted] article. With a little editing (to generalise
> it into essay format rather than "reply" format), it would make an
> excellent Web reference page to which denizens of clc could justly
> point when the subject comes up again.
For no particular reason, today was the day to do that editing
and generalizing. The revised essay is at
http://www.eskimo.com/~scs/readings/portability.20031117.html
Point away.
Just for fun, I poured the same text into the new "clc wiki", at
http://clc-wiki.net/wiki/Portability_and_ANSI_C_Compliance
So anyone is free to edit it to more perfectly reflect the
newsgroup's consensus, refine the wording, eliminate first-person
perspective, etc.
--
Steve Summit
s...@eskimo.com
Keith Thompson
Excellent, and highly recommended. (BTW, "excellent" was the deleted
adjective.)
Just a couple of minor comments.
I just read the Wiki article. I have no problem with the first-person
perspective, but you might consider signing it, or at least mentioning
who wrote the original.
Also, I think "ISO C" would be a clearer and more accurate term than
"ANSI C".
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Default User
> In response, Richard Heathfield wrote:
>
> > An [adjective deleted] article.
Ha. I first read this as, "An [expletive deleted] article."
I was trying to imagine what Richard had originally said.
Brian
Rod Pemberton
"Default User" <defaul...@yahoo.com> wrote in message
news:44kv4bF...@individual.net...
Adjective deleted? Why bother, unless it was very derogatory and close to
an expletive...
It's simple to put three dots there so noone questions whether the original
article was crappy or not.
RP
Keith Thompson
I suspect Steve was being modest. (The adjective was "excellent".)
CBFalconer
> "Rod Pemberton" <dont...@bitbucket.cmm> writes:
>
... snip ...
>>
>> Adjective deleted? Why bother, unless it was very derogatory and
>> close to an expletive... It's simple to put three dots there so
>> noone questions whether the original article was crappy or not.
>
> I suspect Steve was being modest. (The adjective was "excellent".)
Modest? A Programmer? A C Programmer? Extinct. :-)
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
Jack Klein
comp.lang.c:
I agree with Richard, the "excellent" adjective was well deserved.
I have tried to make the same point in replies of varying length here
over the years.
I enjoyed your description of building a desktop simulation of the
user interface for an embedded system. I've been doing that for more
than a decade and a half. It is extremely useful when the
customer/end user/etc., wants to see and approve the appearance and
operation of the interface early in the cycle.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
Rod Pemberton
"Jack Klein" <jack...@spamcop.net> wrote in message
news:jq0du1dq14snds7s3...@4ax.com...
> On 4 Feb 2006 21:23:59 GMT, s...@eskimo.com (Steve Summit) wrote in
> comp.lang.c:
>
> > A couple of years ago, I posted a big long article defending this
> > newsgroup's focus on the importance of portability and ANSI C
> > compliance. In response, Richard Heathfield wrote:
> >
> > > An [adjective deleted] article. With a little editing (to generalise
> > > it into essay format rather than "reply" format), it would make an
> > > excellent Web reference page to which denizens of clc could justly
> > > point when the subject comes up again.
> >
> > For no particular reason, today was the day to do that editing
> > and generalizing. The revised essay is at
> >
> > http://www.eskimo.com/~scs/readings/portability.20031117.html
> >
> > Point away.
> >
> > Just for fun, I poured the same text into the new "clc wiki", at
> >
> > http://clc-wiki.net/wiki/Portability_and_ANSI_C_Compliance
> >
> > So anyone is free to edit it to more perfectly reflect the
> > newsgroup's consensus, refine the wording, eliminate first-person
> > perspective, etc.
>
> I agree with Richard, the "excellent" adjective was well deserved.
Eh, I'd say mostly good. There are a number of inflammatory things near the
middle. And, the last paragraph will be found highly offensive by many.
And, I'm sure that last paragraph probably translates poorly into other
languages with Altavista, something like "You will be Crucified like Jesus
by the Romans." ;)
Rod Pemberton
Ian Collins
> "Jack Klein" <jack...@spamcop.net> wrote in message
> news:jq0du1dq14snds7s3...@4ax.com...
>
>>On 4 Feb 2006 21:23:59 GMT, s...@eskimo.com (Steve Summit) wrote in
>>comp.lang.c:
>>>Just for fun, I poured the same text into the new "clc wiki", at
>>>
>>>http://clc-wiki.net/wiki/Portability_and_ANSI_C_Compliance
>>>
>>>So anyone is free to edit it to more perfectly reflect the
>>>newsgroup's consensus, refine the wording, eliminate first-person
>>>perspective, etc.
>>
>>I agree with Richard, the "excellent" adjective was well deserved.
>
>
> Eh, I'd say mostly good. There are a number of inflammatory things near the
> middle. And, the last paragraph will be found highly offensive by many.
> And, I'm sure that last paragraph probably translates poorly into other
> languages with Altavista, something like "You will be Crucified like Jesus
> by the Romans." ;)
>
Offensive to whom?
This is a well written piece and makes a very strong case for compliant
code, while avoiding flamebait.
--
Ian Collins.
Flash Gordon
Presumably offensive to those like Rod Pemberton who like to insist that
this group should be wide open to anything vaguely C related even though
experience in comp.lang.c++ apparently shows that this would make the
group useless.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.