This looks like a typo in
https://eel.is/c++draft/print.fun#lib:vprint_nonunicode_buffered

I also couldn't find any active LWG issue in the [print.fun] subclause.

Discarding the user-provided stream obviously makes no sense. I think it
would be best if you sent an email to lwgchair_at_[hidden] with the proposed
change, which is just to forward the stream argument.

On Fri, 20 Mar 2026 at 23:54, Abhinav Agarwal via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> While reading N5032 [print.fun], I noticed what appears to be a
> wording defect in
> void vprint_nonunicode_buffered(FILE* stream, string_view fmt,
> format_args args);
>
> Its Effects are currently specified as:
> string out = vformat(fmt, args);
> vprint_nonunicode("{}", make_format_args(out));
>
> That call appears to select the two-argument overload
> vprint_nonunicode(string_view, format_args), whose Effects are
> specified as
> vprint_nonunicode(stdout, fmt, args);
>
> If so, the caller-supplied stream is discarded and
> vprint_nonunicode_buffered is specified to write to stdout.
>
> By contrast, the parallel vprint_unicode_buffered says:
> string out = vformat(fmt, args);
> vprint_unicode(stream, "{}", make_format_args(out));
>
> This seems user-visible because print(FILE* stream, ...) can dispatch
> to vprint_nonunicode_buffered(stream, ...) on the non-UTF-8 buffered
> path.
>
> For what it's worth, libstdc++ and MSVC STL also appear to implement
> the intended behavior by passing stream through, so this may be a
> wording defect rather than an implementation bug
> https://godbolt.org/z/Kjvvxejhx.
>
> Am I reading this correctly, and is this already a known LWG issue? I
> did not find a matching issue in the active or defect lists. If this
> is not already tracked, I can send a formal library issue writeup to
> lwgchair_at_gmail.com.
>
> Regards
> Abhinav Agarwal
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>