Common misconceptions about C (C95)

[Walter Banks]

I was surprised that the standards committee decided to fix asctime(),
and I suspect strongly that my personal campaign against it was
one of the reasons the committee decided to fix it.

WG14 needs a paper trail to support arguments for change either
through defect reports to resolve ambiguities or formal documents
to make changes in the standard.

w..

 

[Nick]

WG14 needs a paper trail to support arguments for change either
through defect reports to resolve ambiguities or formal documents
to make changes in the standard.

So, another 7 posts of the same old crowd (on both side) and f-all
about C again. Can you *all* leave it out, guys?

 

[Stefan Ram]

I have created a text available under GNU FDL 3 (Free
Documenation License) or later, regarding "Common
misconceptions about C" (C95).

»This second edition cancels and replaces the first
edition, ISO/IEC 9899:1990, as amended and corrected by
ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and
ISO/IEC 9899/COR2:1996.«

ISO/IEC 9899:1999 (E)

This means that C is the language specified by ISO/IEC
9899:1999 (E). »ISO/IEC 9899:1990« is canceled.

 

[robertwessel2]

Richard Tobin a écrit :

C++ NEEDS the cast... If you ever want to compile your code in C++
mode it is better to leave the cast there.

Better still, remove both the cast and the call, and replace it with
new or new[].

Aside from the missing-prototype issue a type for the return from the
allocation function. Something like:

#define CALLOC_TYPE(type) ((type*)calloc(1, sizeof(type)))
#define CALLOC_ARRAY(count, type) ((type*)calloc(count, sizeof(type)))

(and probably malloc versions as well).

Those would probably take care of most actual allocations, and help
prevent type errors. And of course the raw functions remain
available, if those better serve the purpose.

 

[Keith Thompson]

»This second edition cancels and replaces the first
edition, ISO/IEC 9899:1990, as amended and corrected by
ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and
ISO/IEC 9899/COR2:1996.«

ISO/IEC 9899:1999 (E)

This means that C is the language specified by ISO/IEC
9899:1999 (E). »ISO/IEC 9899:1990« is canceled.

In theory, yes. In practice, conforming C90 compilers are still
much more common than conforming C99 compilers. Many compilers
implement large parts of C99, but others, still in common use,
implement almost none of it (more precisely, almost none of the
differences between C90 and C99).

 

[Kenny McCormack]

Richard Harter <[email protected]> excellently summarized the state of
affairs that constitute comp.lang.c, thusly - very charitably
attributing all this wisdom to yours truly:
....

You have to appreciate that Kenny doesn't care about the actual
issues of writing and using C. His chosen function is mocking
the "regulars". In his fantasy world Heathfield is a Svengali
figure who dominates c.l.c with an in-group clique. According to
Kenny the regulars have nothing of consequence to say about C;
rather they spend their time putting down the pretensions of
inferiors by pointing out clique nominated coding errors.

Kenny will be happy to list them for you - he does it as a
regular thing. They include such things as void main(), casting
malloc, i = i++, etc. Kenny doesn't care whether they are coding
errors or not - as far as I can tell he doesn't have any interest
in C as such. To him the "errors" in his little list are
shibboleths, tokens by which the insiders know each other and
establish their credentials.

Well done. 5 star post by Mr. Harter (5 bonus points there, right Richard?)

 

[Kenny McCormack]

If so, why? If not, why is the void pointer from malloc any different?

Mr. Harter is quite correct in saying that I don't care one way or the
other about the C stuff. The reasons for this are complex and deep; my
plan is to reply to your other thread in which you inquire as to my
motives. If I work up the energy, I will post there. Until, you'll
just have to trust your imagination...

 

[spinoza1111]

spinoza1111wrote:



Start with some basic metrics. Count cycles and generated code.

a) Take the half dozen or so cases and hand code them up as
    micro operations and

b) then separate all those micro operations that can be done at
    compile time and those that must be done at run time

c) Map the micro operations on the instruction set you are using
    and count cycles  and bytes.

The most significant differences will be the base address of an
array is generally a constant that can often be optimized out
with instruction selection or compile time math.

Constant index references are generally a big win for arrays
in most execution environments

You really probably should have finished your book. Code
generation and optimization are about 90% of creating a
compiler. This stuff is pretty fundamental to that process.

Bullshit. If you don't understand parsing, the compiler is worthless.
And if you don't understand modern language design, the compiler is
even more worthless. Kernighan and Pike didn't understand modern
language design in 1970, because their mistakes in designing C
(aliasing, the preprocessor, the use of magic libraries, a broken
pseudo-for, pre-increment and post-increment not thought out in terms
of sequence, no strings, no characters properly understood, an integer
thought to have 16 bits in the original edition, braces used instead
of begin and end keywords at a time when braces weren't even available
on many keytops, two different ways of talking about arrays, etc)
became ... drum roll ... modern language design, rule one of which is
"please, don't EVER do another C".

Please, do not reinvent C
One such language was enough for me
One such language is enough for thee
One such language is enough for such as we
Are. Stay far
Away from C.
Oh say can you see
Any creeps who love C?
It's JUST a good way
Of hiding incompetency.

Old Basic was a better language and old Basic was a bad language. The
conclusion follows, directly.

Oh yes, and I did finish my book. It is available in stores and you
need to buy a copy. I'd send you a courtesy copy if you deserved one,
but you do not. It covers optimization and spends a whole chapter on
code generation for .Net, but the real meat is parsing since if you
screw up parsing there's not point in either code generation or
optimization, is there now?

 

[spinoza1111]

Richard Tobin a écrit :

C++ NEEDS the cast... If you ever want to compile your code in C++ mode
it is better to leave the cast there.

I can't believe that NOT using the cast is a fashion statement. We
know that strong typing is more reliable than weak typing. We also
know that "efficiency" of computation in the sense of a metaphorical
speed is not something as important as its correctness, and that lowly
technicians overrate speed out of a childish attraction to the
computer-as-toy.

 

[Tom St Denis]

Richard Tobin a écrit :

Better still, remove both the cast and the call, and replace it with
new or new[].

Aside from the missing-prototype issue a type for the return from the
allocation function.  Something like:

#define CALLOC_TYPE(type) ((type*)calloc(1, sizeof(type)))
#define CALLOC_ARRAY(count, type) ((type*)calloc(count, sizeof(type)))

(and probably malloc versions as well).

Those would probably take care of most actual allocations, and help
prevent type errors.  And of course the raw functions remain
available, if those better serve the purpose.

Yeah but it still misses the problem that without a definition the
compiler won't know if it needs to convert parameters to the right
data type. malloc() needs a parameter that is of size_t size. How is
the compiler to know this?

The reason the casts are bad is it silences a warning that points out
you are calling a function without a proper prototype.

To the C++ crowd, if you mix C and C++ in a project, put your C code
in .c files and have your make system not explicitly call the C++
compiler for them. Build it in C mode, it's C code.

Tom

 

[spinoza1111]

Michael Tsang was claiming that the use of malloc without a cast *is*
considered poor practice.  Seebs was disagreeing with him (as did I).

"As did I", you say, with a sigh
But you cannot say why.
Malloc with a cast may hide your stupid errors
So you omit the cast in hopes this will ease your nighty-time terrors.
The problem is clear, my dear
Boy.
You're using a programming language, C
That became fashionable only because it came from
Princeton University.

 

[spinoza1111]

Casting is a way to defeat strong typing.

   int a;
   char *p;
   ...
   p = a;

This is an error requiring a diagnostic.

   int a;
   char *p;
   ...
   p = (char *)a;

This is not.  The cast tells the compiler *not* to apply its usual
strong typing, but to convert the value to a character pointer
regardless.

Agreed.

The problem here is that it's possible to "know" C without actually
knowing how to program, which would IMO include sensitivity to types
and in general meaning. As it is, most CLCers here, with the exception
of you and Kenny for the most part, are without being aware of it
stuck in a logical atomism in which there are no distinctions of type:
shoes and ships and sealing wax are all the same to them.

That's what makes this newsgroup a simulation of the Mad Hatter's tea
party in Alice in Wonderland. Carroll anticipated the madness of the
20th century and one of its madnesses was the elimination of the
notion that there are incommensurate types of being. Capitalism, after
all, had through the commodity relationship made it possible to equate
all men and all things through the cash nexus, so it seems natural for
the C programmer, incompetent as a person and programmer in direct
proportion, usually, to his expertise in C, to want to use snoid
pointers, that point to his favorite space: a space in which there are
no distinctions of type: the space of the autistic child who can then
impose his private order on that space.

 

[spinoza1111]

Since the casting is not needed, using it is a bad style. At least, it shows
that there is luck of C knowledge.

Programming is difficult enough when properly done, which is why it's
so seldom properly done; most people here cannot code extempore to the
extent that if anyone does, he is exposed to the vilest kind of
personal abuse for months, an abuse based on envy.

But to make a programmer code to show off a knowledge of what Kenny
and I call the shibboleth, to code defensively in the event that some
Fat Bastard like Heathfield might shit all over you in a way that your
employer can see...that is obscene.

Using malloc with a cast may show a lack of insider knowledge of a
broken language, but it shows purity of heart and competence instead.
I'll take the latter.

 

[spinoza1111]

  shows that there is lack of C knowledge.

(Sigh) Right, welcome to hell, you'll feel right at home. Sit over
there, between Fat Bastard and Scott Evil. Watch out for Mini-Me, he's
an ankle biter.

 

[spinoza1111]

Because you said we should cast in C, because using malloc() needs a casting
in C++, where using malloc() is considered poor practice.

Oops. I think you meant "with a cast", and, you're wrong anyway. You
write better than most of the "native" English speakers here but you
need to proofread your copy more carefully.

 

[spinoza1111]

But we were discussing casting a "void*", which is C's own opt-out of
static typing.

C doesn't care about either implicit or explicit casts of void* to other

Whenever a programmer starts talking about an object such as a piece
of hardware "caring" about something I know he's incompetent. And when
he starts talking about an idea "caring" about something I know that
he's barking mad, even though he might be in a group where this is
perfectly acceptable, since workgroups, companies, organizations and
whole societies can be in my opinion barking mad: cf. Dianne Vaughan's
"The Challenger Launch Decision" U of C press 1999 and Colin Powell's
UN speech of March 2003 on Saddam Husayn's supposed WMDs on this
matter.

 

[spinoza1111]

Richard Harter a écrit :




If you care to search in the archives, Kenny has sometimes given
very good answers to questions posed here.

He has.

Yes, That is why I think he is a good poster here.

He is. And you are a star, une etoile.

That analysis is correct.

It is.

I have posted code here, proposing a container library for C.
Heathfield answered that he did not want to be involved
"with a looser" and never participated in a meaningful way
in those discussions. Neither Mr Thompson, nor most of the
clique in c.l.c. They have nothing to say about an improvement
of C, or about software engineering or about just anything
positive.

Their common approach is to announce that someone else is wrong
without taking the risk of being wrong, and without explaining why.
They actually believe that negation is knowledge. They may all be
barking mad, and this may be why they like to accuse dissidents of
insanity.

Iwas surprised that the standards committee decided to fix asctime(),
and I suspect strongly that my personal campaign against it was
one of the reasons the committee decided to fix it. Heathfield and
the others of the clique were always trying to justify asctime()
misgivings or downplaying the issue's importantce.

Sounds pretty nasty.

What the evolution of C is concerned, Heathfield (and Co) are
always complaining that standard C is not widely implemented,
ignoring all the implementations of the standard. Heathfield
uses a compiler version from the last century, and then it says
that gcc doesn't implement C99 even if he knows (as everybody
else) that C99 is quite well implemented in gcc, in the
linux versions at least.

Incroyable, quel dommage.

Thousands of messages about those "questions" pollute this group
and the insistence of the regulars to discuss those "issues"
AD NAUSEAM makes this group specially boring.

In my posts I try to improve the technical level of this group by discussing
interfaces, ways of doing things, abstract data types, etc. Neither
Mr Thompson nor Mr Heathfield are ever present in those discussions.

You do, and I welcome your contributions. Perhaps we could start a
Facebook group of people unhappy with CLC to discuss C issues.

Obvious.

What could they possibly say?


This is your unjustified personal opinion. I could say that YOU
have no interest in C either. You never bring your code here, or
bring subjects about programming in C in general. Can you please
tell me when was the last time you proposed something to discuss here?

Harter has posted good material but apparently only in the distant
past.

Thanks.


Obviously there are many other errors that could be dicussed. But
they aren't. Only those are selected, to recognize who is a member
of their group.


Weeding the garden is the activity of failed philosophers, unable to
grasp what makes us human: Infinity.

Correct. And to idolize the flaws of an outdated language is obscene.

 

[spinoza1111]

Programming is difficult enough when properly done, which is why it's
so seldom properly done; most people here cannot code extempore to the
extent that if anyone does, he is exposed to the vilest kind of
personal abuse for months, an abuse based on envy.

The abominable treatment of Jacob Navia, who's written an excellent C
compiler, is an example.

Heathfield appears to be a failed software manager skilled at rote
memorizing saws and shibboleth, and enabling the destruction of others
by initiating gossip campaigns.

This situation may go critical in the sense of a lawsuit or an article
in a "prestige" non-computer journal. It's the underside of the
"information society" that elites like because it creates
opportunities to force people to work for free, from unpaid programmer
overtime to "open source", and it results from self-policing of
workers by workers, where the workers with the least principle become
thugs in charge.

Navia, Kenny, Richard-not-Heathfield: you are not alone. Keep up the
good work.

"I see upon their noble brows the seal of the Lord, for they were born
kings of the earth far more truly than those who possess it only from
having bought it."

George Sand

 

[spinoza1111]

In theory, yes.  In practice, conforming C90 compilers are still
much more common than conforming C99 compilers.  Many compilers
implement large parts of C99, but others, still in common use,
implement almost none of it (more precisely, almost none of the
differences between C90 and C99).

--
Keith Thompson (The_Other_Keith) (e-mail address removed)  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

You know, Kiki, I met a gal last Sunday in Wanchai. She'd served as a
volunteer aboard a research vessel out of Scripps researching the
Pacific "garbage gyre", a vast, Texas-sized collection of plastic and
other trash floating in the ocean.

She said it was the worst thing she ever saw. She won't buy anything
plastic. Fortunately for her, beer is served in a glass.

I suggest that the ONLY moral way to discuss C is to regard it in the
same light as a garbage gyre. We must know the garbage gyre, and like
Prospero in The Tempest, we must say "This Thing of Darkness I
acknowledge Mine". But we must not love it, and we must not be proud
of our knowledge or seek to shame others for their mistakes about the
Garbage Gyre that is C.

For C is a garbage gyre indeed.

 

[Nick]

Mr. Harter is quite correct in saying that I don't care one way or the
other about the C stuff.

Plonk.

Two down.