Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: malloc()/realloc() - have I got this right?

Reply
Thread Tools

Re: malloc()/realloc() - have I got this right?

 
 
Keith Thompson
Guest
Posts: n/a
 
      05-30-2008
Richard Heathfield <(E-Mail Removed)> writes:
> CBFalconer said:
>> Richard Heathfield wrote:
>>> CBFalconer said:
>>>

>> ... snip ...
>>>>
>>>> enum {OK = 0, NOMEM};
>>>
>>> Are those the only two failure conditions? What about end of file?
>>> Or a stream error? Why not make it possible to report those?

>>
>> You didn't read the whole routine. It also returns EOF, which is
>> not defined here. I did point out that this listing omitted the
>> documentation etc.

>
> Your point is well-taken, although it does seem that you fail to
> distinguish between genuine end-of-file and a stream error.


So does fgets(). That's what feof() and ferror() are for.

[snip]

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
santosh
Guest
Posts: n/a
 
      05-30-2008
Keith Thompson wrote:

> Richard Heathfield <(E-Mail Removed)> writes:
>> CBFalconer said:
>>> Richard Heathfield wrote:
>>>> CBFalconer said:
>>>>
>>> ... snip ...
>>>>>
>>>>> enum {OK = 0, NOMEM};
>>>>
>>>> Are those the only two failure conditions? What about end of file?
>>>> Or a stream error? Why not make it possible to report those?
>>>
>>> You didn't read the whole routine. It also returns EOF, which is
>>> not defined here. I did point out that this listing omitted the
>>> documentation etc.

>>
>> Your point is well-taken, although it does seem that you fail to
>> distinguish between genuine end-of-file and a stream error.

>
> So does fgets(). That's what feof() and ferror() are for.
>
> [snip]


Nothing can be done about fgets but a new function /could/ disambiguate
between these two conditions thus freeing the caller from some more
repetitive work.

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      05-30-2008
Richard Heathfield <(E-Mail Removed)> writes:
> Keith Thompson said:
>
>> Richard Heathfield <(E-Mail Removed)> writes:

>
> <snip>
>
>>> Your point is well-taken, although it does seem that you fail to
>>> distinguish between genuine end-of-file and a stream error.

>>
>> So does fgets().

>
> Yes, which is another of its faults.
>
>> That's what feof() and ferror() are for.

>
> A recoverable fault, therefore, but still a fault.


Point taken.

On the other hand, fgets()'s failure to distinguish between
end-of-file and an error isn't all *that* bad, and there's some virtue
in sticking to the model used by the standard library.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      05-30-2008
Keith Thompson wrote, On 30/05/08 20:00:
> Richard Heathfield <(E-Mail Removed)> writes:
>> Keith Thompson said:
>>
>>> Richard Heathfield <(E-Mail Removed)> writes:

>> <snip>
>>
>>>> Your point is well-taken, although it does seem that you fail to
>>>> distinguish between genuine end-of-file and a stream error.
>>> So does fgets().

>> Yes, which is another of its faults.
>>
>>> That's what feof() and ferror() are for.

>> A recoverable fault, therefore, but still a fault.

>
> Point taken.
>
> On the other hand, fgets()'s failure to distinguish between
> end-of-file and an error isn't all *that* bad, and there's some virtue
> in sticking to the model used by the standard library.


I don't think using two different negative values to distinguish between
error and end-of-file would be too much of a variation since some
functions which return an int like CBFs ggets (e.g. getc) use EOF for
failure (guaranteed to be negative) and non-negative values for success.
Of course, selecting the two negative values is a bit of a pain, but...

#if EOF==-1
#define FERROR (EOF-1)
#else
#define FERROR (EOF+1)
#endif
--
Flash Gordon
 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      05-30-2008
On 30 May 2008 at 21:53, CBFalconer wrote:
> Ridiculous. Most use of the function simply runs until a non-zero
> is returned, after which the operation ends. It may be because of
> EOF, or because of error. In either case, no further input is
> available.


If you're in a restaurant and can't get your meal either because they've
run out of salmon or because the kitchen's on fire, you might find it
useful to be able to distinguish between those two error conditions.

 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      05-31-2008
CBFalconer wrote:

> santosh wrote:
>> Keith Thompson wrote:
>>> Richard Heathfield <(E-Mail Removed)> writes:
>>>> CBFalconer said:
>>>>> Richard Heathfield wrote:
>>>>>> CBFalconer said:
>>>>>>
>>>>> ... snip ...
>>>>>>>
>>>>>>> enum {OK = 0, NOMEM};
>>>>>>
>>>>>> Are those the only two failure conditions? What about end of
>>>>>> file? Or a stream error? Why not make it possible to report
>>>>>> those?
>>>>>
>>>>> You didn't read the whole routine. It also returns EOF, which is
>>>>> not defined here. I did point out that this listing omitted the
>>>>> documentation etc.
>>>>
>>>> Your point is well-taken, although it does seem that you fail to
>>>> distinguish between genuine end-of-file and a stream error.
>>>
>>> So does fgets(). That's what feof() and ferror() are for.
>>>
>>> [snip]

>>
>> Nothing can be done about fgets but a new function /could/
>> disambiguate between these two conditions thus freeing the caller
>> from some more repetitive work.

>
> Ridiculous. Most use of the function


I was not talking about ggets in particular, but instead about a line
reading function in general.

> simply runs until a non-zero
> is returned, after which the operation ends. It may be because of
> EOF, or because of error. In either case, no further input is
> available. If there is a need to distinguish EOF from errors, it
> can be done at that point.


C provides standard functions to disambiguate between end-of-file and
error. The relevant functions need to be called right after fgetc has
returned EOF. I think it's mostly a matter of design whether this is
done at all, and if so, whether in the caller or callee.

I don't what's ridiculous about any of these alternatives.

> This is not a matter of correctness, but of design philosophy.


Yes. So characterising an alternative design as "ridiculous" might be a
bit premature.

 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      05-31-2008
Antoninus Twink wrote:
> On 30 May 2008 at 21:53, CBFalconer wrote:
>> Ridiculous. Most use of the function simply runs until a non-zero
>> is returned, after which the operation ends. It may be because of
>> EOF, or because of error. In either case, no further input is
>> available.

>
> If you're in a restaurant and can't get your meal either because
> they've run out of salmon or because the kitchen's on fire, you might
> find it useful to be able to distinguish between those two error
> conditions.

For some reason that is beound me you elected to ignore CBF's next sentence,
which addresses exaclty that:
>>If there is a need to distinguish EOF from errors, it
>>can be done at that point.

In you analogy: just ask the waiter for the reason or listen to the fire
alarm.

Bye, Jojo



 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      05-31-2008
Joachim Schmitz wrote:

> Antoninus Twink wrote:
>> On 30 May 2008 at 21:53, CBFalconer wrote:
>>> Ridiculous. Most use of the function simply runs until a non-zero
>>> is returned, after which the operation ends. It may be because of
>>> EOF, or because of error. In either case, no further input is
>>> available.

>>
>> If you're in a restaurant and can't get your meal either because
>> they've run out of salmon or because the kitchen's on fire, you might
>> find it useful to be able to distinguish between those two error
>> conditions.

> For some reason that is beound me you elected to ignore CBF's next
> sentence, which addresses exaclty that:
>>>If there is a need to distinguish EOF from errors, it
>>>can be done at that point.


The debate was whether the caller or the callee should disambiguate
between end-of-file and error. IMHO doing it in the caller saves a
small amount of otherwise extra work in the calling code, which is
after all, the main purpose of library code. It's unclear from the
above sentence by CBFalconer whether he means the caller or the callee
when he says "at that point". One might assume from the general tone of
his reply and the use of the word "ridiculous" that he prefers this to
be done by the calling code. Either way is fine but I personally prefer
to have the line reading function do this low-level chore.

> In you analogy: just ask the waiter for the reason or listen to the
> fire alarm.


The analogy is flawed. The client (line reading function) has to report
the reason to someone else, (perhaps someone at his home). So should
the client ask the waiter for the reason and go home and report that,
or go home and simply say "the salmon was unavailable" and leave it to
that person to go to the restaurant and ask the waiter for the reason
why Salmon was not available?

 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      05-31-2008
santosh wrote:
> Joachim Schmitz wrote:
>
>> Antoninus Twink wrote:
>>> On 30 May 2008 at 21:53, CBFalconer wrote:
>>>> Ridiculous. Most use of the function simply runs until a non-zero
>>>> is returned, after which the operation ends. It may be because of
>>>> EOF, or because of error. In either case, no further input is
>>>> available.
>>>
>>> If you're in a restaurant and can't get your meal either because
>>> they've run out of salmon or because the kitchen's on fire, you
>>> might find it useful to be able to distinguish between those two
>>> error conditions.

>> For some reason that is beound me you elected to ignore CBF's next
>> sentence, which addresses exaclty that:
>>>> If there is a need to distinguish EOF from errors, it
>>>> can be done at that point.

>
> The debate was whether the caller or the callee should disambiguate
> between end-of-file and error. IMHO doing it in the caller saves a
> small amount of otherwise extra work in the calling code, which is
> after all, the main purpose of library code. It's unclear from the
> above sentence by CBFalconer whether he means the caller or the callee
> when he says "at that point". One might assume from the general tone
> of his reply and the use of the word "ridiculous" that he prefers
> this to be done by the calling code. Either way is fine but I
> personally prefer to have the line reading function do this low-level
> chore.
>
>> In you analogy: just ask the waiter for the reason or listen to the
>> fire alarm.

>
> The analogy is flawed. The client (line reading function) has to

s/has/may have/

> report the reason to someone else, (perhaps someone at his home). So
> should the client ask the waiter for the reason and go home and
> report that, or go home and simply say "the salmon was unavailable"
> and leave it to that person to go to the restaurant and ask the
> waiter for the reason why Salmon was not available?

Either is fine and at the discretion of the client (customer).
If someone else (at home) needs to know and the client didn't bother to ask,
that someone else better uses a different client next time.

Bye, Jojo


 
Reply With Quote
 
Joachim Schmitz
Guest
Posts: n/a
 
      05-31-2008
Joachim Schmitz wrote:
> santosh wrote:
>> Joachim Schmitz wrote:
>>
>>> Antoninus Twink wrote:
>>>> On 30 May 2008 at 21:53, CBFalconer wrote:
>>>>> Ridiculous. Most use of the function simply runs until a non-zero
>>>>> is returned, after which the operation ends. It may be because of
>>>>> EOF, or because of error. In either case, no further input is
>>>>> available.
>>>>
>>>> If you're in a restaurant and can't get your meal either because
>>>> they've run out of salmon or because the kitchen's on fire, you
>>>> might find it useful to be able to distinguish between those two
>>>> error conditions.
>>> For some reason that is beound me you elected to ignore CBF's next
>>> sentence, which addresses exaclty that:
>>>>> If there is a need to distinguish EOF from errors, it
>>>>> can be done at that point.

>>
>> The debate was whether the caller or the callee should disambiguate
>> between end-of-file and error. IMHO doing it in the caller saves a
>> small amount of otherwise extra work in the calling code, which is
>> after all, the main purpose of library code. It's unclear from the
>> above sentence by CBFalconer whether he means the caller or the
>> callee when he says "at that point". One might assume from the
>> general tone of his reply and the use of the word "ridiculous" that
>> he prefers this to be done by the calling code. Either way is fine
>> but I personally prefer to have the line reading function do this
>> low-level chore.
>>
>>> In you analogy: just ask the waiter for the reason or listen to the
>>> fire alarm.

>>
>> The analogy is flawed. The client (line reading function) has to

> s/has/may have/
>
>> report the reason to someone else, (perhaps someone at his home). So
>> should the client ask the waiter for the reason and go home and
>> report that, or go home and simply say "the salmon was unavailable"
>> and leave it to that person to go to the restaurant and ask the
>> waiter for the reason why Salmon was not available?

> Either is fine and at the discretion of the client (customer).
> If someone else (at home) needs to know and the client didn't bother
> to ask, that someone else better uses a different client next time.

To extend the anaoly: If I go to a restaurant to eat and nothing is
available, I may not care why, the fact that I'm still hungry will just lead
me to the next restaurant.
Or I might care to ask why no salmon ia available and it the reason is a
burning kitchen, I'd leave hungry too (and quicly), otherwise I might pick a
diferent choice from the menu. Provided it's not the salmon that I'm
longinhg for.

So there are good reasons for both designs, both with pros and cons, but
none invalid or superior to the other.

Bye, Jojo


 
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
If you Got Questions? I bet We got Answers Leisure.201@gmail.com Javascript 1 04-28-2007 11:04 PM
I have got this assignment in my school ... Can u people help me in this regard please. Sallu Cisco 0 01-03-2006 04:49 PM
have you got any of these i can have spike240 Case Modding 4 09-14-2005 03:48 AM
Have a got an MTU problem? Advice needed thejayman Cisco 1 07-30-2005 05:35 PM
Warehouse Dell dimension 3000 advert. This is a question so TNO doesn't have to download this message and read it to waste his time reading messages that I could have possibly got the answer .. (damn, run out of space in the subject line!) cowboyz NZ Computing 68 12-21-2004 02:19 PM



Advertisments