ANSI C compliance

[BruceS]

Roose wrote:

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]

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]

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.

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.

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]

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]

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]

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


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?


Example, please.

<http://groups.google.com/[email protected]>

 

[Richard Heathfield]

<http://groups.google.com/[email protected]>

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]

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]

<http://groups.google.com/[email protected]>

Well, aren't you the sick little troll? Surely you could have found
something more valuable to your argument?

 

[Joona I Palaste]

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.

 

[Alan Balmer]

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]

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]

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]

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?

 

[Keith Thompson]

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]

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]

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]

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
(e-mail address removed)

 

[Kelsey Bjarnason]

[snips]

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]

[snips]

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