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

Discussion in 'C Programming' started by Keith Thompson, May 30, 2008.

  1. Richard Heathfield <> 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.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 30, 2008
    #1
    1. Advertising

  2. Keith Thompson

    santosh Guest

    Keith Thompson wrote:

    > Richard Heathfield <> 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.
     
    santosh, May 30, 2008
    #2
    1. Advertising

  3. Richard Heathfield <> writes:
    > Keith Thompson said:
    >
    >> Richard Heathfield <> 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) <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"
     
    Keith Thompson, May 30, 2008
    #3
  4. Keith Thompson

    Flash Gordon Guest

    Keith Thompson wrote, On 30/05/08 20:00:
    > Richard Heathfield <> writes:
    >> Keith Thompson said:
    >>
    >>> Richard Heathfield <> 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
     
    Flash Gordon, May 30, 2008
    #4
  5. 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.
     
    Antoninus Twink, May 31, 2008
    #5
  6. Keith Thompson

    santosh Guest

    CBFalconer wrote:

    > santosh wrote:
    >> Keith Thompson wrote:
    >>> Richard Heathfield <> 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.
     
    santosh, May 31, 2008
    #6
  7. 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
     
    Joachim Schmitz, May 31, 2008
    #7
  8. Keith Thompson

    santosh Guest

    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?
     
    santosh, May 31, 2008
    #8
  9. 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
     
    Joachim Schmitz, May 31, 2008
    #9
  10. 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
     
    Joachim Schmitz, May 31, 2008
    #10
  11. Keith Thompson

    santosh Guest

    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".
     
    santosh, May 31, 2008
    #11
  12. Keith Thompson

    santosh Guest

    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>
     
    santosh, May 31, 2008
    #12
  13. santosh 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,

    >
    > 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.

    The client, your funktion, _may_ need to report failure to someone else.
    The (Standard) Library indeed has to keep the reason some place.

    Bye, Jojo
     
    Joachim Schmitz, May 31, 2008
    #13
  14. 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
     
    Joachim Schmitz, May 31, 2008
    #14
  15. In article <>,
    Antoninus Twink <> 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.


    On the other hand, I've been to hundreds of restaurants and have on
    several occasions had to make a new choice because they'd run out of
    what I'd ordered, but I've never had the problem that their kitchen
    was on fire. It's not a possibility that I take into account when
    choosing restaurants. Similarly, for some purposes the possibility of
    an i/o error while reading is so insignificant that it can just be
    ignored - just as you typically take no precautions to guard against
    out-of-stack errors (which in my experience are much more common).

    Obviously a program which, say, deletes the original file after
    processing it should distinguish between an i/o error and EOF.
    But not all programs are like that, and typically an i/o error
    will produce a user-visible indication.

    Errors when writing, rather than reading, are much more common because
    they can be caused by a full disk.

    -- Richard
    --
    In the selection of the two characters immediately succeeding the numeral 9,
    consideration shall be given to their replacement by the graphics 10 and 11 to
    facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)
     
    Richard Tobin, May 31, 2008
    #15
  16. Keith Thompson

    Richard Guest

    santosh <> writes:

    > CBFalconer wrote:
    >
    >> santosh wrote:
    >>> Keith Thompson wrote:
    >>>> Richard Heathfield <> 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.


    You must remember that "Chuck" is a world authority on everything and
    has publicly stated that it would hard to find "better" than his
    libraries...
     
    Richard, May 31, 2008
    #16
  17. Keith Thompson

    santosh Guest

    CBFalconer wrote:

    > santosh wrote:
    >> Joachim Schmitz wrote:
    >>

    > ... snip ...
    >>
    >>> 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".

    >
    > Because complicating a simple routine to allow for 'everything' is
    > ridiculous,


    Actually the function only has to return one additional status code, but
    yes, point taken.

    > especially when no impediment has been placed in the
    > way of handling that 'everything' when needed. Also, this is a
    > binary world, so many things go on the 'ridiculous' side to me.
    > :)


    I noticed.
     
    santosh, May 31, 2008
    #17
  18. santosh <> writes:
    > Joachim Schmitz wrote:

    [...]
    >> 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?


    Speaking of flawed analogies ...

    I don't think the difference is all that big a deal. You're not going
    home, then going back to the restaurant to ask whether it's on fire.
    It's just a difference between (a) getting a result back from the
    input function that tells you whether and how it failed, or (b)
    getting a result back from the input function that tells you it
    failed, then calling another (presumably very cheap) function to tell
    you why.

    (On the other hand, separating the error determination this way does
    make it too easy to ignore error conditions. The most straightforward
    idioms for reading from a file just read until they can't, then stop.)

    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, May 31, 2008
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Bren
    Replies:
    8
    Views:
    2,069
    Stephen Howe
    Sep 4, 2003
  2. DrBob
    Replies:
    2
    Views:
    604
    Unforgiven
    Nov 26, 2003
  3. Jun Woong

    Re: Override malloc,calloc,realloc and free?

    Jun Woong, Jun 26, 2003, in forum: C Programming
    Replies:
    0
    Views:
    1,113
    Jun Woong
    Jun 26, 2003
  4. Jens Thoms Toerring

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

    Jens Thoms Toerring, May 28, 2008, in forum: C Programming
    Replies:
    0
    Views:
    375
    Jens Thoms Toerring
    May 28, 2008
  5. Flash Gordon

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

    Flash Gordon, May 31, 2008, in forum: C Programming
    Replies:
    4
    Views:
    279
    Joachim Schmitz
    Jun 1, 2008
Loading...

Share This Page