From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from thiem.email (elliethiem.com [116.203.31.83]) by sourceware.org (Postfix) with ESMTPS id D1C5B3854818 for ; Thu, 29 Oct 2020 16:02:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D1C5B3854818 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=wobble.ninja Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kittens@wobble.ninja Received: from [192.168.178.159] (pd9e158dc.dip0.t-ipconnect.de [217.225.88.220]) by thiem.email (Postfix) with ESMTPSA id 62829121DC3 for ; Thu, 29 Oct 2020 16:02:16 +0000 (UTC) Subject: Re: Is there a way to use vsnprintf_l? Would it possibly be considered for an addition one day, if missing? To: libc-help@sourceware.org References: <87sga95u39.fsf@oldenburg2.str.redhat.com> <97ee03c7-29a7-e0a4-2aa2-462efbc494f0@linaro.org> From: ell1e Message-ID: Date: Thu, 29 Oct 2020 17:02:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <97ee03c7-29a7-e0a4-2aa2-462efbc494f0@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 16:02:19 -0000 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? >