On Sun, 30 Jul 2023 20:20:31 -0500, Scott Cheloha wrote:
> This patch drags ualarm.3 over to where alarm.3 is. I think it reads
> better and the wording is truer to what the function actually does.
> In particular, ualarm(3) does not block or "wait": the alarm is
> scheduled for asynchronous
On Sun, Jul 30, 2023 at 08:20:31PM -0500, Scott Cheloha wrote:
> This patch drags ualarm.3 over to where alarm.3 is. I think it reads
> better and the wording is truer to what the function actually does.
> In particular, ualarm(3) does not block or "wait": the alarm is
> scheduled for
This patch drags ualarm.3 over to where alarm.3 is. I think it reads
better and the wording is truer to what the function actually does.
In particular, ualarm(3) does not block or "wait": the alarm is
scheduled for asynchronous delivery by the operating system.
I think I may have tried to clean
On Thu, Jul 01, 2021 at 08:50:12AM -0600, Todd C. Miller wrote:
> On Thu, 01 Jul 2021 08:14:51 -0600, "Todd C. Miller" wrote:
>
> > Aha, I see. It is because delay can be a float.
>
> Here's a diff to use nanosleep/setitimer instead of usleep/ualarm.
> Is it worth it?
Yes I think something
On Thu, 01 Jul 2021 08:14:51 -0600, "Todd C. Miller" wrote:
> Aha, I see. It is because delay can be a float.
Here's a diff to use nanosleep/setitimer instead of usleep/ualarm.
Is it worth it?
- todd
Index: usr.bin/systat/engine.c
On Thu, 01 Jul 2021 08:10:49 -0600, "Todd C. Miller" wrote:
> It looks like systat is the only consumer of ualarm(3) in the tree.
> I don't think it even makes sense there since the actual delay is
> in seconds, not microseconds. The change to ualarm/usleep was made
> by canacar@ in 2008. I
On Wed, 30 Jun 2021 17:24:28 -0600, "Theo de Raadt" wrote:
> Scott Cheloha wrote:
>
> > FWIW, the manpage has literally always led with this bolded
> > implementation detail. From January of 1986:
> >
> > https://svnweb.freebsd.org/csrg/lib/libc/gen/ualarm.3?revision=25789=m
> arkup
>
> I'm
Calling more than one of the interfaces setitimer(2), alarm(3),
and ualarm(3) in the same program results in unspecified behaviour.
I don't think it is unspecified. It will behave precisely as
expected...
Hi,
fair enough. When there are good reasons to not merge manual pages -
in this case, causing confusion about types and encouraging type
conversion, overflow, and truncation bugs, and alarm(3) and ualarm(3)
not being part of the same subsystem in the first place (if i
understand deraadt@
Scott Cheloha wrote:
> > +Exceedingly large timing arguments are succeptable to truncation.
> >
> > Rough warning feels like it is enough.
>
> Do you mean truncation or overflow?
Maybe, once again, accurately explain the problem.
Exceedingly large timing arguments will perform incorrectly
Scott Cheloha wrote:
> FWIW, the manpage has literally always led with this bolded
> implementation detail. From January of 1986:
>
> https://svnweb.freebsd.org/csrg/lib/libc/gen/ualarm.3?revision=25789=markup
I'm just saying it is uninformative and distracting.
> ... specifically,
On Wed, Jun 30, 2021 at 04:50:27PM -0600, Theo de Raadt wrote:
> Todd C. Miller wrote:
>
> > On Thu, 01 Jul 2021 00:14:12 +0200, Ingo Schwarze wrote:
> >
> > > Can the current wording below CAVEATS, "confusing behavior", be made
> > > more precise, explaining what actually happens rather than
On Wed, Jun 30, 2021 at 04:23:42PM -0600, Theo de Raadt wrote:
> >Uh, oh, to my naive ears (naive with respect to matters of time-related
> >functions), this sounds like a typical case where we likely want one
> >manual page documenting both alarm(3) and ualarm(3), not two pages.
> >
> >Basically,
Todd C. Miller wrote:
> On Thu, 01 Jul 2021 00:14:12 +0200, Ingo Schwarze wrote:
>
> > Can the current wording below CAVEATS, "confusing behavior", be made
> > more precise, explaining what actually happens rather than merely
> > calling it "confusing"? For example, saying that they all
Todd C. Miller wrote:
> > I think it would be ideal for the manual page text to state
> > which values can be used in a *portable* way. If, for some reason,
> > that is not desirable, then the main text should say which values
> > can be used on OpenBSD, and STANDARDS should say that using
On Thu, 01 Jul 2021 00:14:12 +0200, Ingo Schwarze wrote:
> Can the current wording below CAVEATS, "confusing behavior", be made
> more precise, explaining what actually happens rather than merely
> calling it "confusing"? For example, saying that they all override
> each other or something like
On Thu, 01 Jul 2021 00:14:12 +0200, Ingo Schwarze wrote:
> I'm confused. It seems i fail to find useconds_t in POSIX.
> I only see suseconds_t there, in , which must be signed,
> include [-1, 100], and not be wider than long. Also, our manual
> says ualarm(3) is -xpg4.2. That's basically
>Uh, oh, to my naive ears (naive with respect to matters of time-related
>functions), this sounds like a typical case where we likely want one
>manual page documenting both alarm(3) and ualarm(3), not two pages.
>
>Basically, the rule of thumb is: if two functions have a very similar
>purpose,
Hi Scott,
Scott Cheloha wrote on Wed, Jun 30, 2021 at 03:15:31PM -0500:
> As it would turn out, there are not one, but *two* simplified
> interfaces to setitimer(2). We just cleaned up the alarm(3) manpage,
> but did you know there is also a ualarm(3) interface?
I certainly didn't... :-)
>
Hi,
As it would turn out, there are not one, but *two* simplified
interfaces to setitimer(2). We just cleaned up the alarm(3) manpage,
but did you know there is also a ualarm(3) interface?
Luckily it's basically the same interface as alarm(3). So, I have
taken the rewritten manpage from
20 matches
Mail list logo
