I don't dissagree that standard coding methods are a good thing, I don't
dissagree that you should promote unity in the programming community and
standards are a way to accomplish this..  Now for the question.

How many of you ANSI C programmers have coded ENTIRELY in ANSI C for a
production program.  That is you haven't slipped in any small deviations
because ANSI would have taken too much time, or you couldn't figure out
how to do it in ANSI so you just cooked up some code to finish the
program.

So then who wants to be the first to say they code entirely in ANSI C?
Or how about this, do you all agree that ANSI C is the way you should
code production programs (that require C of course!!) - or is ANSI just
an ideal to shoot for.

Believe it or not I don't want to start a flame war, I'm really more
interested in how strictly production programmers hold themselves to the
ANSI standards.  I'm a system administrator and I browse this group to
glean some programming tips and to keep in touch with the community.  

Thanks for taking the time to answer nicely
Rob

Please don't confuse the forum with the arena. The newsgroup can function
only because discussion is limited (at least in theory) to ANSI/ISO C.
Opening it to discussions of platform-specific extensions would drown
discussion of C in noise.

A very direct result of my own participation in c.l.c has been that I make a
serious effort to write strictly ANSI code. When not possible (frequent) I
isolate POSIX calls in separate modules; and when I need to use non-ANSI,
non-POSIX extensions (/very/ seldom) that code is segregated from the
others.

This all struck me as a big PITA in the early stages; but has become
more-or-less natural with use.

    RG> After surfing this group for a while now, something has struck me as
    RG> interesting.  Everybody harps on writing ONLY ANSI C code, or only
    RG> posting question in ANSI C, or only praying to the ANSI C standards....

I don't think anyone uses _only_ ISO code in "real" programs.  The
point that is often made is that this newsgroup only deals with the
ISO portion of people's code.  ISO C is a "lowest common
denominator".  That is, most C compilers support ISO C, as well as
their own extensions.  By using as much ISO C as possible in your
code, you increase portability, as only localized changes must be
made.

The reason we only allow questions regarding ISO C is that it is what
everyone here knows.  If someone asks a question regarding, for
example, Borland C, I can't help.  And if someone posts an answer to a
question regarding Borland C, but it is incorrect, many of the experts
here would be unable to correct the answer.  However, if an incorrect
answer is given regarding an ISO C question, there are several people
here that can correct this.

[...]

    RG> How many of you ANSI C programmers have coded ENTIRELY in ANSI C for a
    RG> production program.  That is you haven't slipped in any small deviations
    RG> because ANSI would have taken too much time, or you couldn't figure out
    RG> how to do it in ANSI so you just cooked up some code to finish the
    RG> program.

I code as much as possible in ISO C.  However, I have never written a
real-world program that is 100% ISO.  On the other hand, if I do write
a program that uses non-ISO extensions, I don't post questions about
it here.  Most of my code is POSIX, and I would ask in
comp.unix.programmer.  What isn't POSIX or ISO is OS-specific, so I
ask in comp.os.qnx.

    RG> So then who wants to be the first to say they code entirely in ANSI C?
    RG> Or how about this, do you all agree that ANSI C is the way you should
    RG> code production programs (that require C of course!!) - or is ANSI just
    RG> an ideal to shoot for.

The core of the program should be ISO C.  Only the edges, where
non-ISO functionality is required, should other coding techniques be used.

[...]

    RG> Thanks for taking the time to answer nicely
    RG> Rob

Hope that was nice enough :)

Cheers,
Kevin

Of course, hardware components interfaces are target specific. But is is
very easy to abstract them to a simple

iowrite(context,register,data)
data = ioread(context,register)

pair of functions.

And you should not discuss problems with the system specific extentions
in comp.lang.c

Kurt

Be portable when you can, non-portable when you must.

Even if you are working on a program that interfaces with the features
of a platform, it can be useful and important to know which parts are
standard C and which are not, so that you can exercise proper hygiene
in separating these pieces in some way, so that the program is designed
with a plan for retargetting to different platforms.

By working in a smaller language, you can sometimes end up with larger
code, but all that is needed to understand that code is gathered in
one document, and it doesn't have to be corrected or bloated to support
additional platforms.

But do you really end up with larger code? I find that by understanding
the standard language in detail, I can use its portable subset much
more effectively than some programmer who gropes around in a
platform-specific C dialect with the help of an incomplete compiler
reference manual.

Also, it's worth mentioning another phenomenon you sometimes see:
programmers who don't understand ANSI C sometimes invent poor devices that
are supposed to aid the portability of the program. These devices actually
become counterproductive obstacles to readability and maintainability,
and are often nonportable anyway, or don't address true portability
issues.  The corresponding maximally portable ANSI C code is shorter
and cleaner by comparison.

Even if you are working on a program that interfaces with the features
of a platform, it can be useful and important to know which parts are
standard C and which are not, so that you can exercise proper hygiene
in separating these pieces in some way, so that the program is designed
with a plan for retargetting to different platforms.

By working in a smaller language, you can sometimes end up with larger
code, but all that is needed to understand that code is gathered in
one document, and it doesn't have to be corrected or bloated to support
additional platforms.

But do you really end up with larger code? I find that by understanding
the standard language in detail, I can use its portable subset much
more effectively than some programmer who gropes around in a
platform-specific C dialect with the help of an incomplete compiler
reference manual.

Also, it's worth mentioning another phenomenon you sometimes see:
programmers who don't understand ANSI C sometimes invent poor devices that
are supposed to aid the portability of the program. These devices actually
become counterproductive obstacles to readability and maintainability,
and are often nonportable anyway, or don't address true portability
issues.  The corresponding maximally portable ANSI C code is shorter
and cleaner by comparison.

    Still, portability and maintainability are not the only attributes
of importance in all circumstances.  They are usually less important
than correctness, for example.  Sometimes (less often than commonly
thought, IMHO) speed is paramount.  Sometimes the overriding criterion
is "Get it done by 3PM."  The craft of programming consists in large
measure of finding the right compromises between divergent goals, and
it is often the case that the compromises appropriate to Project X
would be anathema in Project Y.

    A reasonable approach to writing code when portability is important
(and IMHO it turns out to be important more often than not) is to use
the capabilities of the "weakest" or "broadest" standard at hand for as
long as they will suffice, to graduate to "stronger" or "narrower"
standards as and only as needed, and to resort to unstandardized methods
only in extremis.  This guideline tells me, for example, that most of my
program's code can be in Standard C, except for the parts which handle
the inter-process communication.  At that point I'll have to rely on the
family of Unix standards, but I'll stick to what they provide -- right
up to the point where I simply *must* use the Solaris "doors" interface.
Each time I invoke an additional standard I gain access to additional
capabilities at the cost of making my code more difficult to port.  The
important thing is to be aware of when you're crossing the lines, and
to do so only when there's a good reason.

    I'd like to revisit one of your remarks just a bit:

    Finally, to what I think is your main question:

If the purpose of the C language was portability, there would be
no implementation-defined, unspecified and undefined aspects of the
language.  Implementations would be forbidden to provide extensions.

If you want Java, you know where to find it :-)

This group is for and about ANSI C.  For non-ANSI stuff there are other
groups such as comp.unix.programmer, gnu.gcc.*, and so on.

  Standards?  We don't need any stinkin' standards!

   Well, actually, maybe you do.  It really is a question of what you
   want to do.

   The standard -- either one -- is not the End of All C.  Writing
   `strictly conforming' C code, however, has an enormous benefit.  The C
   standards are, in essence, a contract between you -- a programmer  
   writing C code -- and the implementor supplying your C compiler and
   library.  This contract says, in effect, that as long as you stick to
   your part of the bargain, the implementor must stick to his.  The
   moment you violate your side of the deal, the implementor is free to
   violate his, too.

   In practice, this means that any strictly conforming code you write
   will work on every C compiler. ... it also means that you can change
   compilers or even machines.  If, after getting halfway through a
   program, your boss comes to you and says `the model Q computer is
   obsolete; we're buying model R machines now' and you wrote Q-specific
   code, you will have to rewrite it all.  If you wrote standard C, it
   will all work on model R.

That way, porting to new platforms is made simpler, and anyone with ANSI
C knowledge (not necessarily knowledge of the target platforms) can get
a very good idea of the way the program works, very quickly.

--
Duncan Bayne
1974 Yamaha RD350

The *rest* of his post looked sane: I think you missed out.

Cheers,
Dave.