Re: SIGSTKSZ is now a run-time variable

Bruno: Just wanted to add...glibc has made this change and Not yet released Fedora has made this change among a number of other packages. This is the trend going forward. Carol On Mon, Mar 8, 2021 at 8:48 AM Carol Bouchard wrote: > Hi Bruno: > > This is the direction everyone is going in.

Re: SIGSTKSZ is now a run-time variable

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. POSIX already allows non-preprocessor-safe. Andre

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

[adding bug-gnulib] 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 can >> only be det

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 Tue, Mar 9, 2021 at 10:23 AM Eric Blake via Libc-alpha wrote: > [adding glibc and Austin group lists] > On 3/6/21 12:50 PM, Bruno Haible wrote: > > Besides being invalid, it is also not needed. The alternate signal stack > > needs to be dimensioned according to the CPU and ABI that is in use. F

Re: SIGSTKSZ is now a run-time variable

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. I could see the definition of SIGSTKSZ being changed to the static minimum a particular pr

Re: SIGSTKSZ is now a run-time variable

On 3/9/21 8:14 AM, shwaresyst via Libc-alpha wrote: The question becomes whether glibc is in violation of POSIX for having made the change, I don't see how that would be. Apps must define _SC_SIGSTKSZ_SOURCE or _GNU_SOURCE to get the new API, which means the apps do not want strict POSIX conf

Re: SIGSTKSZ is now a run-time variable

Eric Blake wrote: > I can open a defect against POSIX if we decide that is needed, but want > some consensus first on whether it is glibc's change that went too far, > or POSIX's requirements that are too restrictive for what glibc wants to do. Thanks for opening the discussion, Eric. Here are a

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 the

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 >> that use of sysconf() is a no

Re: SIGSTKSZ is now a run-time variable

On Tue, Mar 9, 2021 at 12:27 PM Bruno Haible wrote: > > Eric Blake wrote: > > I can open a defect against POSIX if we decide that is needed, but want > > some consensus first on whether it is glibc's change that went too far, > > or POSIX's requirements that are too restrictive for what glibc want

Re: SIGSTKSZ is now a run-time variable

Yes, it's not something an application would expect to need to keep increasing, just that's the part of I'd move it to. The definition could also be the max required by a processor family, with sysconf() reporting a possible lower value for a particular processor stepping. At least that way th

Re: SIGSTKSZ is now a run-time variable

On Tue, Mar 09, 2021 at 08:58:38PM +0100, Bruno Haible via austin-group-l at The Open Group wrote: > Eric Blake wrote: > > I can open a defect against POSIX if we decide that is needed, but want > > some consensus first on whether it is glibc's change that went too far, > > or POSIX's requirements

Re: SIGSTKSZ is now a run-time variable

On Tue, Mar 9, 2021 at 1:53 PM shwaresyst via Libc-alpha wrote: > > > Yes, it's not something an application would expect to need to keep > increasing, just that's the part of I'd move it to. The definition > could also be the max required by a processor family, with sysconf() > reporting a po