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

santosh wrote:
Joachim Schmitz wrote:

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.

I agree. That is why I still don't understand why CBFalconer responded
to an earlier post as "ridiculous".
Indeed. Calling another ones opinion or needs ridiculous is just that...

Bye, Jojo


.

Relevant Pages

  • Re: malloc()/realloc() - have I got this right?
    ... For some reason that is beound me you elected to ignore CBF's next ... he prefers this to be done by the calling code. ... The client has to ... or go home and simply say "the salmon was unavailable" ...
    (comp.lang.c)
  • Re: malloc()/realloc() - have I got this right?
    ... For some reason that is beound me you elected to ignore CBF's next ... he prefers this to be done by the calling code. ... The client has to ... or go home and simply say "the salmon was unavailable" ...
    (comp.lang.c)
  • Re: malloc()/realloc() - have I got this right?
    ... For some reason that is beound me you elected to ignore CBF's next ... The debate was whether the caller or the callee should disambiguate ... small amount of otherwise extra work in the calling code, ... or go home and simply say "the salmon was unavailable" and leave it to ...
    (comp.lang.c)
  • Re: malloc()/realloc() - have I got this right?
    ... For some reason that is beound me you elected to ignore CBF's next ... The debate was whether the caller or the callee should disambiguate ... this to be done by the calling code. ... The client has to ...
    (comp.lang.c)
  • Re: Handling empty relation to child object
    ... but you won't have to check for Client = ... > In the calling code I do: ... > this will throw an error if, for whatever reason, the Client does not ... > How can I get it to return an empty string instead of having to do: ...
    (microsoft.public.dotnet.languages.vb)