[libcxx-commits] [PATCH] D150044: [libc++][print] Adds FILE functions.

[Tom Honermann via Phabricator via libcxx-commits]

tahonermann added inline comments.


================
Comment at: libcxx/test/libcxx/input.output/iostream.format/print.fun/vprint_unicode_posix.pass.cpp:40
+
+  FILE* file = fmemopen(buffer.data(), buffer.size(), "wb");
+  assert(file);
----------------
uabelho wrote:
> When I run this testcase the assert on line 48 below fails for me, and it seems to be because the "fmemopen" call here writes '\0' at the first byte in buffer.
> 
> I really doen't know anything about this and if I read at 
>  https://man7.org/linux/man-pages/man3/fmemopen.3.html
> it says
> ```
>        w      The stream is opened for writing.
> ```
> and also
> ```
>        w+     Open the stream for reading and writing.  The buffer
>               contents are truncated (i.e., '\0' is placed in the first
>               byte of the buffer).
> ```
> So it seems like when I run this in my environment "w" partly does what "w+" should do.
> 
> Does this problem sound familiar to anyone?
Are you by chance using an old glibc version from 2015 or earlier? Early implementations of `fmemopen()` unconditionally truncated the buffer when opened for write. This was changed in this commit:

  - https://github.com/bminor/glibc/commit/fdb7d390dd0d96e4a8239c46f3aa64598b90842b#diff-d190e07e0c146d56444d64c78bb49f4764974719ed454e0254644e1a7b793803L239

Alternatively, the "old" implementation replaced by the commit above is still present in current glibc releases under the name `__old_fmemopen`. Perhaps your builds are somehow calling that implementation?

  - https://github.com/bminor/glibc/blob/master/libio/oldfmemopen.c


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150044/new/

https://reviews.llvm.org/D150044