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

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,

Why? If a library function /could/ fail, then returning a status code is
IMHO more or less essential. Otherwise the function becomes close to
ususable.

<snip>

.

Relevant Pages

  • Re: malloc()/realloc() - have I got this right?
    ... The debate was whether the caller or the callee should disambiguate ... he prefers this to be done by the calling code. ... but I personally prefer to have the line reading function do this ...
    (comp.lang.c)
  • Re: code access security across the network
    ... There is no reliable way to identify calling code over a network. ... used to identify the caller can be spoofed by a malicious caller. ... your efforts would be better placed on ensuring that your web service ... this would involve not trusting self-declared client user ...
    (microsoft.public.dotnet.security)