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

[Mikael Holmén via Phabricator via libcxx-commits]

uabelho 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);
----------------
tahonermann wrote:
> 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
Yes, seems like we're using ancient glibc versions on our servers.

That explains our problem then. Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150044