ANSI C compliance

[Roose]

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

 

[Richard Heathfield]

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.

Indeed. And people who write C programs refer to it to ensure that their
programs are C programs.

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.

Other newsgroups exist to discuss the extensions relating to particular
implementations and platforms. Please take up platform-specific discussions
in those other newsgroups. Thank you.

<snip>

 

[Ian Woods]

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.

Let me rewrite this paragraph a little:

comp.lang.c is a newsgroup dedicated to discussions about the C
programming language. The C programming language is defined by an
international committee and it's definition is published by ISO. People
write compilers which conform to this standard because otherwise they
wouldn't be compiling C. Many C compilers also have a non-conforming mode
as an extension which makes it behave like a compiler for a language
which is similar to but different from C.

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.

Hmmm... and this one:

Some parts of the standard are implimentation defined, so some C programs
will behave differently on another platform. The C standard defines the
behaviour of programs compiled with a C compiler, and where parts are
implimentation defined requires that the behaviour is documented by the
vendor. Any compiler which, when compiling a C program, produces an
executable with behaviour different to that defined by the standard for
the compiled source is not a C compiler.

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.

If your intention is to learn C, then do so. That is what is typically
discussed here. If you want to learn almost-but-not-C-from-a-specific-
vendor then there are newsgroups for that too.

This
is shorthand for overengineering -- architecting a general system when
a specific one will do.

I don't see how writing in C is overengineering compared to writing in 'a
C like language provided by some vendor'. It takes me no longer to write
in C than it does to write in almost-C for an implimentation I'm familiar
with.

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.

Indeed, it's a waste of time thinking about the portability issues
involved in making code work on such an array of systems. That's why we
leave it to C compiler programmers to do it for us. They worry about that
stuff, and I can just code in C secure in the knowledge that my program
will do what I intended it to do.

<snip business example of using languages like-C but vendor specific and
the effort of porting between them, and the financial success of said
project>

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

Indeed. This is why I write in C whenever reasonable, rather than for a
specific implimentation of it. If I need to do something which requires
vendor specific code, I do it at the latest possible opportunity rather
than earliest. I only incur the cost of having to examine and learn the
vendor specific parts when necessary.

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.

Certainly, if you're not programming in C to begin with then it takes
time in your schedule to make it into C later. Personally, I'll stick
with writing in C when reasonable, and only go into vendor specific non-C
extentions when they're needed.

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

Roose

*hands Roose some flame retardant underwear...*

Ian Woods

 

[Roose]

I'm going to respond to this as a serious answer, even though you are trying
to refute my arguments with a game popularized by Richard -- pretend that
the only thing that exists is what this newsgroup discusses. My article was
about things outside ANSI C, so to reason about it correctly, you must not
play that game.

If your intention is to learn C, then do so. That is what is typically
discussed here. If you want to learn almost-but-not-C-from-a-specific-
vendor then there are newsgroups for that too.

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.

I don't see how writing in C is overengineering compared to writing in 'a
C like language provided by some vendor'. It takes me no longer to write
in C than it does to write in almost-C for an implimentation I'm familiar
with.

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?

Indeed, it's a waste of time thinking about the portability issues
involved in making code work on such an array of systems. That's why we
leave it to C compiler programmers to do it for us. They worry about that
stuff, and I can just code in C secure in the knowledge that my program
will do what I intended it to do.

Point taken, but I still contend that portability is a feature. It costs
extra to make code ANSI compliant.

Indeed. This is why I write in C whenever reasonable, rather than for a
specific implimentation of it. If I need to do something which requires
vendor specific code, I do it at the latest possible opportunity rather
than earliest. I only incur the cost of having to examine and learn the
vendor specific parts when necessary.

Same logic applies, not talking about "you".

Roose

 

[nobody]

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

Nice touch. Warmonger doin' explainin'.

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

Sure, he actually compiles your crap with ANSI compatibility switch on
and if it compiles without diagnostics (s)he fires you. I don't think even
newbies are going to believe it.

We are discussing whether this newsgroup should focus on 100% ANSI C or

No, we are not. You are trying to change focus of this group (should I say
hijack?). This NG *is* about standard C. As it was already suggested,
feel free to create your own and feel free to choose your topicality.

simply topics related to the C language in the real world. There is a C

Geez, didn't know that C standards were created in some *un*real (world).

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

The fact that your boss doesn't like when C programs actually compile
doesn't necessitate change in focus of this NG. Suggestion: name your
NG comp.lang.c.non-compilable, with strict specification in FAQ that
compilable code is not permitted.

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

One of those various reasons is writing non-standard code, as proposed
by OP and it's "advice(s)".

alleviate this -- to decide which compiler is wrong if they differ in
behavior.

Alleviation lies exactly in adhering to standard.

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

What do compiler bugs have to do with standards? And it's not 0% - you
didn't write all C code in the Universe. Your suspicion is unjustifiable and
not
backed by any facts. Of course, only if we don't count your desire to
stir wars in this NG as a fact supporting your "suspicion".

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

Again, your suspition is not based on facts. Though it's nice
demagoguery: "I would suspect ...". Stirring emotions for your support
in absence of any real arguments?

intended to be, or actually are, standard C. It simply isn't necessary
engineering practice, although there are certainly exceptions. For

example,

Sure, you are entitled to your opinion, what you consider to be "necessary
engineering practice". Hope you are not going to program weapons systems
anytime soon and will stick with games (if even that claim of yours is
true).

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.

So the other people read it and compiled it, and that was it. Presumably
they had never used it for any "real product". They just bought it and read
it (whatever that means) and compiled it for fun of it. I won't be rude and
won't say that I hope you didn't get a job.

Now, on to my point.

Finally. Enough of foreplay already.

Writing truly standard C as valued by the "regulars"

No need for quotes.

<def>
Main Entry: 1reg·u·lar
Pronunciation: 're-gy&-l&r, 're-g(&-)l&r
Function: adjective
3 a : ORDERLY, METHODICAL <regular habits> b : recurring, attending, or
functioning at fixed or uniform intervals <a regular income> <a regular
churchgoer>
4 a : constituted, conducted, or done in conformity with established or
prescribed usages, rules, or discipline b : NORMAL, STANDARD: as (1) :
ABSOLUTE, COMPLETE <a regular fool> <the office seemed like a regular
madhouse> (2) : thinking or behaving in an acceptable, normal, or agreeable
manner <was a regular guy> c (1) : conforming to the normal or usual manner
of inflection
</def>

As you've promissed, you are getting to your point. You simply can't
stand if something is regular like in "orderly", "methodical", "normal",
"standard" and more form above. So you have decided to bring discord,
so you can have some fun (as admitted in previous posts of yours) in the
ruse of 'C language for all', 'down with despots-regulars' and similar.
Well, C is for all who are willing to do some walking, not only talking.

in this newsgroup is time-consuming if you're not experienced.
And it takes time to accumulate the knowledge necessary to do so.

What an unholly idea - to extend one's effort to achieve one's goals.

Thus, in the business world, it is not considered good practice,

I'm sure that interested reader will find plenty of supportive evidence
for above claim as published by "Roose" and other internationally
recognized business analysts and other authorities.

since time = money.

OK, Roose, let's start with basics. In standard (not yours) C,
"=" is assignment operator. If you want to get idea of equivalence
accross in clc, you should use "==" instead. Please feel free, in your
new NG, to redefine the language. Also I would strongly suggest
to rename it.
"Yours only, Roose, will be Fame,
and clc regulars will fall in Shame"

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

Obviously, Roose doesn't want to only change focus of clc and redefine
(C) language, it is also trying to redefine terms so less knowledgeable
or experienced folks would fall into it's (liar's) lair. Roose is presumably
the only one working in *real* team building *real* software products,
and therefore the only authority on how such things are done and should be
done. Rest of participants in this NG are either newbies needing Roose's
directions, so they can become members of *real* teams and build *real*
software products, or old farts who know nothing about *real* C, *real*
software development, *real* business, and *real* life in general. They
know only thing or two about standard, which is *real*, but obsolete
and harmful for *real* developers (like Roose) working on *real*
projects (alas, like Roose).

called "speculative generality" (from one of Steve McConnell's books I

Indeed, "speculative" part was demonstrated by OP very sucessfully.

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.

Like, for example:
int* pi;
int i = *pi;

This code instead of doing "exactly what you need to do", "does more than
that, potentially". Depending, among others, on platform, time of day and
what program was swapped before you loaded yours. If you try hard
enough, you even get SIGSEGV, which old clc fossils would jelaously
try to take away from you. Don't let them! Think, guys,
what great potentials you can achieve under Roose's directions,
unimanigable under orderly, methodical, normal, standard regulars.
What beautiful life's rewards are awaiting it's followers.Heaven pales in
comparision.

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)

Roose's loathing of *any* order, rules, conventions or standards surely
makes it expert on defining "special circumstance". Suggestion for
comp.lang.c.non-compilable:
Q 7.2: What is a "special circumstance"?
A: Special circumstance is any event, or set, combination or permutation
of events as decided by Roose from time to time as dictaded by it's mood
and other factors, with retroactive applicability and subject to change
without any notice, and subject to no change with maybe some advanced
notice.

is considered speculative generality. Portability is a
feature of code.

For sure it is not feature of code written by you, as you are admitting
elsewhere in this post.

Thinking about portability to machine with 9 bit bytes or
2 stacks or no stack or 6 stacks is a waste of time

Because of standard's abstractions, you *don't* have think
of it, if you adhere to standard. Not to have to think about
something can be hardly demonstrated as a waste of time.
Of course, in Roose's world, where portability is defined
differently, you will have to think about it every time when
you want to "port". If yo are lucky enough (or paid enough
attention to Roose and followed it's advices), you will have to
rewrite everything from scratch. Well, I guess for some it's viable
definition of "porting".

(at least business time,
your personal time is free to be spent however you like),

I like that - benevolent leader.

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

If you adhere to Roose's teaching and dogmas ("standard C. It simply
isn't necessary engineering practice"), you won't have to worry about
your jobs any more. There always will be some "problem at hand".
Plenty of them. So there will never be time to be "spent working on
features that actually are required, ones that actually generate money".
Really fascinating. Ultimate job security. ("Can we fire Fred"? "No,
we can't". "Why not"? "He is fixing some problem at hand". "And
what about Lucy"? "Same, she is working on another problem at hand".
"And Roose"? "No way, she is leading them".)

Business requirements are extremely
volatile. Executives are fickle.

Which is sufficient evidence in itself for abandonment of all standards,
be it C, ethical, accounting or other regulatory (standards).

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.

And maybe Roose is bullshitting everybody and didn't get past of
successful compilation of "Hello word".

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.

And I was wondering why my kid's console freezes from time to time
and needs to be rebooted. Now I know. It's funny how someone
is proudly displaying it's ignorance and incompetence. Even if it
admitted it doesn't exists.

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 user didn't press Enter without any data? Then my effort
writing checks for errors would have been wasted.
What if pilot didn't bank in such a way, than my effort checking
from negative value would have been wasted.
What if my car didn't crash? Then my effort buckling up would have
been wasted.
Quite novel reasoning concepts.

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

So you see? Because there may be non-conforming compiler on some
platform, it makes sense to write non-comforming code.

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

Sure. Like when enough patients die because of software malfunction.
Then we will fix it. Or when enough planes fall from the sky. Treshold
value determination will be left to developer. *Real* one.

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

Sure. For individuals lazy enough to learn (or stupid enough), writing
ANSI C compliant code has to be reflected in the project schedule.
And it requires immense intellectual effort to switch relevant compiler
flags on and off. And who has time reading diagnostic messages these
days, anyway?

my boss would be
PISSED. You don't do that. There is a very real risk of creating bugs in

Only bugs seem to be only in your already not working head. (I'm not
mentioning brain on purpose. It's existence wasn't demonstrated yet.
But I suspect it's non-existence might be.)

already working code, which of course is much worse than that code not being
ANSI C.

Incompetent can **** up any code - already working or not. Which is
noncorelated to conformance of code.

That said, you should learn the basic rules of the language

Like assignment and logical operators, for example.

(to a reasonable point, there is definitely a point of diminishing

returns).

Of course, definition of "when enough is enough" will be supplied by Roose,
from time to time, and all that.

Far too many programmers hack blindly,
just trying to shut the compiler warnings up.

From your ravings it's clear that it's far_too_many++;

(Believe it or not, I am actually the one on the team that adheres most
strictly to standards,

Readers should be beware of what "strictly" means in Roose's world.

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

I guess this NG wonders the same about you.

So, the second bottom line is, that this is C programming in the real

world,

Sorry for omission. Please name your NG comp.lang.c.non-compilable.real.

which the overwhelming majority of people are interested in doing. As

Presumably Roose performed representative poll, so it must know
what "overwhelming majority of people are interested in doing".
Maybe it will be kind enough and share data with the readers,
together with applied methodology.

opposed to whacking off in a newsgroup about their ANSI C knowledge as an

No one called you here. You don't like it, please feel free to leave
any time. Still some space left on news servers for your own group,
with your own rules. If you know what "overwhelming majority"
and all this want to do, they for sure will follow your call and you
won't need to waste your time with rigid fossils. Why not to leave
them peacfully alone here until they die of old age, and in meantime
you can build yourself your little imperium in form of new NG based
on whatever misconceptions you choose.

end in itself. That is why CLC is a terrible place to discuss ONLY ANSI

C,

Normal people tend to leave terrible places, as soon as they discover
how terrible they are. They just don't persist there and bitch about
how terrible places they are. Especially if no one holds them there
and there is plenty of space in virtual neighborhood.

as there is already perfectly good place (CLC.moderated). This is where

As it was explained to you, and as names indicate, both groups are
about same "thing", only one of the groups is moderated. Don't lie
at least about facts what everyone can see and verify. Actually, why
*you* don't move there and moderate it - this way it will be *you*
who decides who speaks and who not. This is what you are after
anyway, so it is really "already perfectly good place (CLC.moderated)"
for all your purposes - both clearly advertised and those yet hidden.

people new to C tend to come (as mentioned, alt.comp.lang.learn-c-c++ is a
joke by its very title),

As mentioned by "regular". No need to hide the fact. Or are you sooo
embarassed that you've agreed on one point with regular?

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.

At best, you are again trying to mislead. FAQ and answers tell them both
about standard and topicality. You are trying to convince people that
they should vacate clc (and you take over, of course) and you had found
them good new home, at all that. Suddenly, you are new-born authority
on *real* programming in *real* C and to hell with everyone, right?
I don't think so.

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

I don't think you will recognise *any* reasonable response as such.
Judging by my experience of redefinition of terms by you.

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

Ah, here we go. Now I know how you translate "reasonable".
And as for flames, this is what you are trying to do, right? What
about spending your time fixing bugs in your software instead?
It would for sure serve better purpose than igniting wars on almost
daily basis.

 

[nobody]

I'm going to respond to this as a serious answer, even though you are trying
to refute my arguments

You are still top-posting, therefore you are not serious. BTW, either
news server or my newsreader must have stripped any arguments you
may have made in OP. Surely only this must be reason I didn't find
any. If both server and client software function properly (presumably
because they don't adhere to any standard), reason may be something
else. Like your omission to post any (arguments). In that case, whoever
you are responding to (which is not clear thanks to your insistence on
top-posting) may have find it hard to refute them (non-existent arguments).

 

[Richard Bos]

We are discussing whether this newsgroup should focus on 100% ANSI C

No, we aren't. _You_ are discussing that. The regulars know that it
_does_. Now be a decent netizen and drop it.

Richard

 

[Ian Woods]

I'm going to respond to this as a serious answer, even though you are
trying to refute my arguments with a game popularized by Richard --
pretend that the only thing that exists is what this newsgroup
discusses. My article was about things outside ANSI C, so to reason
about it correctly, you must not play that game.

Most of the time I skip through comp.lang.c and only really read the most
recent threads and threads to which I've previously contributed. This is
the case here. I wasn't aware that I'd stumbled into a game being played
between yourself and Mr. Heathfield.

With regards to what this newsgroup discusses, that's covered in the FAQ.
Even outside of the FAQ and this newsgroup, however, how do you define C?
For me that question is easy to answer: I have a document which defines
C. When people speak of C I look to the most authoritative definition of
C which I know about.

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.

Here I'm using you not to refer to 'Roose' but as an impersonal pronoun
(though, rereading that's not completely clear). Usually, I don't use the
term 'one' because it sounds pretentious. But, I shall rewrite my
paragraph as it was meant and bugger the pretentiousness:

"If one's intention is to learn C, then do so. That is what is typically
discussed here. If one wanted to learn almost-but-not-C-from-a-specific-
vendor then there are newsgroups for that too."

I hope that clears up the meaning.

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?

Assuming he was hired as a C programmer, I'd expect him to be familiar
with C. If he were hired as a programmer of some particular
implimentations not-C I wouldn't have that expectation. In either case, I
would have ensured that original job description was accurate, and if
not, then I'd like to know why not and how that could be corrected. The
correction may very well involve some retraining time for the
accidentally mis-hired programmer. I certainly wouldn't, as a manager,
knowingly hire someone as a C programmer who wasn't one.

I have, on and off, worked on projects in C with people who are only
familiar with a particularly implimentation, and typically not the one
which the project is using. In these cases I do my best to vet their
code, and usually in a few weeks, no more than casual vetting is
required. It's rare that this makes projects overrun since there's
usually time for such code reviews already set aside.

Point taken, but I still contend that portability is a feature. It
costs extra to make code ANSI compliant.

Yes, it would cost extra if you (or one) were to make code C after it
were written. I don't see how it costs extra if the code is written in C
in the first place. The handful of people who I've 'mentored' whilst they
were learning C didn't (at least as far as I saw) find their learning any
harder than a specific vendors C implimentation. The 'portability' they
effectively get without having to go out of their way thinking about it
because they naturally code the way they do.

<snip>

Ian Woods

 

[rihad]

You are still top-posting, therefore you are not serious. BTW, either
news server or my newsreader must have stripped any arguments you
may have made in OP. Surely only this must be reason I didn't find
any. If both server and client software function properly (presumably
because they don't adhere to any standard), reason may be something
else. Like your omission to post any (arguments). In that case, whoever
you are responding to (which is not clear thanks to your insistence on
top-posting) may have find it hard to refute them (non-existent arguments).

I've seen this kind of "top-posting" coming even from regulars, so it's got to
be fine. This is not even top-posting in the strict sense, but a kind of a
"prelude", background, to what will come.

 

[Joona I Palaste]

No, we aren't. _You_ are discussing that. The regulars know that it
_does_. Now be a decent netizen and drop it.

But Roose's boss doesn't want him to write standard-compliant code, so
therefore no one uses standard-compliant code, and this whole
newsgroup is meaningless.

 

[Richard Bos]

But Roose's boss doesn't want him to write standard-compliant code, so
therefore no one uses standard-compliant code, and this whole
newsgroup is meaningless.

Then I see no problem with Roose getting the fsck off this meaningless
newsgroup and finding a meaningful one somewhere else. Or with him
trying to create the group comp.lang.c.unportable.

Richard

 

[Joona I Palaste]

Then I see no problem with Roose getting the fsck off this meaningless
newsgroup and finding a meaningful one somewhere else. Or with him
trying to create the group comp.lang.c.unportable.

Believe me, you're not the only one who sees no problem with that. In
fact, Roose is the only one who does.

--
/-- Joona Palaste ([email protected]) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"As a boy, I often dreamed of being a baseball, but now we must go forward, not
backward, upward, not forward, and always whirling, whirling towards freedom!"
- Kang

 

[goose]

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

we are not. *we* already know what this newsgroup focuses on. *you*
dont know what it focuses on, apparently.

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

everyone already knows that there are compiler specific extensions
to ANSI C. but we also know that there are newsgroups dedicated
to that. this newsgroup is dedicated to ANSI C. if you require
a borland answer, go to a borland newsgroup, if you require a
sparc answer, go to the sparc newsgroups.

why are you all het up about the fact that you've been off-topic
numerous times ? why not just accept the advice given to you and
get back on topic ?

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

that wasn't a flame, btw

hth, hand
goose,

 

[Irrwahn Grausewitz]

yet another irrelevant troll-post, filled with loads of non-arguments.

To whom it may concern
======================

Roose is an individual incapable of accepting the fact that his
attempts to take over comp.lang.c are futile. His posts are best
ignored, as they are either poor examples of usenet trolling or
contain misleading information, or both.

In order to get an idea what comp.lang.c is all about, it is strongly
suggested to read the following documents:

Welcome message for comp.lang.c, by Billy Chambless:
http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html

FAQ-list for comp.lang.c, maintained by Steve Summit:
http://www.eskimo.com/~scs/C-faq/top.html


Regards

 

[pete]

Roose wrote:

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.

Which compiler is wrong because your code
won't work on more than one platform ?
That's a joke. Get it ?
While there might be a problem with a particular compiler,
if you haven't learned how to write portable code,
then the problem is very most likely your code.

The way to write portable code,
can't be construed from your compiler experiences.
How to write portable code is on topic.
It has everything to do with the C standard.

 

[Alan Balmer]

I'm going to respond to this as a serious answer, even though you are trying
to refute my arguments with a game popularized by Richard -- pretend that
the only thing that exists is what this newsgroup discusses. My article was
about things outside ANSI C, so to reason about it correctly, you must not
play that game.

Please play your game somewhere else. You have it wrong - it's not
that "the only thing that exists is what this newsgroup discusses.."
The point is that this newsgroup discusses what is on-topic for this
newsgroup. Other things exist, are interesting to discuss, and are
discussed - elsewhere. Not here.

 

[Roose]

Which compiler is wrong because your code
won't work on more than one platform ?

No, learn to read, if the compilers differ in behavior. Example: if one
accepts void main() and one doesn't. Spare me the nitpicks.

 

[Richard Heathfield]

I'm going to respond to this as a serious answer, even though you are
trying to refute my arguments with a game popularized by Richard --
pretend that
the only thing that exists is what this newsgroup discusses.

That's a travesty. This newsgroup discusses C. Other things exist apart from
C, but we don't discuss them here. We discuss them elsewhere.

My article
was about things outside ANSI C,

Then it is off-topic in this newsgroup. If you wish to discuss things
outside C, please post contributions to such discussions in a newsgroup
where they are topical. Thank you.

<snip>

 

[Guest]

That's a travesty. This newsgroup discusses C. Other things exist apart from
C, but we don't discuss them here. We discuss them elsewhere.

A most interesting statement and in direct contradiction of what you
have stated previously:

"On the other hand, comp.lang.c is /also/ a community, and as
such has its own internal community dynamics. These include
backchat, in-jokes, and the occasional protracted OT discussion.

"In other words, it's okay for "us" to post OT, but not okay
for "them"."

Why do you deny the truth now?

By your own statement, you _do_ discuss things here that exist apart
from C.

--

 

[Tom St Denis]

Why do you deny the truth now?

By your own statement, you _do_ discuss things here that exist apart
from C.

Occasionally meta-threads [e.g. OT] are required to control/advise/etc the
group. This doesn't mean that OT posts are ok here just that there are
instances [like say, this one] where it's tolerable.

If your post is truly about the C language then post away. If it isn't then
find an appropriate group. Can't be any simpler than that.

Tom