473,372 Members | 821 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,372 software developers and data experts.

Malcolm's new book

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

Jul 24 '07
263 9008
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

Aug 30 '07 #251
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
Aug 30 '07 #252
"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.
Aug 30 '07 #253
>>>>"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
Aug 30 '07 #254
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.

Aug 30 '07 #255
"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"
Aug 30 '07 #256

"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

Aug 31 '07 #257
"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"
Aug 31 '07 #258
[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.
Sep 2 '07 #259
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

Sep 3 '07 #260
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.
Sep 3 '07 #261
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.

Oct 27 '07 #262
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.
Oct 27 '07 #263
[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.
Oct 28 '07 #264

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

9
by: anonymous | last post by:
Hi CLCers, I want to know your opinion about the book: Expert C programming-Deep C secrets by Peter Van Der Linden. Thanks in advance. Sha
12
by: Guido Mureddu | last post by:
Hello, I'm a student in electronic engineering. I do know you've seen and answered this sort of topic/request countless times, but I haven't found past threads as helpful as I had hoped, and...
16
by: Robert Zurer | last post by:
Can anyone suggest the best book or part of a book on this subject. I'm looking for an in-depth treatment with examples in C# TIA Robert Zurer robert@zurer.com
8
by: Dgates | last post by:
Has anyone typed up an index for the O'Reilly book "C# and VB.NET Conversion?" I'm just learning C#, and often using this little book to see which VB.NET terms translate directly to some term in...
11
by: www.douglassdavis.com | last post by:
I'm looking for advice here, and I would really appreciate it if you could help. Is there a VB 2005 book that you like and would recommend (and why)? Would you consider it good for...
6
by: Hello | last post by:
Hello every body Please can any body tells me a good book that can teach me "visual basic 2005" (as beginner). Thank you all =========================================
1
by: jrw133 | last post by:
i got this program the other day and ive just started it and i am getting some errors that i cant figure out. requirements: 1)create a clas called Book. a Book has three data members: m_title,...
76
by: lorlarz | last post by:
Crockford's JavaScript, The Good Parts (a book review). This shall perhaps be the world's shortest book review (for one of the world's shortests books). I like Douglas Crockford (because I am a...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: taylorcarr | last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.