ANSI C compliance

On 5 Nov 2003 01:56:01 GMT, sc*@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.

--
Al Balmer
Balmer Consulting
re************************@att.net

Nov 13 '05 #52

On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <no****@nospam.nospam>
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.

--
Al Balmer
Balmer Consulting
re************************@att.net

Nov 13 '05 #53

On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <no****@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.

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.

--
Al Balmer
Balmer Consulting
re************************@att.net

Nov 13 '05 #54

Sheldon Simms

On Wed, 05 Nov 2003 10:34:19 +0000, Joona I Palaste wrote:

Keith Thompson <ks*@cts.com> scribbled the following:
"Roose" <no****@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.

Nov 13 '05 #55

Roose

> 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. You mean you guys
don't test your code before posting it? : ) I will look for another
example of such a thing.

Roose

Nov 13 '05 #56

Mark Gordon

On Wed, 05 Nov 2003 07:43:49 GMT
"Roose" <no****@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" <sc*@eskimo.com> wrote in message
news:bo**********@eskinews.eskimo.com...
Roose wrote:
I'm not talking about "you" or "I". I'm talking about a real
development team, that makes a real product. On such a team, _as
a fact_, you will encounter old code, code written by someone
other than yourself. Old code
that is likely not written in ANSI C.
Sure, but none of us -- you, I, or Ian -- is talking to or about
that earlier programmer. We're talking about us -- you, me, and
anyone else who happens to be listening, who we'd like to convince
to do better than the earlier programmer.

OK, I think the real point was lost somewhere there, but my contention
is that ANSI C being "better" is dependent on the situation, and not
an absolute fact.

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.

Nov 13 '05 #57

Roose wrote:

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 : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Nov 13 '05 #58

Roose wrote:

<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>

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

Nov 13 '05 #59

Thomas Matthews

Mark Gordon wrote:

On Wed, 05 Nov 2003 07:43:49 GMT
"Roose" <no****@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" <sc*@eskimo.com> wrote in message
news:bo**********@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

Nov 13 '05 #60

BruceS

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bo**********@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>

Nov 13 '05 #61

Alan Balmer <al******@att.net> writes:

On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <no****@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.

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

Nov 13 '05 #62

On Wed, 05 Nov 2003 08:07:48 GMT, in comp.lang.c , "Roose"
<no****@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 =---

Nov 13 '05 #63

On Wed, 05 Nov 2003 07:43:49 GMT, in comp.lang.c , "Roose"
<no****@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.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Nov 13 '05 #64

Jack Klein

On Wed, 05 Nov 2003 21:47:24 GMT, Keith Thompson <ks*@cts.com> wrote
in comp.lang.c:

Alan Balmer <al******@att.net> writes:
On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <no****@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

Nov 13 '05 #65

Dim St Thomas

Richard Heathfield <do******@address.co.uk.invalid> wrote in message news:<bo**********@sparta.btinternet.com>...

te*********@BUSThotmailE.Rcom wrote:
I find it fascinating that Richard begins his defense of one lie with
another:

It's unfortunate that you choose the word "lie" to describe a poor choice of
wording, but c'est la vie.

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

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

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

I will cheerfully accept the alternative wording, but do you have an actual
example of an OT comp.lang.c thread started by a regular contributor?
Various regulars have, of course, started totally off-topic threads in
the past...

Example, please.

<http://groups.google.com/groups?threadm=3C59AAE4.10203C26%40yahoo.com>

Nov 13 '05 #66

Dim St Thomas wrote:

Richard Heathfield <do******@address.co.uk.invalid> wrote in message
news:<bo**********@sparta.btinternet.com>...
te*********@BUSThotmailE.Rcom wrote:
> 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>

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.

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

Nov 13 '05 #67

Randy Howard

In article <nS************@newssvr14.news.prodigy.com>,
no****@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: po********@sco.com

Nov 13 '05 #68

Randy Howard

In article <1e**************************@posting.google.com >,
di*********@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?

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

Nov 13 '05 #69

Joona I Palaste

Randy Howard <ra**********@foomegapathdslbar.net> scribbled the following:

In article <nS************@newssvr14.news.prodigy.com>,
no****@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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"C++ looks like line noise."
- Fred L. Baube III

Nov 13 '05 #70

On Thu, 6 Nov 2003 02:26:35 -0600, Randy Howard
<ra**********@FOOmegapathdslBAR.net> wrote:

In article <1e**************************@posting.google.com >,
di*********@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?

--
Al Balmer
Balmer Consulting
re************************@att.net

Nov 13 '05 #71

On Wed, 05 Nov 2003 21:47:24 GMT, Keith Thompson <ks*@cts.com> wrote:

Alan Balmer <al******@att.net> writes:
On Wed, 05 Nov 2003 08:57:29 GMT, "Roose" <no****@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.

--
Al Balmer
Balmer Consulting
re************************@att.net

Nov 13 '05 #72

Joona I Palaste wrote:

Randy Howard <ra**********@foomegapathdslbar.net> scribbled the following:
In article <nS************@newssvr14.news.prodigy.com>,
no****@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.)

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

Nov 13 '05 #73

Joona I Palaste

Richard Heathfield <do******@address.co.uk.invalid> scribbled the following:

Joona I Palaste wrote:
Randy Howard <ra**********@foomegapathdslbar.net> scribbled the following:
In article <nS************@newssvr14.news.prodigy.com>,
no****@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 (pa*****@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

Nov 13 '05 #74

Randy Howard <ra**********@FOOmegapathdslBAR.net> writes:

In article <nS************@newssvr14.news.prodigy.com>,
no****@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.

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

Nov 13 '05 #75

On 6 Nov 2003 18:46:28 GMT, in comp.lang.c , Joona I Palaste
<pa*****@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...
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Nov 13 '05 #76

Ian Woods

Mark McIntyre <ma**********@spamcop.net> wrote in
news:0t********************************@4ax.com:

On 6 Nov 2003 18:46:28 GMT, in comp.lang.c , Joona I Palaste
<pa*****@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

Nov 13 '05 #77

Al Balmer wrote:

On 5 Nov 2003 01:56:01 GMT, sc*@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
sc*@eskimo.com

Nov 13 '05 #78

Kelsey Bjarnason

[snips]

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.

Nov 13 '05 #79

Joona I Palaste

Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> scribbled the following:

[snips]
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.

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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Bad things only happen to scoundrels."
- Moominmamma

Nov 13 '05 #80

Kelsey Bjarnason <ke*****@xxnospamyy.lightspeed.bc.ca> writes:

[snips]

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.

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)

Nov 13 '05 #81

On Fri, 7 Nov 2003 11:31:59 +0000 (UTC), in comp.lang.c , Ian Woods
<ne******@wuggyNOCAPS.org> wrote:

Mark McIntyre <ma**********@spamcop.net> wrote in
news:0t********************************@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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Nov 13 '05 #82

On Sat, 08 Nov 2003 13:05:07 -0800, in comp.lang.c , Kelsey Bjarnason
<ke*****@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 :-)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

Nov 13 '05 #83

Ben Pfaff

Mark McIntyre <ma**********@spamcop.net> writes:

On Fri, 7 Nov 2003 11:31:59 +0000 (UTC), in comp.lang.c , Ian Woods
<ne******@wuggyNOCAPS.org> wrote:
Mark McIntyre <ma**********@spamcop.net> wrote in
news:0t********************************@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.)

Nov 13 '05 #84

Ben Pfaff wrote:

Mark McIntyre <ma**********@spamcop.net> writes:
On Fri, 7 Nov 2003 11:31:59 +0000 (UTC), in comp.lang.c , Ian Woods
<ne******@wuggyNOCAPS.org> wrote:
>Mark McIntyre <ma**********@spamcop.net> wrote in
>news:0t********************************@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"

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

Nov 13 '05 #85

Ian Woods

Richard Heathfield <do******@address.co.uk.invalid> wrote in
news:bo**********@titan.btinternet.com:

<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

Nov 13 '05 #86

[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...]

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 abot 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
sc*@eskimo.com

Nov 13 '05 #87

Roose wrote:

...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
sc*@eskimo.com

Nov 13 '05 #88

Steve Summit wrote:

[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.

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

Nov 13 '05 #89

Mike Wahler

"Steve Summit" <sc*@eskimo.com> wrote in message
news:20********************@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

Nov 13 '05 #90

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/....20031117.html

Point away.

Just for fun, I poured the same text into the new "clc wiki", at

http://clc-wiki.net/wiki/Portability...I_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
sc*@eskimo.com

Feb 4 '06 #91

sc*@eskimo.com (Steve Summit) writes:

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/....20031117.html

Point away.

Just for fun, I poured the same text into the new "clc wiki", at

http://clc-wiki.net/wiki/Portability...I_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.

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.

Feb 4 '06 #92

Default User

Steve Summit wrote:

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

Feb 5 '06 #93

Rod Pemberton

"Default User" <de***********@yahoo.com> wrote in message
news:44************@individual.net...

Steve Summit wrote:
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.

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

Feb 5 '06 #94