Re: getdelim doesn't set errno on failure?

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> Note that POSIX *does* require a failed malloc call to set errno to
>> ENOMEM, albeit with CX shading (meaning IEEE Std 1003.1-2001).
>>
>>   http://www.opengroup.org/susv3xsh/malloc.html
>>
>> Let's try not to let substandard systems dictate interface design.
>> If some system has a poor implementation of a function like malloc
>> we can easily ensure that it is replaced.
>
> I'm not in favour of a wrapper around malloc(), that would add overhead to
> a function called as frequently as malloc(), just to set 'errno'.
>
> What value do you expect in errno after malloc() failed? ENOMEM is
> the most frequent and maybe also the only reasonable choice when malloc()
> fails. What's the purpose then of setting errno then?

One of the goals of Gnulib is to hide portability vagaries like this.
If being able to assume that malloc sets errno to ENOMEM upon failure
can lead to a more useful implementation of getline, or to more reliable
diagnostics in general, then I think it is fine to make getline depend
on a slightly more-expensive, wrapped malloc -- on non-conforming systems.

This is sort of like whether to code for conforming malloc/realloc/free
when they are passed a size of 0 or a NULL pointer.  Code that assumes
the more useful (usually newer) standard -- relying on the wrapper when
necessary -- is slightly cleaner and more maintainable, but with some
small amount of overhead on systems that require the wrapper.

That said, I don't particularly care how getline is implemented,
as long as it can be used robustly and reasonably easily.

> ISO C 99 is not a "substandard",

As applied to a *system* that implements malloc that way, `substandard'
seems like an apt description.  Such a system falls short of a prescribed
norm: relatively-recent POSIX.

> and Windows malloc() is not "poor" just
> because it does not set errno.

Call it what you like, but lack of support for such a basic bit of
functionality is certainly not a plus.

My point is that Gnulib development should not be held hostage to a
system that is behind the standards curve.  If the workarounds (e.g.,
wrappers) required to keep the mainstream code clean end up being too
expensive on Windows, we can hope that someone will profile things there
and find a clean workaround.