Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Bug/Gross InEfficiency in HeathField's fgetline program

Reply
Thread Tools

Bug/Gross InEfficiency in HeathField's fgetline program

 
 
Flash Gordon
Guest
Posts: n/a
 
      11-13-2007
Richard Heathfield wrote, On 12/11/07 21:29:
> Flash Gordon said:
>
>> Tor Rustad wrote, On 07/11/07 01:00:

>
> <snip>
>
>>>> I don't think that Richard believes he is always correct.
>>> Neither did I.

>> OK, we are all agree Richard makes mistakes.

>
> Strictly speaking, we all agree that I don't believe he doesn't make
> mistakes.


OK, can we all agree that I make mistakes?

> That does not mean we all agree that I *do* make mistakes. Maybe
> we do, and maybe we don't, but we haven't said so yet.


Well, I believe that Richard makes mistakes, but I'm not going to state
which Richard I am referring to yet.
--
Flash Gordon
 
Reply With Quote
 
 
 
 
Peter Nilsson
Guest
Posts: n/a
 
      11-13-2007
Keith Thompson <(E-Mail Removed)> wrote:
> > > > For: the name starts with str and it is described
> > > > in 7.21 String Handling
> > > >
> > > > Against: the fact that it does not take or produce
> > > > a string
> > >
> > > s/does/need/. It _can_ be used to work exclusively with
> > > real C strings - it just takes more work and attention
> > > than should be necessary.
> > >
> > > IMO it _is_ a string function, but a severely broken one.

> >
> > Hence my advice: just don't use it.

>
> I disagree.
>
> A string function deals with a certain data structure, called
> a "string" by the C standard, consisting of "a contiguous
> sequence of characters terminated by and including the first
> null character" (C99 7.1.1p1).
>
> strncpy() deals with a different data structure,


But still caters for strings.

> one that has no name that I'm aware of, consisting of an
> array of N characters of which the first M are significant,
> and the remaining N-M characters are all set to '\0',
> where M may be equal to N. Such a data structure happens
> to contain a "string" *unless* M==N.


In the old days, this is what I called a record field, though
in some cases a space was used for padding rather than 0.
Fixed width fields, and checksums too apparently, are a thing
of the past.

<snip>
> The facts that this relatively obscure data structure is
> supported in the standard, that there's only one standard
> function that supports it,


Huh? fread, fwrite, scanf, printf, memcpy, memcmp... to name
a few. And that's obviously excluding other constructs like
zero initialisation.

> and that that function has a name that misleadingly implies
> that it's a string function, are all historical accidents.


Merely historical in my opinion. I don't believe they were
an accident at the time. In those days, people were using
fixed width fields, and they were squeezing as much out of
limited memory as possible.

The function _can_ be used to copy prefixes of strings to
a string. And it _will_ terminate the destination with a
sufficiently large enough buffer. If you're going to say
that it's not a string function because you can't guarantee
the source or destination will be strings, then you may as
well say that strcpy is not a string function!

> I don't recall anyone claiming that the standard C library
> is a model of coherent design.


Although apparently single byte character constants being
int and not single byte characters is perfectly coherent!

--
Peter

 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      11-13-2007
Peter Nilsson wrote:
> Keith Thompson <(E-Mail Removed)> wrote:

....
>> one that has no name that I'm aware of, consisting of an
>> array of N characters of which the first M are significant,
>> and the remaining N-M characters are all set to '\0',
>> where M may be equal to N. Such a data structure happens
>> to contain a "string" *unless* M==N.

....
>> The facts that this relatively obscure data structure is
>> supported in the standard, that there's only one standard
>> function that supports it,

>
> Huh? fread, fwrite, scanf, printf, memcpy, memcmp... to name


Neither fread() nor scanf() stops reading at a null character, nor does
either one fill the rest of a character array with null characters after
having read one. Neither fwrite() nor memcpy() stop writing at a null
character, nor does either one write extra null characters from that
point onward. memcmp() doesn't pay any special attention to null
characters. printf() can be forced to stop writing a string at a fixed
number of bytes, but the corresponding argument is still required to be
a null-terminated string, which is not guaranteed for this data
structure. Only strncpy() does these things, which makes it a very
anomalous function.

....
> The function _can_ be used to copy prefixes of strings to
> a string. And it _will_ terminate the destination with a
> sufficiently large enough buffer. If you're going to say
> that it's not a string function because you can't guarantee
> the source or destination will be strings, then you may as
> well say that strcpy is not a string function!


strcpy() requires that its input be a string, and guarantees, when all
of it's requirements have been met, that it's output is also a string.

>> I don't recall anyone claiming that the standard C library
>> is a model of coherent design.

>
> Although apparently single byte character constants being
> int and not single byte characters is perfectly coherent!


Well, the standard C languange isn't exactly a model of coherent design
either; it has too much history to cope with to allow that.
 
Reply With Quote
 
William Hughes
Guest
Posts: n/a
 
      11-13-2007
On Nov 12, 10:00 pm, Peter Nilsson <(E-Mail Removed)> wrote:

> The function _can_ be used to copy prefixes of strings to
> a string. And it _will_ terminate the destination with a
> sufficiently large enough buffer. If you're going to say
> that it's not a string function because you can't guarantee
> the source or destination will be strings, then you may as
> well say that strcpy is not a string function!
>



Hardly. If you use strcpy correctly, then you *can* guarantee that
that the source and destination will be strings. (If you do not
use it correctly you can guarantee exactly nothing, don't stop the
presses) If you use strncpy correctly then you cannot guarantee that
the source and destination will be strings.

- William Hughes

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      11-13-2007
Flash Gordon said:

> Richard Heathfield wrote, On 12/11/07 21:29:
>>
>> Strictly speaking, we all agree that I don't believe he doesn't make
>> mistakes.

>
> OK, can we all agree that I make mistakes?


No, I think you're mistaken about that.

--
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
 
Reply With Quote
 
Tor Rustad
Guest
Posts: n/a
 
      11-13-2007
Richard Heathfield wrote:
> Flash Gordon said:
>
>> Tor Rustad wrote, On 07/11/07 01:00:

>
> <snip>
>
>>>> I don't think that Richard believes he is always correct.
>>> Neither did I.

>> OK, we are all agree Richard makes mistakes.

>
> Strictly speaking, we all agree that I don't believe he doesn't make
> mistakes. That does not mean we all agree that I *do* make mistakes. Maybe
> we do, and maybe we don't, but we haven't said so yet.


Not quite, when we agreed thinking that Richard didn't beleave he is
always correct, it did follow that we believed Richard will be wrong at
some point in space-time. When this event has occurred, Richard must
have been wrong. Either Richard was right being wrong, or Richard was
wrong believing being wrong.

OTOH, what we all believe now, might have changed, so that require a
whole new discussion. That conclude my views on the matter...

--
Tor <(E-Mail Removed) | tr i-za-h a-z>
 
Reply With Quote
 
user923005
Guest
Posts: n/a
 
      11-13-2007
On Nov 13, 10:22 am, Tor Rustad <(E-Mail Removed)> wrote:
> Richard Heathfield wrote:
> > Flash Gordon said:

>
> >> Tor Rustad wrote, On 07/11/07 01:00:

>
> > <snip>

>
> >>>> I don't think that Richard believes he is always correct.
> >>> Neither did I.
> >> OK, we are all agree Richard makes mistakes.

>
> > Strictly speaking, we all agree that I don't believe he doesn't make
> > mistakes. That does not mean we all agree that I *do* make mistakes. Maybe
> > we do, and maybe we don't, but we haven't said so yet.

>
> Not quite, when we agreed thinking that Richard didn't beleave he is
> always correct, it did follow that we believed Richard will be wrong at
> some point in space-time. When this event has occurred, Richard must
> have been wrong. Either Richard was right being wrong, or Richard was
> wrong believing being wrong.
>
> OTOH, what we all believe now, might have changed, so that require a
> whole new discussion. That conclude my views on the matter...


I remember clearly when Richard was wrong. It was when he thought
that he was mistaken. He also cut himself once, shaving with Occam's
razor. Seriously, Richard Heathfield is one of the frequent posters
to news:comp.lang.c who knows a lot about the C language. I have
learned things from Richard's posts on many occasions. He has a very
wry and dry sense of British humor that sometimes goes over everyone's
head, including mine.

I suspect that the topicality has had a wee bit of drift here.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Designing fgetline - a perspective Richard Harter C Programming 48 11-25-2007 11:40 PM
Re: Bug/Gross InEfficiency in HeathField's fgetline program Dik T. Winter C Programming 2 11-07-2007 01:38 PM
Program inefficiency? hall.jeff@gmail.com Python 17 10-01-2007 04:48 PM
RE: Program inefficiency? Michael.Coll-Barth@VerizonWireless.com Python 6 10-01-2007 06:22 AM
Segfaulting when trying to create custom 'fgetline' function Jeff Rodriguez C Programming 4 11-17-2003 08:31 AM



Advertisments