Re: Segfault City


Richard Heathfield wrote:
spinoza1111@xxxxxxxxx said:


Andrew Poelstra wrote:

I stopped reading after the first function. I wasn't sure why he kept

Which disqualifies you from a technical discussion.

No, it doesn't, because he can always go back and read it if he wishes. And
he is certainly qualified to discuss the part he has read.

Why are you posting?

Why are you?

Because you're engaged in a campaign of personal destruction as you
were with Schildt.


casting chars to ints, as though there wasn't implicit casting going on
by default. Then he tested for > '9', which made no sense to me.
Realizing that I wouldn't be able to trace that logic, I stopped.

It was a straightforward test for numerics.

No, it wasn't even remotely straightforward. It was unnecessarily verbose.

This would be a straightforward test for numerics:

int to_digit(int ch)
{
return isdigit((unsigned char)ch) ? ch - '0' : -1;
}

If you think that's too obfuscated, here's another, which I don't like very
much as it trades structural elegance for simplicity, but it /is/ simple:

int to_digit(int ch)
{
if(isdigit((unsigned char)ch))
{
return ch - '0';
}
return -1;
}


Again, are you qualified to be in this discussion?

As much as you are, and probably more.

Expressed fairly enough.



You stopped trying to understand things twice, so your opinion is
worth...what?

Plenty. What he's saying is that your code is unnecessarily obscure and
difficult to read. That's the mark of a bad programmer, unless your intent
is to win the IOCCC.

No, the mark of a bad programmer is inability to think outside the
particular set of chosen inputs and your insistence that C is still
usable for new development.

What, if anything, can it be guaranteed will be > '9' in standard C?

This isn't grammatical therefore I do not fully understand it. If you
are saying there is no character greater than 9, well I wish you all
the best in your future career. You'll need it.

C offers no guarantee that there is any character with a code point higher
than '9'. In EBCDIC, the code point of '9' is 249, so there are just six
characters (none with well-defined interpretations) with higher code
points. So Andrew's point is perfectly valid. It was also sufficiently
grammatical than I could understand it.

OK, this is complete nonsense. Are you pulling my leg?

You read in the standard that "C offers no guarantee with a code
point..."

But it MEANS that there CAN be. Can you read?

And to use EBCDIC, a completely obsolete encoding, obsoleted by ASCII
and then international 16 bit encoding...the mind boggles!

In ASCII, for which nearly all C code is written, the letters follow
the numbers! If the user enters A your "correct code" breaks?

[The "standard" may require the C runtime to treat the digits as
following the characters. The fact is that real compilers don't, and
use the encoded value. What this illustrates is the UNUSABILITY of the
standard, and consequently that it is extremely unwise, to the level of
professional malpractice, to recommend C for new development, as you
appear to.]

Are you for real? And you are sitting on your fat ass telling me I
don't know how to program?

But then you say that there are "just 6 characters" as if the small
number of characters makes it probable that your code won't break!

"My program is standard C, therefore the user has no right to send
characters with t a value higher than 9" is the zenith of arrogance.

And you use this as a reason for presenting code which BREAKS if there
IS a code point after all (c - 0 with no test for greater than 9)????

This is worse than I thought.

You seem to be using C on an IBM mainframe with the SAS compiler, and
pompously talking about C based on a misreading of the standard!

And if your compiler runs on an ASCII system, it has to jiggle
characters at runtime to make sure 9 is the "last" character. And C is
an "efficient" language?

Without being even aware that given aliasing, C can't be standardized
in a modern sense?

And icing on the cake..."it was also sufficiently grammatical THAN I
could understand it".

Do respond. I need a laugh and it seems you are ... well, not awake,
but posting. Are you drunk? Are you stoned?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

.

Relevant Pages

  • Javac-compilor error
    ... discipline id.e.programming Java. ... from standard input and writes to standard output, but it is possible to redirect the input ... error occurs while trying to open the file, an exception of type IllegalArgumentException ... then this number of characters, then extra spaces are added to the front of x to bring ...
    (Fedora)
  • Re: Case-sensitivity as option?
    ... Wide characters: Mapped to half-width characters ... I guess taking case insensitivity out of standard would be the right ... simplification (eg. you can use general purpose hash-algorithms ...
    (comp.lang.forth)
  • Re: keyword capitalization -- current practice
    ... outside the scope of the standard. ... more) different characters to be functionally the same. ... I once used a computer that used the ASCII character set, ... But the fortran compiler on that machine only recognized the subset ...
    (comp.lang.fortran)
  • Re: Invariant with DIGIT-CHAR-P and the reader.
    ... should appear to the Lisp reader as a number. ... >>> reading of the standard makes me believe the Lisp reader should ... >> Why a new CL could not accept more forms for unicode digits? ... > a..z, characters chosen by the implementation, and not from some higher ...
    (comp.lang.lisp)
  • Re: array processing in Lisp
    ... use of symbols instead of english for functions ... or dyadically because this depends on its position in a verb train and whether ... * Allow all combinations of printable ASCII characters as symbols, ... ;; in standard J (see ...
    (comp.lang.lisp)