Question regarding gettext behavior on iconv failure

Hello GNU gettext maintainers, In today's Austin Group meeting, we developed an example of using the proposed POSIX standardization of gettext() and encountered a situation where we felt that GNU gettext may have a bug. For context, the entire example is at:

Re: SIGSTKSZ is now a run-time variable

[adding glibc and Austin group lists] On 3/6/21 12:50 PM, Bruno Haible wrote: > Hi, > > Carol Bouchard wrote in > : >> A change that was introduced is the >> #define SIGSTKSZ is no longer a statically defined variable. It's value

Re: SIGSTKSZ is now a run-time variable

On 3/9/21 9:26 AM, Andreas Schwab wrote: > On Mär 09 2021, Eric Blake via Libc-alpha wrote: > >> The question becomes whether glibc is in violation of POSIX for having >> made the change, or whether POSIX needs to be amended to allow SIGSTKSZ >> to be non-preprocessor-safe and/or non-constant. >

Re: SIGSTKSZ is now a run-time variable

On 3/9/21 10:14 AM, shwaresyst wrote: > > To me that looks like a conformance violation and should be reverted. There > is no _SC_SIGSTKSZ defined in by the standard, to begin with, so > that use of sysconf() is a non-portable extension on its own. Portable apps can't use _SC_SIGSTKSZ, but

Re: SIGSTKSZ is now a run-time variable

On 3/9/21 1:34 PM, Eric Blake via austin-group-l at The Open Group wrote: > On 3/9/21 10:14 AM, shwaresyst wrote: >> >> To me that looks like a conformance violation and should be reverted. There >> is no _SC_SIGSTKSZ defined in by the standard, to begin with, so &

Re: Interpretation starting for a 30 day review (1440)

On Sat, Oct 30, 2021 at 12:46:55AM +0700, Robert Elz via austin-group-l at The Open Group wrote: > Date:Fri, 29 Oct 2021 10:00:04 -0700 > From:Nick Stoughton > Message-ID: > > > | Just for reference, the C standard says: > > Thanks, it was a little hard to

Re: [1003.1(2016/18)/Issue7+TC2 0001440]: Calling `system("-some-tool")` fails (although it is a valid `sh` command)

On Sat, Oct 30, 2021 at 08:21:55PM -0400, Wayne Pollock via austin-group-l at The Open Group wrote: > Is it guaranteed that on conforming systems nohup (and friends) must not > accept or > delete the first "--"? For the example to work, nohup must not discard the > "--". > But might it? I'm

Re: how do to cmd subst with trailing newlines portable (was: does POSIX mandate whether the output…)

On Tue, Feb 08, 2022 at 06:53:50AM +0100, Christoph Anton Mitterer via austin-group-l at The Open Group wrote: > Hey. > > I'm afraid but some more questions came up on my side: > > > 1) POSIX says: > "The encoded values associated with , , , and > shall be invariant across all locales

Re: bug#65659: RFC: changing printf(1) behavior on %b

On Thu, Aug 31, 2023 at 03:10:58PM -0400, Chet Ramey wrote: > On 8/31/23 11:35 AM, Eric Blake wrote: > > In today's Austin Group call, we discussed the fact that printf(1) has > > mandated behavior for %b (escape sequence processing similar to XSI > > echo) that will eventually conflict with C2x's

Re: bug#65659: RFC: changing printf(1) behavior on %b

On Fri, Sep 01, 2023 at 08:59:19AM +0100, Stephane Chazelas wrote: > 2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group: > [...] > > The current POSIX says that %b was added so that on a non-XSI > > system, you could do: > > > >

Re: bug#65659: RFC: changing printf(1) behavior on %b

On Fri, Sep 01, 2023 at 07:19:13AM +0200, Phi Debian wrote: > Well after reading yet another thread regarding libc_printf() I got to > admit that even %B is crossed out, (Yet already choosen by ksh93) > > The other thread also speak about libc_printf() documentting %# as > undefined for things

RFC: changing printf(1) behavior on %b

In today's Austin Group call, we discussed the fact that printf(1) has mandated behavior for %b (escape sequence processing similar to XSI echo) that will eventually conflict with C2x's desire to introduce %b to printf(3) (to produce 0b000... binary literals). For POSIX Issue 8, we plan to mark

Re: [Issue 8 drafts 0001556]: clarify meaning of \n used in a bracket expression in a sed context address or s-command

Adding bug-...@gnu.org into this conversation. On Mon, Apr 25, 2022 at 02:50:22AM +0200, Christoph Anton Mitterer via austin-group-l at The Open Group wrote: > Hey. > > Geoff, I haven't had time yet to look at your updated proposal of > #1550, not sure whether I manage to do it this night or in

Re: Can struct sockaddr_un.sun_path be a flexible array member?

On Sun, Jul 17, 2022 at 03:46:52PM -0700, Nick Stoughton via austin-group-l at The Open Group wrote: > Note that a flexible array member is not the same thing as a variable > length array, and although both entered the standard in C99, previous > versions allowed the FAM to be specified as an

Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility

On Fri, Jul 22, 2022 at 09:26:45AM +0200, Quentin Rameau via austin-group-l at The Open Group wrote: > Hello, > > > == > > https://austingroupbugs.net/view.php?id=1457 > >

Re: [1003.1(2016/18)/Issue7+TC2 0001457]: Add readlink(1) utility

On Fri, Jul 22, 2022 at 05:04:09PM +0100, Jonathan Wakely wrote: > On Fri, 22 Jul 2022 at 15:53, Robert Elz via austin-group-l at The > Open Group wrote: > > Aside from that possibility the only reason would seem to be the same > > as why echo (real ones) have -n (and trashy ones have \c) and why

Re: Latest on POSIX efforts to standardize gettext

On Thu, May 05, 2022 at 09:31:41AM -0500, Eric Blake via austin-group-l at The Open Group wrote: > Hello GNU and Illumos folks, > > The Austin Group (those in charge of the POSIX specification) have > been working on a draft to incorporate the gettext(3) family of > functions and

Latest on POSIX efforts to standardize gettext

Hello GNU and Illumos folks, The Austin Group (those in charge of the POSIX specification) have been working on a draft to incorporate the gettext(3) family of functions and related gettext(1) utilities into the next revision of POSIX (per https://austingroupbugs.net/view.php?id=1122). After

Re: [1003.1(2008)/Issue 7 0000561]: NUL-termination of sun_path in Unix sockets

On Wed, Nov 30, 2022 at 08:54:03AM -0600, Eric Blake via austin-group-l at The Open Group wrote: > > ... > > |https://austingroupbugs.net/view.php?id=561 > > First, I chose that wording because 'sizeof(struct > sockaddr_un.sun_path)' doesn't compile. You a

Re: [1003.1(2008)/Issue 7 0000561]: NUL-termination of sun_path in Unix sockets

On Mon, Nov 28, 2022 at 07:30:36PM +0100, Steffen Nurpmeso via austin-group-l at The Open Group wrote: > Austin Group Bug Tracker wrote in > : > ... > |https://austingroupbugs.net/view.php?id=561 > ... > |-- > | (0006085)

Austin Group questions on iconv()

In today's Austin Group meeting, the folks discussing POSIX had a question for Bruno and/or anyone else with an idea on how the standards should approach a difference in behavior between Solaris and GNU iconv() implementations. For context, today's meeting minutes:

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

On Fri, Apr 21, 2023 at 05:00:14PM +0200, Alejandro Colomar wrote: > > > > The wording I see in > > doesn't seem to cover the case of aliasing a sockaddr_storage as a > > protocol-specific address for setting other members. > > > > Aliasing

Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used

On Thu, Apr 06, 2023 at 02:05:15PM -0400, Zack Weinberg wrote: > On Thu, Apr 6, 2023, at 12:31 PM, Alejandro Colomar via Libc-alpha wrote: > > On 4/6/23 18:24, Eric Blake wrote: > >> here's the updated wording that the Austin Group tried today (and we > >> plan on starting a 30-day interpretation

Re: encoding question

On Sat, Jul 15, 2023 at 10:41:49PM +, Thorsten Glaser via austin-group-l at The Open Group wrote: > Hi, > > I get that the POSIX locale must be a single-byte character locale > where all 256 octets are characters. I’ve got a question about the > wide character representation. > > Assuming

Re: [Issue 8 drafts 0001798]: Must posix_getdents remember file offsets across exec?

Adding in Corinna Vinshcen, one of the Cygwin developers. She had problems trying to post directly on the bug page, so we can use email replies and summarize the results back to the bug. On Mon, Jan 22, 2024 at 03:30:20PM +, Austin Group Bug Tracker via austin-group-l at The Open Group

Re: Questions on strftime vs. POSIX

ful time format from a single interface. For example, https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00077.html https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg00064.html Eric Blake On Wed, Feb 07, 2024 at 08:14:39AM -0600, Eric Blake via austin-group-l at The Open Group w

Re: Re: Questions on strftime vs. POSIX

Widening the scope of this conversation, with Paul's permission. Context for the Open Group readers: per my Action Item from Monday's meeting, I emailed Paul regarding https://austingroupbugs.net/bug_view_page.php?bug_id=1797 On Mon, Feb 05, 2024 at 10:51:34AM -0800, Paul Eggert wrote: > On

Re: Recommendation for POSIX ed consideration

Hello Andrew, I'm forwarding your message on to the full Austin Group. On Sun, Dec 10, 2023 at 11:37:40PM -0500, Andrew L. Moore wrote: > Hi, > I am the author of the original GNU ed and maintain an alternative (and I > might add, much more robust) version at github.com/slewsys/ed. > > One thing