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

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


.

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 ... 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: code access security across the network
    ... with web services, such as all of the various HTTP auth protocols (basic, ... only interaction with the calling code is data sent over the wire, ... data used to identify the caller can be spoofed by a malicious caller. ... client user identity and re-validating all data on the server side. ...
    (microsoft.public.dotnet.security)