Segfault City

[spinoza1111]

(e-mail address removed) said:>
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;
}

I'm not a C "expert" by your lights, but I am an expert programmer, and
the above is one of the silliest things I've ever seen posted on the
net. You may be a "recognized C expert", but you can't program and
should not be permitted to write software or write about software. Here
is why:

(1) You call the code a "straightforward test for numerics" but it
isn't any such thing. It assumes that the library contains an isdigit()
function and doesn't "test" at all. Instead, using isdigit() it checks
for a digit (which makes your statement wrong and a lie because isdigit
does the work you claim "your" code does) and then converts the digit
to a number.

(2) Earlier this evening I mistook your code to fail if the character
value exceeded '9' because your code was so terribly wrong (in saying
it was something it was not) that I actually overlooked (1); you are
not making the test you say you are making. I was in a hurry because
I'm wasting my time replying to you.

To call the above code "straightforward" is obscene. You need to code
what you mean, and the minimal assumption you can make about digits is
that their value, when converted to an integer (whether byte, unsigned
or other) is inclusively between that of the integer value of '0' and
that of '9'.

The value of letters in EBCDIC did not conform to this, but this was a
mistake caused by the fact that Herman Hollerith, the designer of the
IBM punched card, needed "zone" bits. It was fixed in ASCII. In all
extant coding systems except perhaps obscure ones, digit values are
adjacent.

You may believe that a "standard" C programmer would always use isdigit
to ensure his code worked on non-ASCII, non-EBCDIC systems. The isdigit
function would then I suppose completely conceal the machine and code
dependent test and here, the code would be transportable between ASCII
and EBCDIC machines.

This would be a good thing. The problem is that actual working C
programmers can't be sure of having a fully conforming implementation
for legacy code, and don't waste time if they're smart making legacy
programs conform to your favorite standard. And, you intentionally
mislead them, as a self-appointed C expert, by saying that your code is
a "straighforward test for numerics" when it is not.

In your code, assuming that the C environment the programmer is using
(which doesn't have to be standard) has an isdigit, you don't break if
the digit value is greater than the value of 9. However, your code,
starting with your claim, is a lie, and you are posting (perhaps as a
paid agent) disinformation in a campaign of character assassination
similar to that you conducted against Herb Schildt. **** you.

You're a code monkey and on the job, if this is your style, your
interest is solely in spreading confusion, and, probably, office
politics and character assassination.

As much as you are, and probably more.


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.

Obscure? Difficult to read? Give me a break. You say above that "this
would be a straightforward TEST FOR NUMERICS" [emphasis mine] and then
you use isdigit() to do the heavy lifting.

 

[CBFalconer]

I'm assuming you remember Edward G Nilges from his brief
habitation under a bridge here in CLC?

Oh we remember it alright. That troll has been coming out from
under his bridge in comp.programming almost continuously, and has
produced its normal share of Nilgewater in spades. Some of us have
left it unplonked, and have been shamelessly baiting it.

 

[Malcolm]

Keith Thompson wrote:

It's still a good example of ugly C (they're called argc and argv,
not intArgCount and strArgValues), and it could probably be written
more

Nope, they are called what I called them. The abandonment of Hungarian
notation was a mistake.


I think Keith's comment on argc/argv is right, i.e., using argc/argv
follows the rule of keeping 'the least possible surprise value' to a
minimium. It's what's 'expected' - I feel that there's no good reason for
changing the parameter names, and doing so will only cause confusion
somewhere down the line.

On Hungarian Notation, a few years ago [oh, now that I come to think about
it, that's quite a few years ago] I would have agreed with you - I used HN
all of the time, and liked it once I got used to it [I *had* to adopt
their use where I worked].

However, IMHO, modern development environments makes their use redundant -
now, if you want to know the type-of-something, its storage-class, or
where it's declared/defined - you simply use some shortcut/gesture built
into the development environment and you'll get all the information you
need. And that's great - this kind of feature, when used with meaningful
names makes code more readable [more easily parsable, and kinder on the
eye]. In fact, in dropping them, it might also make one think just a
little harder about the 'usage' part of any name used?

The irony is that the more modern your computer, the more antiquated your
development environment. I've got a nice parallel cluster to play with, but
it uses Fortran 77 and a C compiler so old-fashioned that it won't even
accept // comments. I edit the source files in emacs. My one concession to a
modern environment is that I flat refuse to have anything to do with vi.

The reason is that when something is brand new, there isn't time to get nice
tools together. It happens with games consoles as well.

 

[Chris Smith]

I'm not a C "expert" by your lights, but I am an expert programmer, and
the above is one of the silliest things I've ever seen posted on the
net.

Perhaps expert programmers disagree on this matter, then. It seems
rather trivial to me -- the kind of thing one might do all the time.
It's certainly not silly. What is silly is to avoid using isdigit for
this purpose.

(1) You call the code a "straightforward test for numerics" but it
isn't any such thing. It assumes that the library contains an isdigit()
function and doesn't "test" at all.

If we first assume that we're working in C, then the availability of
isdigit is not an assumption; it logically follows from the existing
assumptions. If you won't assume that we're working in C, then I'm
afraid you're posting in the wrong newsgroup.

(which makes your statement wrong and a lie because isdigit
does the work you claim "your" code does)

I don't think Richard is claiming any sort of priority here. He's just
demonstrating how to write working code.

(2) Earlier this evening I mistook your code to fail if the character
value exceeded '9' because your code was so terribly wrong

The code is not wrong. If you mistook it for incorrect, then all I can
say is we all make mistakes. If you still refuse to acknowledge that
mistake, then perhaps some sould-searching is in order.

The value of letters in EBCDIC did not conform to this, but this was a
mistake caused by the fact that Herman Hollerith, the designer of the
IBM punched card, needed "zone" bits. It was fixed in ASCII. In all
extant coding systems except perhaps obscure ones, digit values are
adjacent.

Perhaps you read EBCDIC tables differently than I do. It appears to me
that this most certainly is true of EBCDIC. It had better be, or a
conforming C implementation would not use EBCDIC.

This would be a good thing. The problem is that actual working C
programmers can't be sure of having a fully conforming implementation
for legacy code

Please point out a C implementation that's in any significant amount of
use (i.e., not a toy implementation built by a student for a compilers
class, or something like that) that fails to implement isdigit.

starting with your claim, is a lie, and you are posting (perhaps as a
paid agent) disinformation in a campaign of character assassination
similar to that you conducted against Herb Schildt. **** you.

Okay, this is where qualified mental help is in order. When people are
wrong about important things, other people say so. This is a perfectly
natural thing to occur. While it can be done in more or less polite
ways, it is simply not rational to hope for it to stop happening. That
would be the death of progress as a civilization.

 

[Malcolm]

--

Andrew Poelstra said:

[X-posted, and followups set]

I found something interesting on the Web today, purely by chance.

Just out of curiousity, did you stumble upon that while Googling your own
name? I'm not accusing you of arrogance,

...just of self-indulgence. Yes, I was actually looking for a specific
Terry
Pratchett quote. I knew it was on a page of quotations that /also/ quoted
something by me, but that's all I could remember, so I googled for my name
+ quote and Google showed me:

You're a greater man than we thought, if you are quoted on the same page as
Terry Pratchett.
What was this priceless pearl?

 

[Malcolm]

Char constant expressions '9' or '0' are type of int. Even if
they aren't, they will be promoted as type of int in the operations.
I'm not very clear on that, could you please give more hints?

And how do you feel about the following code snippet?

int ctoi(char c)
{
int i = -1;
if (c >= '0' && c <= '9')
{
i = c - '0';
}
return i;
}

lovecreatesbeauty

/*
convert character to numerical value
Params: ch - digit in character encoding
Returns: numerical value of the digit. behaviour if passed non-digit is
undefined
*/
int chartonumber( char ch)
{
assert( isdigit(ch) );
return ch - '0';
}

Nice, easy to see. And if someone passes a non-digit to such a function, it
deserves to kick.
And no, it isn't qute conforming but it's conforming enough. Anyone care to
point out the technical difficulty?

 

[spinoza1111]

(e-mail address removed) said:

The important thing is that C students learn how to write C properly. The
characteristic you share with Schildt is that you are endeavouring to teach
C without actually knowing it, and /that/ is what is destructive.

The developer dot star post was not any attempt to "teach" C. You've
concealed the fact that in the post there is full disclosure that I was
temporarily returning to C to do "global" computing, might make errors,
had made errors, and trusted a collegial site to make any corrections
needed in the spirit of open source.

Whereas you've set yourself up as a *guru* and yet you have lied,
saying that a "straightforward test for numeric digits" is one when it
used isdigit to make the test!

That's another mark, it's true, but my point is still perfectly valid.

My code may have been "obscure" if you so misunderstood the problem but
you're hopeless if you can present a USE of a system function as the
solution. You're a thief of intellectual property and a liar.

Well, that's certainly an opinion, although I doubt whether it will be
shared by many here in comp.lang.c.

Who? Amateur programmers, retirees with anger management problems, and
script kiddies? I am soooo scared.

No, I'm perfectly serious, and no, it's not even incomplete nonsense, let
alone complete nonsense. What I have said is accurate.

....and completely misleading, Monkey Boy, which was your intent: to
confuse in a deliberate campaign of Swift Boating as you did with
Schildt.

I taught SAS C in 1989 when I was a daily user of C (today, I have, it
seems, forgotten more *real* C than you will ever know). EBCDIC C
programming is a rarity and in ASCII the programmer has to worry about
letters, which have what you call "code points" higher than '9'.

The ONLY sensible way to code the test remains

if (intCharValue >= [int]'0' && intCharValue <= [int]'9')

NOT in the sense that this won't "break" someone's C environment but in
the sense that the final C code in a particular C environment has to be
an && condition which shows the minimal assumption, that digits are
adjacent.

Your big lie is that there is one C when in fact nearly all C
programmers have to use a dictated and not fully standard compiler.
Your code tells them to use a library function, isdigit(), which I
suppose is part of your Standard but may not be available elsewhere.

I may have missed it. Perhaps it's a fundamental part of the toolkit of
every C programmer, and I am too dumb to see it. But here, your lie
remains, because you call a use of the function "a straightforward test
for numerics" when it isn't.

Furthermore it is my understanding that most C library functions can be
coded in C. A conforming definition would use your Standard's guarantee
that the numeric value of digits are adjacent, and would be in fact my
&& test of being in the interval.

Not those exact words, but yes, it's true that the Standard offers no such
guarantee.


Yes, I can read, and yes, there can be characters with a higher code point.


Some programmers don't get to choose their character set.


Not at all. But to rely on the letters following the numbers (which, I
hasten to add, your code does not) would be silly.

Your code doesn't "break" because it uses a magic function which isn't
available to all C programmers. It doesn't do the job it says it will
do. Furthermore, it makes the legacy assumption that all characters are
bytes.

[The "standard" may require the C runtime to treat the digits as
following the characters.

It doesn't. The guarantees given by the Standard w.r.t. code points are as
follows:

1) all characters in the basic source and execution character sets have
positive values;
2) '0' to '9' are in numerical order and contiguous.

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

No, it illustrates that you don't understand the Standard's guarantees about
code points (see above).

OK, I don't understand the Standard's guarantees. But you don't know
how to code clearly (and people who think your code is clear are
deceiving themselves), and you implemented a solution that doesn't do
the job you says it does.

Well, I don't own a donkey, fat or otherwise, but apart from that you're
broadly correct, yes.


No, I'm saying that to rely on character ordering that is not guaranteed by
the Standard renders code non-portable to systems where that reliance is
misplaced. I will again say, however, that your code does *not* fall foul
of this particular issue. We are discussing a minor point raised by Andrew
about a curious way of phrasing a character test, not an error in your
code.

As was the case in 2002, you've spread confusion again because your
purpose here is to character assassinate and trash, as in your campaign
against Schildt. You now admit that my code doesn't "fall foul".

Your claim was so outre that earlier this evening I understood you to
be claiming that you merely needed to test for greater than or equal to
zero to check for a number. I now realize that your praxis was even
worse.

But nobody is saying that.

As was the case in 2002, you've made deliberate misstatements in order
to Swift Boat and spread confusion.

Not at all.


Please cite and explain the relevant section of the Standard that you think
I am misreading.

**** the standard, and **** you. You have lied consistently, about
Schildt, in 2002, and here:

This would be a straightforward test for numerics: [IT IS NOT]

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

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

No, not at all. You seem to have misunderstood my point completely.

And you are lying.

No, C is a programming language. Whether C programs are efficient depends on
how they are written. It is easily possible to write inefficient programs
in C, just as it is easily possible to write inefficient programs in any
sufficiently powerful programming language. (The caveat is only there
because I suppose it is possible to conceive of a programming language so
limited that all its expressible programs are efficient, but that would
almost certainly be a very limited language indeed.)


Well, I'll let you take that up with ISO.

Like most Swift Boaters and most liars in business, you are fearful of
and resentful of authority and in search therefore of easy "marks" to
bully with your lies. C cannot be "standardized" because it is an
assembly language, and **** ISO if it makes this claim.

No, but I am in the mood to write a Sieve. See below.

I am in NO mood to read your code. You are a cheap liar, a code monkey,
and a thug.

 

[spinoza1111]

[X-posted, and followups set]

I found something interesting on the Web today, purely by chance.

It would be funny if it weren't so sad. Or sad if it weren't so funny. I'm
not sure which.

http://www.developerdotstar.com/community/node/291

Something I wondered about was why the code tests numbers up through
half the highest value (call it N), rather than up through sqrt(N),
which is clearly (?) sufficient. Most discussions I've read of this
algorithm stop at sqrt(N), though perhaps the original algorithm
didn't?

I saw this recommendation in 1974 (in Wirth) and it makes perfect
sense...if you have an efficient way to get square root.

Wirth's discussion, however, emphasized that you add "efficiencies"
sensibly depending on resources.

If the number to be tested for primehood is a power of two, getting
square root is easy, but, it will be already excluded because a power
of two is divisible by 2 and nonprime.

Dividing by 2 is implemented by a fast shift in modern compilers which
"loses" the remainder but for the test used, all you need is the value
of the floor.

So, for big primes, the numbers run up past square root to one half.

 

[spinoza1111]

[X-posted, and followups set]

I found something interesting on the Web today, purely by chance.

It would be funny if it weren't so sad. Or sad if it weren't so funny. I'm
not sure which.

http://www.developerdotstar.com/community/node/291

This "teacher of C" demonstrates his prowess with a masterful display of
incompetence in a 200-line program that travels as swiftly as possible to
Segfault City.

(Actually, using my normal gcc switches, it doesn't even get past TP3, but
it will at least compile if you just use gcc -o foo foo.c, after hacking it
around a bit to do things like mending the line-spanning single-line
comments and string literals, which - in fairness to the author - are
probably an artifact of the Webification of the code.)

I wonder how long I'll take to stop laughing.

It compiled cleanly with Digital Mars, Pelles C and lcc-win32.
Errors for missing or misplaced braces just after the first "if"
block in main()with Open Watcom. In the cases where it compiled,
it ran without a segfault.

But I made an error if I did strcat without memory available. I need to
investigate the site code. Right now my higher priority is responding
to a clear lie on REH's part.

So, thanks for your effort in making a fair check. But I may have made
an error.

In any event, the output is ponderous and confusing and there is
far too much superfluous code: the core code for the Sieve of
Eratothenes can be written in about a half dozen lines of C.

OK, so it's ponderous. This is an aesthetic judgement based on a
decadent C culture of programmers with cushy jobs taking far too long
to developed embedded systems in which brevity is an actual attempt to
conceal, as in the case of:

This would be a straightforward test for numerics:

int to_digit(int ch)
{
return isdigit((unsigned char)ch) ? ch - '0' : -1; // isdigit, not "this", does the test!!!
}

</heathfield>

The ponderosity is successful, not in establishing pseudodominance and
in character assassination, in TEACHING C, as was Schildt.

 

[spinoza1111]

[X-posted, and followups set]

I found something interesting on the Web today, purely by chance.

It would be funny if it weren't so sad. Or sad if it weren't so funny. I'm
not sure which.

http://www.developerdotstar.com/community/node/291

I somehow missed the author's name at the top of the -- entry?
article? post? -- but well before I got to the actual code
I had made a guess that proved to be correct. The man does have a
distinctive style (though probably it was a major clue that it's
you drawing people's attention to the entry).

The use of macros seems somewhat C-idiomatic, but not the names
chosen for the arguments to main. (Who else .... ) I'm not sure
what to make of string2number, but perhaps there's a good reason
I'm not thinking of to not use one of the library functions (e.g.,
atoi or strtol) that would seem to accomplish the same thing.

Because in fact few actually existing C environments conform to the
most current Standard I decided to roll my own. I was at the time
engaged in a global computing project for people who can't afford clean
water, let alone rush out and buy a conforming implementation.

 

[Dave Vandervies]

(e-mail address removed) said:

It's a fabulous illusion, then, given that so many of us earn our bread and
butter from writing programs in it.

Ooh, is it time for the "It's impossible to use portable C in the real
world" thread again?

Next week, my employer will be deploying (in the real world) a system
containing a module of approximately 2300 lines of code (as reported by
wc -l), for which I also wrote approximately 1000 lines of test drivers
and data analysis tools, and the amount of non-portable code (actually,
in this case, it's better described as "questionably portable", since
a single #ifdef-controlled macro is enough to get a clean build on two
implementations that are probably getting close to as different as two
hosted implementations targeting the same hardware family can get) in that
module is small enough that I can paste it here without annoying anyone:

--------
#ifndef _WIN32
#define _declspec(x) /*ignore MSVC declspec markers*/
#endif
--------
_declspec(dllexport) int imm_predict
--------
_declspec(dllexport) int imm_update
--------

So, that's about 0.2% of the code that escaped into the real world,
and about 0.15% of the total code that was written and kept around,
that's non-portable.

(Not all of our code is quite this good an example, but saying that 80-90%
of the distinct modules have 80-90% of their code portable would probably
be a recognizeable approximation to reality. Which is in about the same
range as the numbers I keep seeing people claim for the amount of code
that can't be made portable, except that I got my numbers by looking at
a real system, and I'm not sure where they're getting theirs.)


dave

 

[spinoza1111]

Well here's one message in which Nilges shows his "knowledge" in C:
http://groups.google.de/group/comp....="#define+MALLOCSTMT"&rnum=1#9860a66e44c4c65d

Agreed it's a terrible link but look google for
#define MALLOCSTMT and you'll find it.

Around that same time he has posted some other severly broken code and
blaimed C for it. Ah threads with Nilges tend to get a bit large over
time.

Richard's strategy is to post a lie that then spreads confusion, and
causes his butt buddies, and people frightened of him, to repeat
character assassinations. It is Swift Boating.

Here is Richard's lie:

This would be a straightforward test for numerics:

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

</heathfield>

As you can see, it's not a straightforward test for numerics. It uses a
system library function that may or may not be available depending on
the C environment dishonestly and converts to numerics.

I call this Swift Boating because it appears that Richard deliberately
lied, as did the President about Kerry's war record, in order to leave
others with an impression that since he's the Expert (as the President
is the "President") he would be honest, therefore any objection is
whining.

He then proceeded to massively confuse this issue by actually talking
about EBCDIC when perhaps less than 1% of C programs use IBM
mainframes.

 

[spinoza1111]

<giggle> It's Nilges? You probably don't know, Alf, but people have
been helpfully pointing out his errors for years. So far, it's had no
discernible effect.

That's a lie, Al.
Hmm, another retiree who can neither code nor manage his anger.

 

[Richard Heathfield]

(e-mail address removed) said:

I'm not a C "expert" by your lights,

Quite so.

but I am an expert programmer,

and
the above is one of the silliest things I've ever seen posted on the
net.

Your values seem to be upside down.

You may be a "recognized C expert", but you can't program and
should not be permitted to write software or write about software.

Fortunately for good programmers everywhere, your opinion about who should
be permitted to write software or write about software is not normative.

Here is why:

(1) You call the code a "straightforward test for numerics" but it
isn't any such thing.

It is.

It assumes that the library contains an isdigit()
function and doesn't "test" at all.

isdigit() is well-defined by the Standard. It is available on all hosted
implementations. If you are arguing that the implementation might be
freestanding (in which case isdigit() might not be available), then the
same argument applies to strlen, strcmp, printf, strcat, and time, all of
which your own code uses.

Instead, using isdigit() it checks
for a digit (which makes your statement wrong and a lie because isdigit
does the work you claim "your" code does)

My code checks for a digit by calling isdigit. That is not a lie. That is
code re-use.

and then converts the digit to a number.
Indeed.

(2) Earlier this evening I mistook your code to fail

<shrug> What's one more mistake among so many?

To call the above code "straightforward" is obscene.

I would guess you are just about unique in thinking so.

You need to code
what you mean, and the minimal assumption you can make about digits is
that their value, when converted to an integer (whether byte, unsigned
or other) is inclusively between that of the integer value of '0' and
that of '9'.

The value of letters in EBCDIC did not conform to this,

How can the value of letters be relevant to the value of digits?

but this was a
mistake caused by the fact that Herman Hollerith, the designer of the
IBM punched card, needed "zone" bits. It was fixed in ASCII. In all
extant coding systems except perhaps obscure ones, digit values are
adjacent.

They are adjacent in EBCDIC too.

You may believe that a "standard" C programmer would always use isdigit
to ensure his code worked on non-ASCII, non-EBCDIC systems.

No, I believe a good C programmer uses isdigit() to detect whether a value
is a digit because that's what isdigit() is /for/, and it does its job
well.

The isdigit
function would then I suppose completely conceal the machine and code
dependent test and here, the code would be transportable between ASCII
and EBCDIC machines.

In this case, it doesn't actually matter. The two principal benefits of
isdigit() are clarity and performance. (Performance hardly matters in this
case, since we're talking about a function that only gets called a handful
of times, but in general it is sometimes relevant.)

This would be a good thing. The problem is that actual working C
programmers can't be sure of having a fully conforming implementation
for legacy code,

This newsgroup is full of actual working C programmers. Does anyone know of
any hosted C implementation that doesn't have a working isdigit()? (I
don't.)

and don't waste time if they're smart making legacy
programs conform to your favorite standard. And, you intentionally
mislead them, as a self-appointed C expert,

When was /that/ appointment made? Cite, please.

by saying that your code is
a "straighforward test for numerics" when it is not.

Sure it is. Your turn.

In your code, assuming that the C environment the programmer is using
(which doesn't have to be standard)

If it isn't standard, it isn't a C environment.

has an isdigit, you don't break if
the digit value is greater than the value of 9.

Of course not. Neither does yours. So?

However, your code,
starting with your claim, is a lie, and you are posting (perhaps as a
paid agent) disinformation in a campaign of character assassination
similar to that you conducted against Herb Schildt.

The code is what it is. I'm not paid for doing Usenet. I am not posting
disinformation. I am not in the business of assassinating characters, but I
do reserve the right to criticise incompetent programming when I see it.

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.

Obscure? Difficult to read? Give me a break. You say above that "this
would be a straightforward TEST FOR NUMERICS" [emphasis mine] and then
you use isdigit() to do the heavy lifting.

Yep. That's one way to write clear, easy-to-read code - use the standard
library to do standard tasks, where appropriate.

 

[spinoza1111]

I missed the "< '0'" because he disguised '0' behind a temp variable.
Indeed, 'tis ugly but not incorrect.

Hmm, another art critic, masquerading as a competent programmer.

C programmers in America constitute a decadent programming culture and
they are attracted to job-preserving, in-crowd ugliness. Fortunately,
managers have evolved ways for so subcontracting their work and
alienating them from the tools of production that their negative
productivity doesn't matter.

The code was intended to be globally comprehensible because, thank G-d,
I don't live in America anymore and I don't have to put up on the job
with American programmers who love ugly code. English is a world
language, therefore I use longer and more English like names in order
to be certain of world understandability...not the approval of a bunch
of code monkeys.

 

[CBFalconer]

I'm not a C "expert" by your lights, but I am an expert programmer, and
the above is one of the silliest things I've ever seen posted on the
net. You may be a "recognized C expert", but you can't program and
should not be permitted to write software or write about software. Here
is why:

(1) You call the code a "straightforward test for numerics" but it
isn't any such thing. It assumes that the library contains an isdigit()
function and doesn't "test" at all. Instead, using isdigit() it checks
for a digit (which makes your statement wrong and a lie because isdigit
does the work you claim "your" code does) and then converts the digit
to a number.

Why should an 'experienced' programmer refuse to use a routine that
is guaranteed to be available in the C library? Even if he should
decide on such a foolish technique, he could write:

int to_digit(int ch) {
if (('0' <= ch) && ('9' >= ch)) return ch - '0';
return -1;
}

No flowery conversions an code monstrosities needed.

 

[spinoza1111]

(e-mail address removed) said:


If you want your program to work on EBCDIC systems, yes. But EBCDIC is
beside the point, which is that when portability is a highly desirable
objective, it's a bad idea to introduce unnecessary dependencies into your
code. (And I will say again that you did not in fact do this.)

How clever. Make the aspersion and then retract it. You sure you don't
work for Karl Rove?

There's no nonsense here to get away with, so what you claim is false, and
your "experience" is irrelevant to what the Standard says about character
sets.

Again, the Standard is not implemented by many C environments and
people come here for guidance on C praxis...not the Standard.

It's a fabulous illusion, then, given that so many of us earn our bread and
butter from writing programs in it.

I make money, so I'm ok
I works all night and I sleeps all day
I puts on women's clothing
And I hangs around in bars

[Chorus of Mounties]
He makes money, so he's ok
He works all night and he sleeps all day
He puts on womens' clothing
And he hangs around in bars

It's trivial to make it a non-issue. I have already shown how to do this.

Your code does not as I feared earlier this evening allow characters
greater than '9' to be numbers, but if you'd had an elementary
dedication to the truth and not making money by way of character
assassination you would not have posted this gem:

 

[CBFalconer]

Someone lets *Nilges* teach C? Where? Has his supervisor been
notified?

He is joining Schildt, in more ways than one.

 

[spinoza1111]

Someone lets *Nilges* teach C? Where? Has his supervisor been
notified?

I no longer have a programming supervisor because over the course of a
successful thirty year career in programming including assistance to
John Nash, book publishing, and operating system development (VM/CMS
modifications and bootstrap loaders) I began to realize in recent years
that American programming culture is decadent, as is the culture of
places, like Richard's UK, in thrall to American models.

I realized that more and more programming "supervisors" are in fact
dependent on self-appointed experts like Richard who deliberately tell
lies, spread confusion and bully others.

I therefore moved to Asia where I am an educator in English, history,
and yes computer science. I no longer have to deal with an American
programming culture that outside Microsoft is decadent and increasingly
migrating to Asia.

 

[Richard Heathfield]

(e-mail address removed) said:

The developer dot star post was not any attempt to "teach" C.

Quotes from the page:

"I had to develop an instructor solution to a simple C problem, the
calculation of primes using the Sieve of Eratosthenes."

"The first challenge in teaching the Sieve of Eratosthenes..."

"But as a teacher of C I plan to stress its flaws and its pitfalls from my
POV (point of view)."

You have certainly managed to stress some flaws and pitfalls, but they are
not C's flaws or pitfalls.

You've
concealed the fact that in the post there is full disclosure that I was
temporarily returning to C to do "global" computing,

No, I posted the URL to that page. Anyone who saw the code also had every
opportunity to read the accompanying blurb.

My code may have been "obscure" if you so misunderstood the problem but

Oh, I understood the problem all right. Indeed, I understood it better than
you did. (That's why my program is so much faster than yours.)

you're hopeless if you can present a USE of a system function as the
solution.

Those who ignore the standard library condemn themselves to rewriting it.

You're a thief of intellectual property and a liar.

Whose intellectual property have I stolen? How have I lied? You'll have to
do better than "using isdigit() constitutes lying".

Who? Amateur programmers, retirees with anger management problems, and
script kiddies?

To insult an entire newsgroup in one short paragraph is the work of a troll.
If you're interested in learning C, this newsgroup can be of tremendous
help to you. If you're not, I suggest you stop using it before your
software kills someone.

I am soooo scared.

No need to be. We're all very pleasant and well-mannered people most of the
time.

I taught SAS C in 1989 when I was a daily user of C (today, I have, it
seems, forgotten more *real* C than you will ever know). EBCDIC C
programming is a rarity and in ASCII the programmer has to worry about
letters, which have what you call "code points" higher than '9'.

The ONLY sensible way to code the test remains

if (intCharValue >= [int]'0' && intCharValue <= [int]'9')

Firstly, that won't even compile. Secondly, when you correct [int] to (int),
you are casting an int to an int, which is utterly pointless. Thirdly, a
call to isdigit() is far clearer as well as being quicker to type, and it
may even run a bit faster, too.

NOT in the sense that this won't "break" someone's C environment but in
the sense that the final C code in a particular C environment has to be
an && condition which shows the minimal assumption, that digits are
adjacent.

This is guaranteed by the Standard.

Your big lie is that there is one C when in fact nearly all C
programmers have to use a dictated and not fully standard compiler.
Your code tells them to use a library function, isdigit(), which I
suppose is part of your Standard but may not be available elsewhere.

It's available in all hosted C implementations. I've covered this
elsethread.

I may have missed it. Perhaps it's a fundamental part of the toolkit of
every C programmer, and I am too dumb to see it.
Right.

Furthermore it is my understanding that most C library functions can be
coded in C. A conforming definition would use your Standard's guarantee
that the numeric value of digits are adjacent, and would be in fact my
&& test of being in the interval.

Certainly possible, but by no means certain. Here is a legal implementation
of isdigit(), which might reasonably be used in a library targeted at an
ASCII platform:

/* somewhere in the library code */
const int __is_digit[UCHAR_MAX + 1] =
{
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
1, 1, 1, 1, 1, 1, 1, 1, 1, 1
};

/* in ctype.h */
extern const int __is_digit[UCHAR_MAX + 1];

#define isdigit(c) (((c) == EOF) ? EOF : __is_digit[c])

I may be mistaken but I believe Turbo C implemented it in approximately this
way.

Your code doesn't "break" because it uses a magic function which isn't
available to all C programmers.

It's available to all C programmers on hosted implementations. Your own
program also uses functions that are only guaranteed to be available on
hosted implementations; isdigit() is just as portable as printf() in that
respect.

It doesn't do the job it says it will do.

Yes, it does.

Furthermore, it makes the legacy assumption that all characters are
bytes.

They are, by definition, in all conforming implementations.

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

No, it illustrates that you don't understand the Standard's guarantees
about code points (see above).

OK, I don't understand the Standard's guarantees.
Right.

But you don't know how to code clearly (and people who think your
code is clear are deceiving themselves), and you implemented a
solution that doesn't do the job you says it does.

Yes I do, and no they aren't, and no I didn't.

As was the case in 2002, you've spread confusion again because your
purpose here is to character assassinate and trash, as in your campaign
against Schildt. You now admit that my code doesn't "fall foul".

Oh, but it does, in all kinds of ways. Just not in /that/ way.

Your claim was so outre that earlier this evening I understood you to
be claiming that you merely needed to test for greater than or equal to
zero to check for a number.

Then you need to read what I wrote, rather than what you fondly imagine I
wrote. I made no such claim.

Please cite and explain the relevant section of the Standard that you
think I am misreading.

[elided] the standard, and [elided] you.

May I take that as an admission that you are unable to cite the relevant
section of the Standard?

You have lied consistently, about Schildt, in 2002, and here:

Not at all.

And you are lying.

No, you have just completely and utterly misunderstood this subthread.

C cannot be "standardized" because it is an
assembly language, and [elided] ISO if it makes this claim.

I'll let you take that up with ISO.

I am in NO mood to read your code.

Ah, such a shame. It would have been an education for you.

You are a cheap liar, a code monkey, and a thug.

Four errors in an eleven word sentence. I'm impressed.