fmemopen question

fmemopen question

[Nick Stoughton]

[-- Attachment #1: Type: text/plain, Size: 390 bytes --]

If I open a file for writing and immediately close it:

  fclose(fopen("foo", "w"));

the file "foo" will be truncated to zero length if it exists.

However, I I do this with a memory buffer, e.g.
    char arr[] = { 'a','a','a','a','a','a','a','a','a','a', 0};
    fclose(fmemopen(arr, 10, "w"));
I would expect that arr[0] would have a null byte.

But it doesn't. Is this a bug?

-- 
Nick

Re: fmemopen question

[Adhemerval Zanella Netto]

On 12/10/23 11:57, Nick Stoughton via Libc-help wrote:
> If I open a file for writing and immediately close it:
> 
>   fclose(fopen("foo", "w"));
> 
> the file "foo" will be truncated to zero length if it exists.
> 
> However, I I do this with a memory buffer, e.g.
>     char arr[] = { 'a','a','a','a','a','a','a','a','a','a', 0};
>     fclose(fmemopen(arr, 10, "w"));
> I would expect that arr[0] would have a null byte.
> 
> But it doesn't. Is this a bug?
> 

I think this falls to the Austin defect 657 [1], where the original fmemopen
specification [2]:

  When a stream open for writing is flushed or closed, a null byte shall be 
  written at the current position or at the end of the buffer, depending on 
  the size of the contents.

Indeed does not fully define when to write off the null byte.  The proposed
changed now allow glibc behavior (which only updates the stream on write
operation):

  When a stream open for update (the mode argument includes '+') or for writing 
  only is successfully written and the write advances the current buffer end 
  position, a null byte shall be written at the new buffer end position if it 
  fits.

However, the defect submitter has asked for more clarification. So there still
no resolution.  It seems that at glibc and musl do not write a null byte at
the start of the stream, different than BSD implementation (Free, Open, and
NET) as well AIX72.

[1] https://austingroupbugs.net/view.php?id=657