Malcolm's new book

[Malcolm McLean]

The webpages for my new book are now up and running.

The book, Basic Algorithms, describes many of the fundamental algorithms
used in practical programming, with a bias towards graphics. It includes
mathematical routines from the basics up, including floating point
arithmetic, compression techniques, including the GIF and JPEG file formats,
hashing, red black trees, 3D and 3D graphics, colour spaces, machine
learning with neural networks, hidden Markov models, and fuzzy logic,
clustering, fast memory allocators, and expression parsing.

(Follow the links)

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[CBFalconer]

Malcolm McLean wrote:

"Ben Bacarisse" <be********@bsb.me.ukwrote in message

>"Malcolm McLean" <re*******@btinternet.comwrites:

>>In practise fgets() is too hard for the average programmer to use
correctly, as has time after time been demonstrated here. I caused
outrage by suggesting that most programs would be safer if they
replaced fgets() with gets(). However I was right.

Let me guess. You were alone in this belief on that occasion as well?

Yes. About two years later Steve Summit edited to FAQ to point out that
fgets() is problematic if lines overflow the buffer length, which was the
point I was making all along. Never said I was right.

It handles that. The complications arise when trying to interface
to its handling.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Heathfield]

Malcolm McLean said:

>
"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

>"Malcolm McLean" <re*******@btinternet.comwrites:

>>In practise fgets() is too hard for the average programmer to use
correctly, as has time after time been demonstrated here. I caused
outrage by suggesting that most programs would be safer if they
replaced fgets() with gets(). However I was right.

Let me guess. You were alone in this belief on that occasion as
well?

Yes.

Malcolm: to do a Galileo, it isn't enough to be alone in your opinions.
You have to be right, too.

About two years later Steve Summit edited to FAQ to point out
that fgets() is problematic if lines overflow the buffer length, which
was the point I was making all along.

fgets protects its buffer against overflow.

The only FAQ comment I can find that's even remotely relevant is "(If
long lines are a real possibility, their proper handling must be
carefully considered.)" - which is certainly true but says nothing
about overflowing buffer length.

Never said I was right.

Hold that thought.

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

[Ben Bacarisse]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

>"Malcolm McLean" <re*******@btinternet.comwrites:

>>In practise fgets() is too hard for the average programmer to use
correctly, as has time after time been demonstrated here. I caused
outrage by suggesting that most programs would be safer if they
replaced fgets() with gets(). However I was right.

Let me guess. You were alone in this belief on that occasion as well?

Yes. About two years later Steve Summit edited to FAQ to point out
that fgets() is problematic if lines overflow the buffer length, which
was the point I was making all along. Never said I was right.

You are curiously casual about language for someone who works with
computers. All C functions that put data into buffers are problematic
if the data "overflows" the buffer length, but I don't think you meant
what you wrote. It would be either an almost meaningless remark about
the operation of the function, or a gross under statement of the
problem depending on how precise you are using the term "overflow".

I won't argue the point if you wish to call it "problematic" that
fgets puts no more data into the buffer than there is room for (to me,
it just what fgets does) but I would welcome some examples of programs
that would be safer if they used gets() rather than fgets(). There
must be lots since you claim it is true of "most programs [that use
fgets()]".

--
Ben.

[Charlton Wilbur]

>>>>"B" == Ben Bacarisse <be********@bsb.me.ukwrites:

(to Malcom McLean)

BYou are curiously casual about language

.... full stop.

One would think that after however many threads where Malcolm says
something absurd, gets corrected, and argues about it, claiming "I was
only being informal, something you non-linguists would not
understand," or "I was only trying to write so that the completely
ignorant would not be confused" -- while sometimes restating what he
originally said in ways that subtly move it closer to the correction,
and claiming that that's what he meant all along, sometimes
selectively editing the words of his interlocutors to suggest that
they agree with him -- he would learn to be more precise in his
language.

Or, possibly, that he would learn *something* from the corrections.

Alas, one is frequently disappointed. I suspect it's the manager's
disease: where being *perceived* as being right is far more important
than *being* right, and so Malcolm spends a lot more energy trying to
argue that he was right in the first place than he would just
admitting his error and learning from it.

Charlton
--
Charlton Wilbur
cw*****@chromatico.net

[Kenny McCormack]

In article <km************@homelinux.net>, Richard <rg****@gmail.comwrote:
....

>No. fgets is not problematic. fgets behaves in a defined non problematic
way.

Um, er, that's like saying that starving to death is not problematic.
Afterall, it behaves in a defined (etc) way.

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

>"Malcolm McLean" <re*******@btinternet.comwrites:

>>In practise fgets() is too hard for the average programmer to use
correctly, as has time after time been demonstrated here. I caused
outrage by suggesting that most programs would be safer if they
replaced fgets() with gets(). However I was right.

Let me guess. You were alone in this belief on that occasion as well?

Yes. About two years later Steve Summit edited to FAQ to point out
that fgets() is problematic if lines overflow the buffer length, which
was the point I was making all along. Never said I was right.

Of course he never said you were right. You weren't.

Your claims are:

(1) "fgets() is too hard for the average programmer to use
correctly"

(2) "most programs would be safer if they replaced fgets() with
gets()"

Steve Summit's statement in the FAQ, assuming it's as you portray it,
does not in any way support your first claim, and it most certainly
doesn't support your second, which is directly contradicted by
question 12.23.

A Google search indicates that the word "problematic" does not appear
anywhere under the c-faq.com domain. Can you provide a reference to
Steve Summit's statement about fgets that you were referring to?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Malcolm McLean]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:je******************************@bt.com...

The only FAQ comment I can find that's even remotely relevant is "(If
long lines are a real possibility, their proper handling must be
carefully considered.)" - which is certainly true but says nothing
about overflowing buffer length.

The previous version showed "how to replace gets(0 with a call to fgets()",
then threw away the newline, making it impossible for caller to tell whether
or not a full line of input had been read. That wasn't an improvement.
However it got rid of the undefined behaviour.
Pointing out that it wasn't an improvement created massive protests. It got
rid of the undefined behaviour, so it must be better, mustn't it?

>

>Never said I was right.

Hold that thought.

Some people aren't very mannered. But at least the FAQ is now right.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Keith Thompson]

"Malcolm McLean" <re*******@btinternet.comwrites:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:je******************************@bt.com...

>The only FAQ comment I can find that's even remotely relevant is "(If
long lines are a real possibility, their proper handling must be
carefully considered.)" - which is certainly true but says nothing
about overflowing buffer length.

The previous version showed "how to replace gets(0 with a call to
fgets()", then threw away the newline, making it impossible for caller
to tell whether or not a full line of input had been read. That wasn't
an improvement. However it got rid of the undefined behaviour.
Pointing out that it wasn't an improvement created massive
protests. It got rid of the undefined behaviour, so it must be better,
mustn't it?

Yes. Getting rid of undefined behavior is an improvement. A program
that incorrectly interprets a long line as two shorter lines is an
improvement over a program reads that same long line and incurs a
buffer overflow, causing it to behave in some arbitrarily bad way.
(If you're very very lucky, the resulting undefined behavior might
cause it to interpret the long line as two shorter lines.)

There was still room for more improvement, of course, but that's not
what you claimed.

>>Never said I was right.

Hold that thought.

Some people aren't very mannered. But at least the FAQ is now right.

Yes, it is. Are you seriously claiming credit for that?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Kelsey Bjarnason]

[snips]

On Thu, 30 Aug 2007 00:09:55 +0100, Flash Gordon wrote:

You only mentioned part of the problem, namely that you cannot
distinguish between the two conditions. You do not mention the problem
of loosing the input that has been received.

He did, elsewhere. His take? It is better for *him* to decide to throw
away the data than to pass potentially incomplete data on to you and let
you decide what to do with it.

Just what we need: a library writer who thinks he is god.

[CBFalconer]

Kelsey Bjarnason wrote:

>

.... snip ...

>
I've not really looked at ggets, so I can't really comment.

<http://cbfalconer.home.att.net/download/ggets.zip 10 kbyte

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Kelsey Bjarnason]

On Sun, 02 Sep 2007 21:47:29 -0400, CBFalconer wrote:

Kelsey Bjarnason wrote:

>>

... snip ...

>>
I've not really looked at ggets, so I can't really comment.

<http://cbfalconer.home.att.net/download/ggets.zip 10 kbyte

Yeah, but I've got my own input routines, so I never really cared - which
isn't a comment on you or it.

[Kelsey Bjarnason]

On Thu, 09 Aug 2007 23:53:46 +0100, Mark McIntyre wrote:

On Wed, 8 Aug 2007 17:15:28 -0700, in comp.lang.c , Kelsey Bjarnason
<kb********@gmail.comwrote:

>>[snips]

On Tue, 07 Aug 2007 23:26:14 +0100, Mark McIntyre wrote:

>>>>Guess what? We use compilers, a language and other tools that _do_
conform to the standards of the day.

You do ? Where did you find a portable fully C99 compliant toolset?

As far as C usage is concerned, the standard of the day is C89.

My point exactly.

>>>
Newsflash: C89 is still C.

Newsflash: nobody but you seems to be confused about that.

Okay, I'm baffled. You seem to be arguing against yourself now. Did you
do a reality check recently?

Yes. Perhaps if you learned to read, this wouldn't be a problem.

>>The point to note here is that the Standard itself follows the style
being objected to.

Yes, and the standard also includes gets. What's your point?

Lost on you apparently.

Hey, you're the one arguing mindless adherence. Do tell us when you plan
to start relying on gets for input.

Meanwhile, the rest of us - the ones who prefer intelligent adherence -
will happily not use something *despite* the standard including it, if it
is, in our opinion, a bad idea.

Funny thing, I had vague recollections of you being moderately sane. My
bad. In the bin with the other drooling morons.

[Richard]

Kelsey Bjarnason <kb********@gmail.comwrites:

On Thu, 09 Aug 2007 23:53:46 +0100, Mark McIntyre wrote:

>On Wed, 8 Aug 2007 17:15:28 -0700, in comp.lang.c , Kelsey Bjarnason
<kb********@gmail.comwrote:

>>>[snips]

On Tue, 07 Aug 2007 23:26:14 +0100, Mark McIntyre wrote:

>Guess what? We use compilers, a language and other tools that _do_
>conform to the standards of the day.

You do ? Where did you find a portable fully C99 compliant toolset?

As far as C usage is concerned, the standard of the day is C89.

My point exactly.

>>>>
Newsflash: C89 is still C.

Newsflash: nobody but you seems to be confused about that.

Okay, I'm baffled. You seem to be arguing against yourself now. Did you
do a reality check recently?

Yes. Perhaps if you learned to read, this wouldn't be a problem.

I have noticed a tendency in your rather poor argument skills to resort
to calling people stupid rather a lot. Why is that? It indicates that
you are either incapable or unwilling to present a coherent argument.

[Kelsey Bjarnason]

[snips]

On Sun, 28 Oct 2007 01:19:22 +0200, Richard wrote:

I have noticed a tendency in your rather poor argument skills

The inability of one's opponent to read and comprehend simple English is
not a reflection of one's own argument skills, except, perhaps, insofar as
one either lacks the ability to, or chooses not to, kowtow to the
opponent's limitations by posting in crayon.