Re: A note on computing thugs and coding bums

spinoza1111 said:

<snip>

If you don't read all the posts, you have no right of reply.

That is an interesting opinion, but I do not share it. I see no reason why
I should not ignore all your drivel and focus on what little technical
content remains.

In the rest of this reply, I focus purely on the technical aspects, as
before. All your polemic, rhetoric, abuse, and other such idiocies have
been snipped, unmarked. (Consequently, this reply is less than half the
length of the parent article, despite containing the text of my reply.) If
you want to read them again, by all means refer to the parent article to
this reply.

C handles strings according to its own definition thereof. If you choose
to use another definition of the word "string", that's entirely your
choice, but C's definition of "string" is the definition I use when
discussing strings in a C context. If you want to discuss your belief
that C fails to allow programmers to handle some other data format, I
suggest that you define the data format in question in a way that makes
it clear what you are talking about.

You have no conception of what a string is,

Within the context of the C programming language, I know exactly what a
string is. I have already cited the definition for you. I trust I need not
do so again.

What is a string? It is a sequence of characters or ideograms for
serving human needs.

Well, we can call it that, provided that we recognise that we are putting
aside the C definition for the purposes of this discussion.

The problem with your definition is that it gives no indication about how
to determine where a string *stops*. Somehow, we must carry that
information around, or at least define a mechanism for determining it. One
way to do this is to pass a separate length parameter to functions that
have to deal with strings. Another is to encapsulate the character
information and the length information within a
structure/record/class/whatever.

The C language supports the former mechanism for dealing with arbitrary
sequences of characters - strings, by your definition - with its mem*
functions. It doesn't offer direct support for the latter, but it is
pretty trivial to write one's own support routines for it, and many
programmers have done this.

I suspect that the reason ISO didn't codify such support in the standard
library was either that they couldn't, or didn't care to try to, get
agreement on the best way to do it - "one size doesn't quite fit anybody".

In usable standards, it is Nul to disambiguate it from a null integer
returned to indicate failure, which may or may not be zero.

The C89 Standard is considered usable by a great many implementors
(since they *have* used it to produce conforming implementations) and a
great many programmers (because they *have* used it to produce very
portable programs). That you do not consider it usable is perhaps
relevant to you, but your opinion regarding its usability is not the
only one.

C isn't portable.

Perhaps there is a case for claiming that, but I think it's true to say
that it is currently less non-portable than any other programming
language.

It wasn't designed to be portable.

Then its high degree of portability is a triumph of good software
engineering.

In C, an integer return value of 0 typically indicates success. For
example, if we check the <stdio.h> header, we find that the following
functions use 0 to indicate success: remove, rename, fclose, fflush,
setvbuf, fgetpos, fseek, fsetpos. Functions that do not return 0 for
success are either void functions, or functions that return a count of
some kind (e.g. the number of characters printed by printf), or
functions that return a character value (e.g. putc, getc, ungetc), or
functions that return a pointer value. (I think that list is exhaustive,
but I won't swear to it.)

This is barbarism. The only value that should be returned for success
is bool true. Period. The only value that should be returned for
failure is bool false. Full stop.

It has been said that all happy people are happy in much the same way,
whereas miserable people each dwell in their own particular misery.
Success is - well - success, but failures can happen for a multitude of
reasons. To have many error codes available is useful. Sometimes an error
is non-critical, so one useful convention is to reserve 0 for an optimal
result, negative values for sub-optimal but acceptable results, and
positive values for actual errors (or, of course, vice versa). One might
not like this convention, but then one is not forced to use it. If one
doesn't like the convention used by C, well, wrappers are trivial to
write.

The problem is that real STRINGS cannot contain NUL. I am well aware
that the C character SET contains NUL.

The only mention of NUL in the C Standard is in a non-normative footnote
referring to a specific character set, which is certainly not "the" C
character set.

I really hope you know the difference between a character set and a
character string.

You will be glad to hear that I do know the difference. It is not evident
from your earlier replies that /you/ do.

It is unprofessional to just
assume that the character string will be terminated by a Nul.

In C, if a sequence of characters is not terminated by a null character,
it is not a string.

This is absurd!

You might consider it so, but that is how the C language defines strings.
If you don't like the definition, feel free to try to persuade ISO to
change it.

C does not define reality

It doesn't claim to. Nevertheless, the ISO C Standard defines the C
programming language. If you don't like the definition, you have some
choices, some of which are: (a) lobby ISO to get it changed; (b) put up
with it; (c) ignore the problem and use some other language instead. It
seems that you have chosen option (c), which is fine, but when discussing
the C language, it makes no sense to ignore the formal definition of that
language.

How DARE you even reply?

We all have the right of reply. Your pathetic threat of physical
violence

You're lying. No such threat was made.

In the message with Message-ID
<e654dafc-9e3a-4120-9654-fd218fe1663f@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
you wrote "I'd make mincemeat of you person to person. Care to arrange a
meeting?"

Let others decide for themselves whether I am lying in claiming that this
was a threat of physical violence.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
.

Relevant Pages

  • Re: Theodore Adorno, a prophet of data systems design
    ... C may not be a forgiving language, ... >> attention get burned with the memory leaks, and buffer overruns, ... by a small, compact team of brilliant programmers, or it may be ... so you agree that it is not a limit on the length of the string, ...
    (comp.programming)
  • Re: Theodore Adorno, a prophet of data systems design
    ... C may not be a forgiving language, ... >> attention get burned with the memory leaks, and buffer overruns, ... by a small, compact team of brilliant programmers, or it may be ... so you agree that it is not a limit on the length of the string, ...
    (comp.programming)
  • Re: Which is better - a char type or a string of length one?
    ... character long) we could, perhaps, get the first element of each as ... different from a fixed length string? ... That makes your language untyped (or ... means an array of elements, an ordered set. ...
    (comp.lang.misc)
  • Re: A good compiler
    ... One can try to make a language "safe", ... Because the abstraction level is so low, that even careful programmers ... Standard Library string functions like strcpyare not considered secure by today's standards. ... Graphic and web-based applications make extensive use of text input fields and, because of standards like XML, data exchanged between programs is increasingly in string form as well. ...
    (comp.lang.c)
  • Re: casts
    ... Infantile programmers have in fact destroyed ... it's a failure of the language. ... Also regex correctness has nothing to do with "mathematical formalism" ... If the primitives starting in str are used, then "a C string cannot ...
    (comp.lang.c)