Richard said:
.... snip ..
_A_ result value is not. Using random negative values for errors
and positive values for non-errors is fragile. It presumes that
correct results will never overflow into negative values, for
example. _If_ you know that this will never happen, that's fine,
but this function is meant as an enhancement to the Standard, not
as part of a single program with predictable input, so it needs
to be more solid than most.
For the record: I have nothing against your solution _for a user
function_. For a (meant to become Standard) library function,
though, I strongly suggest using the Standard mechanism for
reporting errors.
Take a look at the error reporting in ggets. It is controlled by
an enum for positive values, and EOF for negative values. No
possibility of overflow (which in itself would be undefined
behaviour) exist. Success is always reported by zero, leaving the
full integer range for various errors. This interfaces easily with
any routine to read as much as is available:
while (!ggets(&lineptr)) processline(lineptr);
and if you want to differentiate between failures you just save the
return value. This is also why ggets doesn't return the line
length. The complications of using ERRNO would be indescribable.
KISS applies. Save the complications for the rare cases.
<
http://cbfalconer.home.att/download/>
BTW Jacobs routine has the fault of returning -1 for EOF, which may
or may not agree with the system. This forces detailed reading of
the routine specification, and/or publishing an enom of values for
the various errors, which may in turn lead to name conflicts.
