* Cygwin sysconf.cc
[not found] ` <d71a5b05-531f-8028-7b06-6ee466053f5f@SystematicSw.ab.ca>
@ 2022-03-01 20:20 ` Brian Inglis
2022-03-02 8:25 ` Corinna Vinschen
0 siblings, 1 reply; 5+ messages in thread
From: Brian Inglis @ 2022-03-01 20:20 UTC (permalink / raw)
To: Cygwin Patches
Interested in a patch for sysconf.cc to return:
_SC_TZNAME_MAX => TZNAME_MAX and
_SC_MONOTONIC_CLOCK => _POSIX_MONOTONIC_CLOCK?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Cygwin sysconf.cc
2022-03-01 20:20 ` Cygwin sysconf.cc Brian Inglis
@ 2022-03-02 8:25 ` Corinna Vinschen
2022-03-02 19:45 ` Brian Inglis
0 siblings, 1 reply; 5+ messages in thread
From: Corinna Vinschen @ 2022-03-02 8:25 UTC (permalink / raw)
To: cygwin-patches
Hi Brian,
On Mar 1 13:20, Brian Inglis wrote:
> Interested in a patch for sysconf.cc to return:
>
> _SC_TZNAME_MAX => TZNAME_MAX and
> _SC_MONOTONIC_CLOCK => _POSIX_MONOTONIC_CLOCK?
not sure I understand the question. Both are already implemented.
$ getconf -a | egrep '(TZNAME_MAX|MONOTONIC_CLOCK)'
_POSIX_TZNAME_MAX 6
TZNAME_MAX undefined
_POSIX_MONOTONIC_CLOCK 200809
Corinna
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Cygwin sysconf.cc
2022-03-02 8:25 ` Corinna Vinschen
@ 2022-03-02 19:45 ` Brian Inglis
2022-03-02 20:35 ` Corinna Vinschen
0 siblings, 1 reply; 5+ messages in thread
From: Brian Inglis @ 2022-03-02 19:45 UTC (permalink / raw)
To: cygwin-patches
On 2022-03-02 01:25, Corinna Vinschen wrote:
> Hi Brian,
>
> On Mar 1 13:20, Brian Inglis wrote:
>> Interested in a patch for sysconf.cc to return:
>>
>> _SC_TZNAME_MAX => TZNAME_MAX and
>> _SC_MONOTONIC_CLOCK => _POSIX_MONOTONIC_CLOCK?
>
> not sure I understand the question. Both are already implemented.
>
> $ getconf -a | egrep '(TZNAME_MAX|MONOTONIC_CLOCK)'
> _POSIX_TZNAME_MAX 6
> TZNAME_MAX undefined
> _POSIX_MONOTONIC_CLOCK 200809
Sorry, must have been looking at very *OLD* version online, as
_SC_CLOCK_SELECTION and _SC_MONOTONIC_CLOCK were not defined.
Why did you not define _SC_TZNAME_MAX => _POSIX_TZNAME_MAX when you
tweaked it?
My rereading of the man and POSIX pages leads me to believe that for all
known values of _SC_... the entries now showing {nsup, {c:0}} should be
{cons, {c:-1L}} supported but undefined, and only out of range values
for the parameter should be treated as {nsup, {c:-1L}}?
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Cygwin sysconf.cc
2022-03-02 19:45 ` Brian Inglis
@ 2022-03-02 20:35 ` Corinna Vinschen
2022-03-02 21:04 ` Corinna Vinschen
0 siblings, 1 reply; 5+ messages in thread
From: Corinna Vinschen @ 2022-03-02 20:35 UTC (permalink / raw)
To: cygwin-patches
On Mar 2 12:45, Brian Inglis wrote:
> On 2022-03-02 01:25, Corinna Vinschen wrote:
> > Hi Brian,
> >
> > On Mar 1 13:20, Brian Inglis wrote:
> > > Interested in a patch for sysconf.cc to return:
> > >
> > > _SC_TZNAME_MAX => TZNAME_MAX and
> > > _SC_MONOTONIC_CLOCK => _POSIX_MONOTONIC_CLOCK?
> >
> > not sure I understand the question. Both are already implemented.
> >
> > $ getconf -a | egrep '(TZNAME_MAX|MONOTONIC_CLOCK)'
> > _POSIX_TZNAME_MAX 6
> > TZNAME_MAX undefined
> > _POSIX_MONOTONIC_CLOCK 200809
>
> Sorry, must have been looking at very *OLD* version online, as
> _SC_CLOCK_SELECTION and _SC_MONOTONIC_CLOCK were not defined.
>
> Why did you not define _SC_TZNAME_MAX => _POSIX_TZNAME_MAX when you tweaked
> it?
Because it's wrong. _POSIX_TZNAME_MAX is just a minimum value required
by POSIX, not the correct value to return for TZNAME_MAX.
> My rereading of the man and POSIX pages leads me to believe that for all
> known values of _SC_... the entries now showing {nsup, {c:0}} should be
> {cons, {c:-1L}} supported but undefined, and only out of range values for
> the parameter should be treated as {nsup, {c:-1L}}?
These are really not undefined, but not supported on Cygwin. That's
why they return with EINVAL. I see what you mean, though, let me think
about it.
while looking into this I see at least one obvious bug. While adding
POSIX per-process timers in 2019 I added a valid DELAYTIMER_MAX value,
but I neglected to add this to sysconf. I'm going to fix this.
Corinna
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Cygwin sysconf.cc
2022-03-02 20:35 ` Corinna Vinschen
@ 2022-03-02 21:04 ` Corinna Vinschen
0 siblings, 0 replies; 5+ messages in thread
From: Corinna Vinschen @ 2022-03-02 21:04 UTC (permalink / raw)
To: cygwin-patches
On Mar 2 21:35, Corinna Vinschen wrote:
> On Mar 2 12:45, Brian Inglis wrote:
> > On 2022-03-02 01:25, Corinna Vinschen wrote:
> > > Hi Brian,
> > >
> > > On Mar 1 13:20, Brian Inglis wrote:
> > > > Interested in a patch for sysconf.cc to return:
> > > >
> > > > _SC_TZNAME_MAX => TZNAME_MAX and
> > > > _SC_MONOTONIC_CLOCK => _POSIX_MONOTONIC_CLOCK?
> > >
> > > not sure I understand the question. Both are already implemented.
> > >
> > > $ getconf -a | egrep '(TZNAME_MAX|MONOTONIC_CLOCK)'
> > > _POSIX_TZNAME_MAX 6
> > > TZNAME_MAX undefined
> > > _POSIX_MONOTONIC_CLOCK 200809
> >
> > Sorry, must have been looking at very *OLD* version online, as
> > _SC_CLOCK_SELECTION and _SC_MONOTONIC_CLOCK were not defined.
> >
> > Why did you not define _SC_TZNAME_MAX => _POSIX_TZNAME_MAX when you tweaked
> > it?
>
> Because it's wrong. _POSIX_TZNAME_MAX is just a minimum value required
> by POSIX, not the correct value to return for TZNAME_MAX.
>
> > My rereading of the man and POSIX pages leads me to believe that for all
> > known values of _SC_... the entries now showing {nsup, {c:0}} should be
> > {cons, {c:-1L}} supported but undefined, and only out of range values for
> > the parameter should be treated as {nsup, {c:-1L}}?
>
> These are really not undefined, but not supported on Cygwin. That's
> why they return with EINVAL. I see what you mean, though, let me think
> about it.
Yep, I guess you're right. I compared this with what Linux returns
for the unsupported tracing options. See commits cf00bba99a61 and
fcec4830abf0.
Thanks,
Corinna
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-03-02 21:04 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20220225163959.48753-1-Brian.Inglis@SystematicSW.ab.ca>
[not found] ` <20220225163959.48753-3-Brian.Inglis@SystematicSW.ab.ca>
[not found] ` <Yhy6OKd/2o8VqIUH@calimero.vinschen.de>
[not found] ` <d71a5b05-531f-8028-7b06-6ee466053f5f@SystematicSw.ab.ca>
2022-03-01 20:20 ` Cygwin sysconf.cc Brian Inglis
2022-03-02 8:25 ` Corinna Vinschen
2022-03-02 19:45 ` Brian Inglis
2022-03-02 20:35 ` Corinna Vinschen
2022-03-02 21:04 ` Corinna Vinschen
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).