At Sun, 29 Nov 2009 01:16:16 +0000, Roy Marples <roy%marples.name@localhost>
wrote:
Subject: Re: Weirdness in comm(1)
>
> On Sunday 29 November 2009 01:01:55 Greg A. Woods wrote:
> > I think whomever munged fgetstr(3) to be based on getdelim(3) in
> > -current may have broken it BADLY (likely, actually; re-introducing
> > bogus line length limits, sigh) -- they also forgot to update the manual
> > page (for both a new error and for its references).
>
> I'll update the manual page to reflect the new error tomorrow evening.
> There is a good reason why the line length is now limited - the sudio buffer
> length it uses is an int. Which is a little small for a size_t that fgetln(3)
> wants to use.
That's not a good reason _at_ _all_.
The previous implementation correctly handled lines as long as it could
realloc() a buffer to fit them; _and_ its documentation also allows for
a standard error for the case where the allocation fails.
I'm not even sure it's sane for a string or stdio function to abuse
EOVERFLOW either, never mind standards compatible, not that fgetln(3)
claims to adhere to any external public standard.
I.e. the API for the previous implementation did not care what buffer
size FILE used internally.
That original implementation has been around for quite a long while now.
I'm sure I'm not the only one with code that relies on the fact that
fgetln(3) will parse lines longer than the internal FILE buffer size --
I learned to use it for this reason from other code I'd read and advice
I'd been given.
I really think its previous behaviour _must_ be reinstated before the
broken code ends up in a NetBSD release. It's important enough for me
that I'd be willing to find some time to try to work on re-factoring
code together, if indeed that actually does make sense in this case.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpCjUJnY3WHK.pgp
Description: PGP signature