From: ell1e <kittens@wobble.ninja>
To: libc-help@sourceware.org
Subject: Re: Is there a way to use vsnprintf_l? Would it possibly be considered for an addition one day, if missing?
Date: Thu, 29 Oct 2020 17:02:15 +0100 [thread overview]
Message-ID: <e1ddd174-a096-db8d-60ee-cfb0750eee0a@wobble.ninja> (raw)
In-Reply-To: <97ee03c7-29a7-e0a4-2aa2-462efbc494f0@linaro.org>
Regarding wide implementations:
For what it's worth, I personally only use stdio string formatting
functions when about to head out to stdout/through a networking pipe/to
UI/... as a final export step where I assume utf-8 in C strings in my
programs usually. In other more internal places I usually use byte
buffers with length anyway that don't work with anything usual, for null
bytes compatibility, possibly use of utf-32, and more. (This is also why
I prefer locale independent behavior for my stdio string handling with
the help of *_l() functions, I don't work with alternate encodings
really if I can help it but just utf-8 everywhere.)
So I'm wondering, is wide string usage still common? I guess this
question is possibly quite off-topic, just curious since it seems
vaguely relevant to the potential demand regarding some of these missing
functions.
I assumed since the world realized UTF-16 is its way out and given one
code point isn't one character even in UTF-32 anyway, people tend to go
more back to just raw UTF-8 these days anyway. But I didn't actually run
a poll, just my personal impression. When I asked for vsnprintf_l it was
also in particular because that one I was kind of sorely lacking in
practical usage, so although I get the desire to be complete for the
sake of it I am coming to this topic from a quite practical viewpoint.
Regards,
ell1e
On 10/20/20 3:30 PM, Adhemerval Zanella wrote:
>
>
> On 20/10/2020 02:45, Florian Weimer wrote:
>> * Adhemerval Zanella via Libc-help:
>>
>>> If the idea is to provide a concise support for printf_l family function,
>>> I think we should add not only snprintf_l or vsnprintf_l, but rather all the
>>> stdio functions for both printf *and* scanf along with the wchar_t family
>>> as well. It means to add support for:
>>>
>>> int fprintf_l (FILE *, locale_t, const char *, ...)
>>> int fscanf_l (FILE * , locale_t, const char *, ...)
>>> int printf_l (locale_t, const char *, ...)
>>> int scanf_l (locale_t, const char *, ...)
>>> int sprintf_l (char *, locale_t, const char * , ...)
>>> int sscanf_l (const char *, locale_t, const char * , ...)
>>> int vfprintf_l (FILE *, locale_t, const char * , __va_list)
>>> int vprintf_l (locale_t, const char *, __va_list)
>>> int vsprintf_l (char * , locale_t, const char *, __va_list);
>>> int snprintf_l (char *, size_t, locale_t, const char * , ...)
>>> int vfscanf_l (FILE * , locale_t, const char * , __va_list)
>>> int vscanf_l (locale_t, const char *, __va_list)
>>> int vsnprintf_l (char *, size_t, locale_t, const char *, va_list)
>>> int vsscanf_l (const char *, locale_t, const char *, va_list);
>>> int dprintf_l (int, locale_t, const char *, ...)
>>> int vdprintf_l (int, locale_t, const char *, __va_list)
>>> int asprintf_l (char **, locale_t, const char *, ...)
>>> int vasprintf_l (char **, locale_t, const char *, __va_list)
>>>
>>> int fwprintf_l (FILE *, locale_t, const wchar_t *, ...)
>>> int fwscanf_l (FILE * , locale_t, const wchar_t *, ...)
>>> int wprintf_l (locale_t, const wchar_t *, ...)
>>> int wscanf_l (locale_t, const wchar_t *, ...)
>>> int wsprintf_l (char *, locale_t, const wchar_t * , ...)
>>> int swscanf_l (const char *, locale_t, const wchar_t * , ...)
>>> int vfwprintf_l (FILE *, locale_t, const wchar_t * , __va_list)
>>> int vwprintf_l (locale_t, const wchar_t *, __va_list)
>>> int vswprintf_l (wchar_t * , locale_t, const wchar_t *, __va_list);
>>> int snwprintf_l (wchar_t *, size_t, locale_t, const wchar_t * , ...)
>>> int vfwscanf_l (FILE * , locale_t, const wchar_t * , __va_list)
>>> int vwscanf_l (locale_t, const char *, __va_list)
>>> int vsnwprintf_l (wchar_t *, size_t, locale_t, const wchar_t *, va_list)
>>> int vswscanf_l (const wchar_t *, locale_t, const wchar_t *, va_list);
>>> int dwprintf_l (int, locale_t, const wchar_t *, ...)
>>> int vdwprintf_l (int, locale_t, const wchar_t *, __va_list)
>>> int aswprintf_l (wchar_t **, locale_t, const wchar_t *, ...)
>>> int vaswprintf_l (wchar_t **, locale_t, const wchar_t *, __va_list)
>>
>> Not sure how you generated this list. swprintf already behaves like
>> snprintf, so there is no need for a separate “n” variant. A
>> wide-character version of dprintf seems unlikely to be implemented
>> anytime soon.
>
> I didn't give much though to the list indeed and most likely this list
> will need to be revised. It was more to give the required complexity
> and work to provide such functionality to glibc.
>
>>
>> You did not list the fortify variants of these functions.
>
> Yes, this will require even more wrapper implementations.
>
>>
>> I would prefer to wait for standardization: it is not quite clear what
>> should happen if you use fwprintf_l on a wide stream that already uses a
>> different charset.
>
> Is this being discussed somewhere? We already have at least one implementation
> (not sure if MacOSX one is not the FreeBSD imported one and if Windows one
> does follow the expected interface). Should we block a possible implementation
> without proper standardization? What about a non wide set of implementations,
> would be feasible?
>
prev parent reply other threads:[~2020-10-29 16:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-17 11:33 ell1e
2020-10-19 21:01 ` Adhemerval Zanella
2020-10-20 5:45 ` Florian Weimer
2020-10-20 13:30 ` Adhemerval Zanella
2020-10-29 15:48 ` Florian Weimer
2020-10-29 16:02 ` ell1e [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e1ddd174-a096-db8d-60ee-cfb0750eee0a@wobble.ninja \
--to=kittens@wobble.ninja \
--cc=libc-help@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).