Re: A note on computing thugs and coding bums

spinoza1111 said:

On Jan 12, 3:48 pm, Richard Heathfield <r...@xxxxxxxxxxxxxxx> wrote:
[In deference to Phlip, all Nilges's polemic, rhetoric, abuse, etc has
[been
snipped after only the briefest scanning to identify its nature, without
actually reading it; this reply focuses purely on the technical part of
Nilges's reply, which is of course broken and needs addressing. CAVEAT:
I have not bothered to indicate where polemic, rhetoric, abuse and other
such idiocies have been snipped. Refer to the parent article if you care
enough.]

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

I have only replied to the parts of the post that I read. I didn't bother
to reply to the parts of the post that I have not read. If you had
bothered to read what I had written (above), you would have realised this.
Since you did not realise it, either you had not read what I had written
(in which case, by your own argument, you had no right to reply to it), or
you did not understand it, in which case the proper course was to ask for
an explanation of the part you did not understand.

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. If you want to read them again, by all means refer
to the parent article to this reply.

spinoza1111 said:

On Jan 12, 2:50 pm, Richard Heathfield <r...@xxxxxxxxxxxxxxx> wrote:
But I think you [i.e. Ben Bacarisse] need a rider on your claim. I'm
sure you meant that the
code is valid for any character set that is legal in C (which is a
very unrestrictive language, but which does impose /some/
restrictions on character sets - specifically, that the values of
characters in the required source character set (other than null)
must be positive, that null must be 0, and that '0' to '9' are
contiguous).

Non restricted ASCII characters beyond 127 aren't positive if bytes
are signed.

There aren't any ASCII characters beyond 127. It's a 7 bit code. We
covered that, remember? But to answer your substantive point, yes, if
bytes are signed AND are only eight bits wide, then this does mean that
all the required source character set characters must have values in the
range 0-127 (with the 0 obviously being assigned to the null character).

This not only is a [...] slap in the face to international users,
it's a [...] slap in the face to American users and an arrogant
piece of [...].

(Expletives deleted.) C does not require that implementations use ASCII. It
allows them to use ASCII. If an implementor wants to use some other
character set (EBCDIC, Unicode, some other standardised set, or even a
custom character set), the C Standard endorses that decision subject only
to the very minor restrictions that: (a) the null character is the
character whose bits are all set to 0; (b) the required character set
characters must have positive values; (c) the digit characters '0' to '9'
have values that are contiguous and which ascend in the obvious way, with
'0' first and '9' last within the digit group. This is not a slap in
anyone's face, but a broad and liberal approach to character sets.

It would NOT be if you would only DESIST from claiming
that C handles strings.

IT DOES NOT.

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 forgot to add that Nul (not "null", please, that names something
different)

In C, the Standard defines the null character as the character with
value 0. More formally: "A byte with all bits set to 0, called the null
character, shall exist in the basic execution character set" - C89:
2.2.1

The C standard is poorly worded. No wonder you like it.

The ISO C Committee does not claim to be perfect, and so there is a process
for raising faults. You are free to raise a fault (a "Defect Report", or
DR) if you wish. If the Committee considers that your report has merit,
they may well decide to change the wording, and no doubt they will take
into consideration any proposed wording change that you might care to
suggest.

Since the context is C, I am using C terminology. If you wish to use the
word "null" for something else instead, that's up to you, but I have
made my usage precisely clear by citing the source of my definition. I
have no qualms about using the appropriate term ("the null character",
sometimes abbreviating it to "null" just as we abbreviate "the space
character" to "space", etc), whether you like it or not.

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.

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

must occur somewhere oh what the hey after the character
set or some stupid thing will happen.

No, it must have the value 0, and must be a part of the character set.
Because some code point values must follow it (i.e. have positive
values), it cannot be at the end, so in no sense does it come "after the
character set".

Your failure of comprehension caused you to miss the typo. Substitute
string for set and stop wasting my time.

Character sets were the subject of discussion. If you randomly introduce a
discussion of character strings into a discussion about character sets and
then describe the character strings as character sets, it is you who waste
my time, rather than vice versa.

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.


You skipped most of the post,

That's because most of the post was rhetoric, polemic, abuse, or other such
idiocy. I made it clear at the outset that I would not address such things
in my reply.

and you are such a poor reader that you
did not mentally correct me when I [...] typed set when I meant string.

So when you make mistakes, it's suddenly my fault? I don't think so.

How DARE you even reply?

We all have the right of reply. Your pathetic threat of physical violence
has failed to intimidate me. I dare to continue to correct your errors
because you dare to continue to make errors. If you don't want me to post
corrections to your articles, don't post errors in those articles.

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

  • Transponder Protocol Open Standard rec.pets-2005a
    ... But anybody can write an open standard, ... transponders readable by the standard is not intended to be identical ... as 20 character readings under this standard unless the reader designer ... If an excerpt string shows four or fewer transitions ...
    (rec.pets)
  • Re: Defacto standard string library
    ... Is there a defacto standard string library ... Unicode, encoded in UTF8 format, except that a zero byte is ... Standard C string functions will be fine with this ... result, it cannot be encoded using a single byte per character, unless ...
    (comp.lang.c)
  • Re: Empty Search Order vs Search Empty Wordlist
    ... Some suggest there should be a standard way to hack into the interpreter ... It's a string of characters that represent a character literal. ...
    (comp.lang.forth)
  • Re: Null terminated strings: bad or good?
    ... the standard that such an implementation would violate. ... The strlen function computes the length of the string pointed to ... the terminating null character. ... A counterargument could be made that if the length of the string can't ...
    (comp.lang.c)
  • Re: A note on computing thugs and coding bums
    ... code is valid for any character set that is legal in C (which is a ... characters in the required source character set ... A String, in C Sharp or Java, can be redefined. ... allow programmers to handle some other data format, ...
    (comp.programming)