Re: ANSI C compliance

From: Roose (nospam_at_nospam.nospam)
Date: 11/05/03 

Date: Wed, 05 Nov 2003 08:57:29 GMT

"Jack Klein" <jackklein@spamcop.net> wrote in message
news:d2ogqvok0csrpbiib6qkniu54uuumq1n6t@4ax.com...
> > We are discussing whether this newsgroup should focus on 100% ANSI C or
> > simply topics related to the C language in the real world. There is a
C
>
> Your "real world" is most certainly not the same as my "real world".
> One of the world's most used C compilers, gcc, has a command line
> switch to compile FORTRAN. That's a "real world" use of a C compiler.
> But it has nothing to do with the C language, which has one and only
> one definition.

Not sure what the point of the fortran example is exactly, but I'm talking
about people who, at the expense of answering anyone's _real_ question,
ignore anything not related strictly to ANSI C, and instead inundate them
with irrelevant details about ANSI C. Again my claim is that -- regardless
of whether they are right to come here -- a lot of newbies do, and get
turned off to the C language. Yes, I've already heard all the responses
about reading the FAQ and such, and I maintain my position regardless.

> > So for various reasons, C you write which runs and works as expected on
one
> > platform might not work on another platform. The C standard is there to
> > alleviate this -- to decide which compiler is wrong if they differ in
> > behavior.
>
> Amazingly enough, I manage to write code that is non-standard
> conforming that works as expected on multiple platforms. Because I
> know enough about the C language and its implementation-defined
> aspects.

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

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

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

If an extension provides a reasonable benefit, and is reasonably common,
then it in effect a useful part of a _de facto standard_ (*gasp* : ) ). I
suggest that one might use such an extension and get the benefit, while
incurring the cost of removing it when business dictates that you port to a
platform that doesn't support it (which may or may not ever happen).

> For a current product I designed a communications protocol for an
> internal CAN network. And I wrote code to implement that protocol.
> That code is most certainly not 100% strictly conforming standard C.
>
> But that somewhat non-standard code compiles and runs correctly on
> four different processor types that interface to that bus:
>
> 1. An 8-bit big-endian microcontroller (8051 architecture). Chars
> have 8 bits and plain char is signed.

Sounds cool.

> > What percent of non-trivial programs are completely ANSI C (i.e. they
work
>
> You entirely miss the point. What percentage of all trivial and
> non-trivial C program, no matter how platform specific they are, could
> be written in completely standard C? I doubt if you would ever find a
> non-trivial program where this figure is less than 50%. Even in many
> large programs with loads of extensions, if is frequently above 90%.

OK, point taken. I will discuss the proportions of code in a project that
is ANSI C from now on.

> > Now, on to my point. Writing truly standard C as valued by the
"regulars"
> > in this newsgroup is time-consuming if you're not experienced. And it
takes
>
> One who is not sufficiently experienced in writing C programs properly
> should not be employed to do so, except perhaps as an apprentice, and
> should not claim to be a professional C programmer.

See my responses to Steve Summit... if you were a hiring manager, would you
limit your applicant pool in such a way, when it is clear that people who
are not completely familiar with strict ANSI C would be capable of meeting
the business objectives?

> > time to accumulate the knowledge necessary to do so. Thus, in the
business
> > world, it is not considered good practice, since time = money.
>
> Yes, the biggest problem with software in general is not C or C++ or
> Pascal or Visual Basic or any other programming language. It is
> programmers who believe like you, that business is served by shoddy
> guesses and half-baked efforts.

I don't see how this follows. Because I don't place high importance on ANSI
C does not mean I advocate "shoddy guesses and half-baked efforts". As I
have written elsewhere, I write for specific platforms, and choose to spend
my time on more important considerations like program architecture, rather
than the line-by-line details of individual pieces of code.

> Would you want to fly on an airliner engineered by aviation engineers
> who had their attitude about learning their discipline and doing
> design work that you express toward writing software?
>
> Would you want to be operated on by a surgeon who decided that
> performing quality surgery is too time-consuming to learn, and
> couldn't be bothered to take the time to accumulate the knowledge
> necessary, because "it is not considered good practice, since time =
> money".

These arguments don't mean much to me. As I said, time spent in one place
is not spent in another. I claim that, in many typical business situations,
when you are writing for specific platforms, ANSI C is not worth the time.
The time is much better spent learning your domain, whether it is airliner
hardware or medical equipment. Also, as I said, there much more important
general software development considerations, like writing unit tests,
improving your build process, training engineers in design principles, etc.

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

So where do you think the bottleneck typically is?

> > There is a field of study you might call "software development", which
is
>
> There is a field of study that is called "software engineering", and
> there is extensive research, much of it headed up by the US government
> funded Software Engineering Institute at Carnegie-Melon University.
>
> Engineering is a discipline, and there is sadly far too little
> discipline in software development. The field is too new, the growth
> too fast.

Agreed.

> This is very far afield from the main thrust of your post, however.
>
> You think there is value in diluting comp.lang.c to throw in
> discussions about anything anyone is trying to do with any C compiler
> anywhere. I, and many of other the regulars, disagree.
>
> It makes no difference whether you are writing C for a PIC
> microcontroller, a Cray supercomputer, a game console, or an
> "ordinary" Windows or Macintosh PC. A large percentage of the code
> should be or at least could be perfectly standard legal C. And aside
> from platform-specific issues that have nothing to do with the topic
> of this group, that is the C language, a certain percentage of the
> problems in even the most platform-specific program will be C language
> issues.
>
> Usenet groups that can't stay focused on a topic die. Our "sister"
> group comp.lang.c++ nearly had that experience about five years ago,
> where swarms of MFC and Windows specific newbies caused many of the
> most knowledgeable regulars to leave. Fortunately, a group of
> determined regulars turned back the tide barely in time, and
> comp.lang.c++ is a valuable resource for C++ programmers today.

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

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

Roose

Relevant Pages

  • Re: There has to be a better way to develop web applications.
    ... one manager still feels VB is not a programmers language, ... learn every tom dick and harry language, standard, and platform so you can ... > the context being discussed all of the arguements are on technology and not ... > on how to use the technology to increase productivity and to provide value to ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: ANSI C compliance
    ... One of the world's most used C compilers, gcc, has a command line ... But it has nothing to do with the C language, ... > platform might not work on another platform. ... Chars have 8 bits and plain char is signed. ...
    (comp.lang.c)
  • Re: Thinking Clearly
    ... than on platform API/Framework then "which platform" is a non issue. ... design is about tradeoffs not ideals. ... proprietary language, they would pay attention to a mass that large. ... They know so little about the VB developer market (the real ones ...
    (borland.public.delphi.non-technical)
  • Re: Delphi to bytecode compiler
    ... >>compability, since Delphi was designed as a compiled language, not as a JIT ... > compiler can still do global optimization, ... solve all their programming problems; ... > the platform independence of that code. ...
    (comp.lang.pascal.delphi.misc)
  • Re: Common Lisp is not a language
    ... | a) we do ANSI Common Lisp ... | b) here are some places where we don't do ANSI CL ... Required Language Features ... PURPORTS TO CONFORM v. makes a good-faith claim of conformance. ...
    (comp.lang.lisp)