473,902 Members | 4,628 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

ANSI C compliance

Just to make a tangential point here, in case anyone new to C doesn't
understand what all these flame wars are about.

Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"

We are discussing whether this newsgroup should focus on 100% ANSI C or
simply topics related to the C language in the real world. There is a C
standard which is defined by an international committee. People who write
compilers refer to this in order to make sure their compilers follow the
standard -- that they actually compile C. However, they also add extensions
to the C language to make your life easier, and of course there are bugs in
the compilers and such.

So for various reasons, C you write which runs and works as expected on one
platform might not work on another platform. The C standard is there to
alleviate this -- to decide which compiler is wrong if they differ in
behavior.

What percent of non-trivial programs are completely ANSI C (i.e. they work
as intended on all platforms for which you have an ANSI C compiler, modulo
compiler bugs)? I would suspect somewhere near 0%, just like about 0% of
non-trivial programs are completely bug free. Even taking this into
account, I would suspect less than 5% of non-trivial C programs written are
intended to be, or actually are, standard C. It simply isn't necessary
engineering practice, although there are certainly exceptions. For example,
one job I once interviewed for was writing standard ANSI C implementions of
licensed technology, that were meant to be ported (by hand) to assembly on
DSPs by the licensees. That is, the idea was to write something for other
people to read and compile, not something to actually go in a real product.

Now, on to my point. Writing truly standard C as valued by the "regulars"
in this newsgroup is time-consuming if you're not experienced. And it takes
time to accumulate the knowledge necessary to do so. Thus, in the business
world, it is not considered good practice, since time = money.

There is a field of study you might call "software development", which is
the study of how real teams build real software products. There is a notion
called "speculativ e generality" (from one of Steve McConnell's books I
think, don't
remember which one, see also Martin Fowler). This is basically when you
write code that speculates on what you may need to write need in the future.
Instead of writing code that does exactly what you need to do, you write
something that does more than that, potentially. This is shorthand for
overengineering -- architecting a general system when a specific one will
do.

Writing 100% ANSI C when you are not in a special circumstance (like the one
I listed above) is considered speculative generality. Portability is a
feature of code. Thinking about portability to machine with 9 bit bytes or
2 stacks or no stack or 6 stacks is a waste of time (at least business time,
your personal time is free to be spent however you like), when you have no
forseeable need for it. Because this time could be spent working on
features that actually are required, ones that actually generate money.
Even if you DO have a forseeable need for it, it is considered good practice
to solve _only the problem at hand_. Business requirements are extremely
volatile. Executives are fickle.

An example. Our game started out on PS2. A couple years ago we ported it
to the GameCube and XBox. Did we have completely portable code at first?
No, we wrote a game for PS2. Would it have been easier to port if we had?
Sure, a little. But it wasn't a big deal to fix all the problems as they
came up, as compiled with *real* compilers. And so we did so, in a
straightforward manner.

Do we have standard C code now that we ported it? No. Do we need to? Not
really, the products sold more than 1.5 million copies and generated
millions of dollars in profits.

Now we are investigating porting it to PSP (Playstation portable). Would
it be easier if we have standard C code? Sure, a little. But what if we
never had to port to PSP? Then our effort writing standard C would have
been wasted. What if the PSP compiler has a bad bug that makes it
incompatible with ANSI C? (Not unlikely, since there is only one compiler
for these machines at first, generally).

In software development, *incur the development cost* of a feature *when you
need it*. Not any sooner.

So, the bottom line is, if I was working on making some old nasty code that
works ANSI C compliant, instead of implementing a feature on my schedule
(ANSI C compliance would be laughed off the schedule), my boss would be
PISSED. You don't do that. There is a very real risk of creating bugs in
already working code, which of course is much worse than that code not being
ANSI C.

That said, you should learn the basic rules of the language (to a reasonable
point, there is definitely a point of diminishing returns). Far too many
programmers hack blindly, just trying to shut the compiler warnings up.
(Believe it or not, I am actually the one on the team that adheres most
strictly to standards, e.g. I am the one who hates it when people use enum
as integers, even though that is standard, etc.. My co-workers would have a
good laugh at this, and wonder if this newsgroup is from another planet.)

So, the second bottom line is, that this is C programming in the real world,
which the overwhelming majority of people are interested in doing. As
opposed to whacking off in a newsgroup about their ANSI C knowledge as an
end in itself. That is why CLC is a terrible place to discuss ONLY ANSI C,
as there is already perfectly good place (CLC.moderated) . This is where
people new to C tend to come (as mentioned, alt.comp.lang.l earn-c-c++ is a
joke by its very title), and CLC.moderated would reject many of their posts
as off topic. Since they don't KNOW what standard C is yet, they don't know
what's on-topic.

Good day. If you have a reasoned response to this, I'd be interested in
your opinions.

(But alas, let the flames from the "regulars" begin...)

Roose
Nov 13 '05
100 7054
Mark McIntyre <ma**********@s pamcop.net> scribbled the following:
On Tue, 04 Nov 2003 05:40:15 GMT, in comp.lang.c , "Roose"
<no****@nospam. nospam> wrote:
Just to make a tangential point here, in case anyone new to C doesn't
understand what all these flame wars are about.

Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"

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


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

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

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates
Nov 13 '05 #41
Joona I Palaste wrote:
Mark McIntyre <ma**********@s pamcop.net> scribbled the following:
On Tue, 04 Nov 2003 05:40:15 GMT, in comp.lang.c , "Roose"
<no****@nospam. nospam> wrote:
Just to make a tangential point here, in case anyone new to C doesn't
understand what all these flame wars are about.

Shorthand title: "My boss would fire me if I wrote 100% ANSI C code"

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

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


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

--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #42
> If you stop to think about it, this is a pretty meaningless
statement. Take out the words "truly standard C as valued by the
regulars in this newsgroup" and replace them by any positive
attribute of code you can think of:

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

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

The other positives are of course worth their cost in all situations. Or at
least, they can be evaluated by the same metric... e.g. if I spend time
optimizing this code, what real benefit do I get? Does it matter?
There is a notion called "speculativ e generality"... This is
basically when you write code that speculates on what you may...
need in the future. Instead of writing code that does exactly
what you need to do, you write something that does more than that,
potentially.


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


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


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


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


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


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


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


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

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

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


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

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

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

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


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


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

Roose
Nov 13 '05 #45

"Jack Klein" <ja*******@spam cop.net> wrote in message
news:d2******** *************** *********@4ax.c om...
We are discussing whether this newsgroup should focus on 100% ANSI C or
simply topics related to the C language in the real world. There is a C

Your "real world" is most certainly not the same as my "real world".
One of the world's most used C compilers, gcc, has a command line
switch to compile FORTRAN. That's a "real world" use of a C compiler.
But it has nothing to do with the C language, which has one and only
one definition.
Not sure what the point of the fortran example is exactly, but I'm talking
about people who, at the expense of answering anyone's _real_ question,
ignore anything not related strictly to ANSI C, and instead inundate them
with irrelevant details about ANSI C. Again my claim is that -- regardless
of whether they are right to come here -- a lot of newbies do, and get
turned off to the C language. Yes, I've already heard all the responses
about reading the FAQ and such, and I maintain my position regardless.
So for various reasons, C you write which runs and works as expected on one platform might not work on another platform. The C standard is there to
alleviate this -- to decide which compiler is wrong if they differ in
behavior.


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


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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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


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

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

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

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


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


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


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

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

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

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

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

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

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


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


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

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"To err is human. To really louse things up takes a computer."
- Anon
Nov 13 '05 #48
On 2003-11-05, Roose <no****@nospam. nospam> wrote:

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

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


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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

In practical terms:

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

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

-- James
Nov 13 '05 #49
Richard Heathfield wrote:
specifier is %ul instead of %lu;


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

--
pete
Nov 13 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
2838
by: Acacia | last post by:
a) Does the C++ language never change? I was recommended to upgrade my MSVC v1.5 to a newer compiler - yet I thought that ANSI C++ was a standardised language and never changed - so why would i need to upgrade my compiler? More features? b) How good is C++? Would it be worth learning for a computer, and possibly programming, enthusiast? Has it got a long life ahead of it or is it likely to die out soon replaced by newer languages?
3
5940
by: Jack | last post by:
Hi I am just trying to get a feel for what oracle SQL syntax there is that would not be covered at all in anyway from a functionality perspective in the standard ANSI SQL.. Any input is appreciated.. Thank you, Jack
83
11670
by: sunny | last post by:
Hi All What is C99 Standard is all about. is it portable, i mean i saw -std=C99 option in GCC but there is no such thing in VC++.? which one is better ANSI C / C99? can i know the major difference between C99 & ANSI C standards?
0
9997
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9845
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10870
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10499
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9673
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
8047
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
1
4725
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4306
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3323
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.