public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
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?
> 

      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).