Re: [PATCH 7/6][BZ #11216] Return fmemopen stream when len==0.

[Rasmus Villemoes <rv at rasmusvillemoes dot dk>]

OndÅej BÃlka <neleai@seznam.cz> writes:

> As previous patches changed fmemopen behavior a lot it may be rigth 
> time to fix that when len==0 fmemopen returns NULL. See:
> http://sourceware.org/bugzilla/show_bug.cgi?id=11216

Yes, please!

I consider it a serious bug in POSIX that it mandates the EINVAL error
for len==0
[http://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html].
I'm not sure about the history, but I think fmemopen() originated in
glibc and POSIX simply standardized what glibc did.

There is not really any reason that fmemopen() with len==0 should
behave differently than fopen() on a size 0 file, at least not when
opening for reading. The glibc manual suggests that fmemopen(s,
strlen(s), "r") can be expected to work: 'So, if you want to read
characters from a null-terminated string, you should supply the length
of the string as the SIZE argument.'

As an application developer, it is quite annoying to have to open-code
the result of what would happen if the string happened to be empty.

The behaviour when open for writing should, I think, be similar to
opening /dev/full: Result in ENOSPC on attempt to write. Both glibc
manual and POSIX use 'if it fits', so not being able to write a nul
byte doesn't matter. There may be a small problem with specifying sane
semantics in the append case, since there is no buffer to search for a
nul byte, but setting the file offset to 0 is not completely
unreasonable. The append/write case to a size 0 buffer is anyway much
less likely to appear in real programs.

-- 
Rasmus Villemoes
<http://rasmusvillemoes.dk/>