Re: A note on personal corruption as a result of using C

spinoza1111 <spinoza1111@xxxxxxxxx> writes:
[...]
THE LIES OF C

I'm probably going to regret jumping into this, but...

"A string cannot contain Nuls" Yes it can. Data arrives as strings and
needs to be validated, but C makes it impossible. It becomes
impossible to write effective string validation routines by definition
if the input isn't even a string: garbage in, garbage out was never
truer.

The C standard provides its own definition of the term "string",
namely (C99 7.1.1p1):

A string is a contiguous sequence of characters terminated by and
including the first null character.

By this definition, a string cannot contain a null character other
than the one that terminates it. This is not a lie; it is a simple
truth that follows from the definition, a definition that has proven
to be useful for real-world programming for many years.

(Note that a string literal may contain embedded null characters; the
standard explicitly acknowledges this.)

Perhaps you'd like to have a way to represent a sequence of characters
that can include embedded null characters. C's standard "string"
doesn't give you this (for example, strlen() computes the length of a
string up to but not including the terminating null character), but
you can certainly create your own data structure that supports this.
For example, you could have a structure consisting of a length and an
array of characters.

One could certainly argue that C's choice of this particular
representation for strings was a bad idea. Or perhaps you object to C
choosing to apply a fairly generic term "string" to one specific
representation. (Or perhaps I should let you make your own arguments
rather than trying to find reasonable interpretations for what you
write.) But calling it a "lie" is absurd.

"A string is 8 bytes" No it isn't and this has not been the case since
under Deng Xiao Peng China entered the real world.

It took me a while to figure out what you meant by this. Of course a
string isn't 8 bytes, unless it just happens to have that length. I
think what you meant is that C claims that a string is composed of
8-bit characters.

The C standard does not require this; the size in bits of an object of
type char must be at least 8 bits, but can be larger (it's typically
16 or 32 bits for DSP implementations).

But yes, in practice, CHAR_BIT==8 on all real-world hosted
implementations that I'm aware of. C does provide a wchar_t type
capable (at least potentially) of representing larger character sets,
though support for it is somewhat sketchy. And UTF-8 provides a
representation for Unicode characters that's compatible with the use
of 8-bit bytes.

The fact that C requires the fundamental character type to have the
same size as the smallest addressible unit of memory is, in my
opinion, infelicitous. It's one of a number of blemishes from C's
history. (I don't recall anyone claiming that C has no such
blemishes.)

"Aliasing gives me power" No it doesn't. It means that you have been
too lazy to find an effective algorithm.

I don't know what you mean by that. Is it something to do with what's
sometimes called "type punning"? Perhaps an example would help.

"Don't make me think! Just make the behavior undefined in the
standard!" Up yours, pal.

The standard does not define the behavior of all possible constructs.
Perhaps you'd like to design a systems programming language that
doesn't have this problem. Perhaps you could make technical points
without resorting to abusive language.

"A regular expression is what my code can handle" No, it isn't: the
theory was developed before computers.

I don't understand whatever point you're making here. If you're
refuting a claim that someone has made, I don't recall seeing it.

The C language itself doesn't support regular expressions, though
several popular regular expression libraries are implemented in C.

I don't know whether the theory of regular expressions was developed
before computers; either way, I fail to see what this has to do with C.

"A struct is a class" No, it isn't.

No such claim has been made with regard to C, because C doesn't have
classes.

(In C++, structs and classes are very similar; the only difference is
that struct members are public by default, and class members are
private by default. In practice, programmers typically use "struct"
for relatively simple types, and "class" for types that depend on
C++-specific features not provided by C. The language does not
enforce this distinction.

"A for is just while with sugar": no it isn't. The for loop needs to
evaluate invariants before it starts, but if you send a boy (Ritchie)
to do a man's job, you get a useless for which might as well be a
while.

Surely you could have made whatever point you're making without
personal insults.

A C for loop is just a while with sugar, as you acknowledge in the
same paragraph ("migh as well be a while"). Perhaps what you mean is
that a C for loop isn't defined the way you want it to be.

"Here's the preprocessor. Don't use it.": a Biblical injunction:
here's the apple tree, guys. Don't eat the apple and don't drink the
Kool Ade: but you must and will, and I'm God.

Who exactly is claiming to be "God"?

The C preprocessor is a powerful tool, and it's extremely easy to
abose and/or misuse it. It's part of the language, and we can't
change that without breaking existing code. It's difficult or
impossible to avoid it entirely ("#include <stdio.h" invokes the
preprocessor). Nobody has argued against using it at all, but since
we're stuck with it, and since it can be dangerous, it's best to use
it minimally and carefully.

"Pointers are unsigned integers and as such compareable. No they
aren't. Yes. Just kidding, they aren't.": C "experts" often sound like
the villain in the movie Dodgeball, "White" Goodman.

No, pointers aren't unsigned integers. They can be compared *as
pointers*.

"Here's post and pre increment. Don't try to guess when they happen":
there weren't enough lies in 1999, so yippee let's standardise the
language and add more!

The C standard does not define the behavior of certain expressions
such as ``i=i++;''. It states this clearly and explicitly. You can
argue that this is poor language design, but how is this a "lie"?
Perhaps you're using the word "lie" in some non-traditional way.

"Hey, Einstein, your code has another bug": it is important, it is Job
One, to design a language that makes fools look wise, and wise men
look like fools, and it has something to do with the Beatles.

I'll consider responding to that if I ever figure out what

A personal note: in Seattle, in the 1980s, I successfully implemented
a safety critical system for hydrostatics working with a professional
engineer who gave me the choice between C and "True Basic", at the
time an attempt by the inventor of Basic to create a useful safe and
structured Basic. I chose True Basic, and my program grandfathered a
series of successful versions, one of which was used on the ship that
found the Titanic. It was rewritten in Visual Basic in the 1990s, of
course, and not by me, and I was proud to see it in its new guise.

Congratulations.

A bit later I was engaged to write a system for real estate appraisal
and chose C: but this project failed because (1) I found myself having
to write all of modern Excel from scratch and (2) because of the need
to remedy hundreds of C gotchas, I spent more time in my library than
on the problem.

I felt ashamed of myself when I billed the client. I'd encapsulated a
string with Nuls in a struct with a long length, and was spending too
much time on proto-OO code, because once you have the struct you need,
in debugging, a toString() method and an inspect() method. In the
latter, I actually traveled the string in a try-catch structure, if I
remember correctly, to see if there was a memory exception.

You obviously dislike C. You clearly do not understand it very well.
That's fine; not everybody has to be a C programmer, and there are
even plenty of C programmers who dislike the language, or at least
certain aspects of it.

Perhaps if you stop trying to use C, you'd be better off. Traversing
a string and checking for memory exceptions certainly isn't something
I'd expect a competent C programmer to try to do.

And perhaps if you stop lecturing people who know the language better
than you do, we'd all be better off.

[snip]

--
Keith Thompson (The_Other_Keith) <kst-u@xxxxxxx>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
.

Relevant Pages

  • RE: VBA question: How to extract cell values in different language
    ... language is entered, but it seems like all that data is lost when the VBA ... about having binary data and not unicode data confirms my suspicions. ... You are have 256 binary characters. ... First column has the string IDs ...
    (microsoft.public.excel.programming)
  • Re: Russian language support
    ... Actually in our previous test we didnt do language transition properly ... bytes, or if in Unicode, just a string of 2-byte values, each of which is ... it selects a font to use to display ... TTF fonts in Windows CE map Unicode characters into suitable glyphs. ...
    (microsoft.public.windowsce.platbuilder)
  • RE: VBA question: How to extract cell values in different language
    ... language is entered, but it seems like all that data is lost when the VBA ... You are have 256 binary characters. ... Unicode data on the same file with two diffferent language setting gives you ... First column has the string IDs ...
    (microsoft.public.excel.programming)
  • RE: VBA question: How to extract cell values in different language
    ... You are have 256 binary characters. ... Depending on the language settings the characters are displayed differrently, ... Unicode data on the same file with two diffferent language setting gives you ... First column has the string IDs ...
    (microsoft.public.excel.programming)
  • Re: C++ char array to C# string, weird characters
    ... You've declared your C structure as containing, not Unicode ... characters, but ASCII characters. ... Everything is working except for the char array member in the struct. ... public string FName; ...
    (microsoft.public.dotnet.framework.compactframework)