Re: times(3): return monotonically increasing values

On Wed, Feb 28, 2018 at 08:58:41AM -0700, Todd C. Miller wrote: > On Wed, 28 Feb 2018 09:46:30 -0600, Scott Cheloha wrote: > > > I want to avoid giving the reader even the slightest impression that > > the return value from times(3) can be used for anything but real-time > &

Re: times(3): return monotonically increasing values

On Tue, Feb 27, 2018 at 07:15:03AM +, Jason McIntyre wrote: > On Mon, Feb 26, 2018 at 07:12:20PM -0600, Scott Cheloha wrote: > > [...] > > > [...] > > > > I don't have access to 1003.1-1988 [1] (the most recent standard > > cited in times.3

Re: times(3): return monotonically increasing values

On Tue, Feb 27, 2018 at 11:38:07AM -0700, Todd C. Miller wrote: > On Mon, 26 Feb 2018 19:12:20 -0600, Scott Cheloha wrote: > > > Reading the latest POSIX description for times(3): > > > > > Upon successful completion, times() shall return the elapsed > > &

times(3): return monotonically increasing values

ther library function page and reword things to look like other library function pages (did my best). Attached changes ok? Input on the manpage restructuring/rewording? -- Scott Cheloha [1] It's this, right? https://standards.ieee.org/findstds/standard/1003.1-1988.html Index: lib/libc

Re: shutdown: simplify countdown loop()

On Sun, Feb 25, 2018 at 10:42:04AM +0100, Theo Buehler wrote: > On Sat, Feb 24, 2018 at 06:25:44PM -0600, Scott Cheloha wrote: > > [...] > > > > If we treat tlist[] like an array instead of a list, we can > > eliminate a lot of special cases and duplicate calls in shutd

shutdown: simplify countdown loop()

is a time_t, so there's just less type friction. It also makes things simpler for some later diffs I have planned. But so, int -> time_t, hence sleep -> nanosleep. ok? -- Scott Cheloha Index: sbin/shutdown/shutdown.c === RCS file: /c

Re: shutdown: fork+exec for wall(1) broadcasts

On Thu, Feb 22, 2018 at 02:13:16PM -0700, Todd C. Miller wrote: > On Thu, 22 Feb 2018 15:06:04 -0600, Scott Cheloha wrote: > > > Could that difference effect the behavior of the program in practice? > > I don't think so. > > > [...] > > > > So unless

Re: shutdown: fork+exec for wall(1) broadcasts

On Thu, Feb 22, 2018 at 01:09:02PM -0700, Todd C. Miller wrote: > On Thu, 22 Feb 2018 13:50:13 -0600, Scott Cheloha wrote: > > > I think setjmping from a signal handler to put a time limit on > > pclose is too magical, especially when the alternative doesn't > >

shutdown: fork+exec for wall(1) broadcasts

/fork/execle, * fprintf -> dprintf, fwrite -> write, and * Strip SA_RESTART from SIGALRM's sigaction so we EINTR out of our wait(2) after 30 seconds. We wait (instead of waitpid) to pick up any stragglers from prior calls to timewarn() that we had to leave behind. ok? -- Scott C

Re: vmd: drive i8253 with monotonic clock

On Sun, Feb 18, 2018 at 02:44:43PM -0800, Mike Larkin wrote: > On Sun, Feb 18, 2018 at 12:00:01PM -0600, Scott Cheloha wrote: > > Hi, > > > > Is it bad if the olatch counts up if the host's wall clock > > is set backward? Or if the olatch makes a big j

vmd: drive i8253 with monotonic clock

into a loop, and (b) use the timespecsub macro from sys/time.h, to make the code briefer. Anyone down to test? -- Scott Cheloha Index: usr.sbin/vmd/i8253.c === RCS file: /cvs/src/usr.sbin/vmd/i8253.c,v retrieving revision 1.17 diff -u

hostapd: account for subseconds when checking rule rates

al = 1; /* true */ t_now.tv_sec - frame->f_last.tv_sec >= frame->f_rate_intval /* and yet ... */ struct timeval t_diff; timersub(_now, >f_last, _diff); /* also true */ t_diff.tv_sec < frame->f_rate_intval ok? -- Scott

sleep(1): cleanup and style(9)

-known practice, no need to explain ok? -- Scott Cheloha Index: bin/sleep/sleep.c === RCS file: /cvs/src/bin/sleep/sleep.c,v retrieving revision 1.26 diff -u -p -r1.26 sleep.c --- bin/sleep/sleep.c 4 Feb 2018 02:18:15 -

sasyncd: schedule events against monotonic clock

So that events fire punctually even if the system clock is changed. ok? -- Scott Cheloha Index: usr.sbin/sasyncd/sasyncd.c === RCS file: /cvs/src/usr.sbin/sasyncd/sasyncd.c,v retrieving revision 1.27 diff -u -p -r1.27 sasyncd.c

date: atoll - > strtonum

ok? Index: bin/date/date.c === RCS file: /cvs/src/bin/date/date.c,v retrieving revision 1.51 diff -u -p -r1.51 date.c --- bin/date/date.c 23 Dec 2017 20:58:14 - 1.51 +++ bin/date/date.c 12 Feb 2018 16:29:24 - @@

hostapd: normalize microsecond limit when parsing

Hi, I'm unfamiliar with this code, but assigning the microsecond value without normalizing it for the timeval looks off. -- Scott Cheloha Index: usr.sbin/hostapd/parse.y === RCS file: /cvs/src/usr.sbin/hostapd/parse.y,v retrieving

Re: iostat: cap wait/interval at 100 million seconds

On Sat, Feb 10, 2018 at 01:12:59PM +1300, Theo Buehler wrote: > On Fri, Feb 09, 2018 at 05:41:34PM -0600, Scott Cheloha wrote: > > Hi, > > > > nanosleep(2) won't take more than 100 million seconds at a time, > > so we ought to cap interval when we read it in. Otherwise

iostat: cap wait/interval at 100 million seconds

new syntax is in use, so we should call it that in the error message for the '-w' flag. ok? -- Scott Cheloha Index: usr.sbin/iostat/iostat.c === RCS file: /cvs/src/usr.sbin/iostat/iostat.c,v retrieving revision 1.39 diff -

leave(1): schedule absolute alarm for start of minute

that refactors that function to obviate it. ok? -- Scott Cheloha Index: usr.bin/leave/leave.c === RCS file: /cvs/src/usr.bin/leave/leave.c,v retrieving revision 1.17 diff -u -p -r1.17 leave.c --- usr.bin/leave/leave.c 9 Oct 2015 01:37

shutdown(8): fprintf(stderr -> warnx

ok? -- Scott Cheloha Index: sbin/shutdown/shutdown.c === RCS file: /cvs/src/sbin/shutdown/shutdown.c,v retrieving revision 1.46 diff -u -p -r1.46 shutdown.c --- sbin/shutdown/shutdown.c3 Apr 2017 20:59:19 - 1.46

sleep(1): better error messages

with what other utilities do. ok? -- Scott Cheloha Index: bin/sleep/sleep.c === RCS file: /cvs/src/bin/sleep/sleep.c,v retrieving revision 1.25 diff -u -p -r1.25 sleep.c --- bin/sleep/sleep.c 2 Feb 2018 16:46:37 - 1.25

Re: sleep(1): support longer naps

On Wed, Jan 31, 2018 at 07:25:58AM +, Jason McIntyre wrote: > On Wed, Jan 31, 2018 at 05:52:35AM +0100, Theo Buehler wrote: > > On Thu, Jan 25, 2018 at 09:35:33PM -0600, Scott Cheloha wrote: > > > [...] > > > > > > I'm not sure whether the l

init(8): check GETTY_SPACING against monotonic clock

there isn't any reason to continue retrieving the current time in the parent process if we're doing the comparison in the child process, so I've moved the system call into that block. ok? -- Scott Cheloha Index: sbin/init/init.c === RCS

sleep(1): support longer naps

not sure whether the larger range is actually an extension to the standard, and if so whether we need to mention it in the manpage, but I've included a diff here anyway just in case. If you have ideas about the wording I'd love to hear them. Thoughts? ok? -- Scott Cheloha Index: bin/sleep/sleep.1

init.8: getty sleep is 30 seconds, not 10

Hi, The child in start_getty() sleeps 30 seconds (not 10) before continuing if getty exited too quickly in its prior attempt. ok? -- Scott Cheloha Index: sbin/init/init.8 === RCS file: /cvs/src/sbin/init/init.8,v retrieving

Re: mg: extract child status with WEXITSTATUS

On Tue, Jan 09, 2018 at 10:05:22AM -0600, Scott Cheloha wrote: > After discussing it with jca@ and trying a few variations I've settled > on the attached diff. > > We indicate if sh(1) was signalled because we have that information at > hand. Otherwise we report the exit status as

Re: mg: extract child status with WEXITSTATUS

After discussing it with jca@ and trying a few variations I've settled on the attached diff. We indicate if sh(1) was signalled because we have that information at hand. Otherwise we report the exit status as we always have. ok? Index: grep.c

authpf: use monotime for duration log

, or if time_t is a floating-point type. At least, that's the impression I got when I read that POSIX allows time_t to be basically anything. AFAICT we typically cast it to long long. Thoughts? ok? -- Scott Cheloha Index: usr.sbin/authpf/authpf.c

Re: mg: extract child status with WEXITSTATUS

On Mon, Jan 01, 2018 at 09:07:25PM -0700, Todd C. Miller wrote: > On Mon, 01 Jan 2018 19:54:07 -0600, Scott Cheloha wrote: > > > Hey, > > > > In the mg(1) *compile* buffer, currently you get incorrect > > output like: > > > > Command exited abnor

mg: extract child status with WEXITSTATUS

Hey, In the mg(1) *compile* buffer, currently you get incorrect output like: Command exited abnormally with code 256 at [...] Using the W* macros in corrects this: Command exited abnormally with code 1 at [...] ok? -- Scott Cheloha Index: usr.bin/mg/grep.c

rpc: misc. time-related cleanup

The timevals in clnt_tcp.c and clnt_udp.c are assigned and never used. The timevals in auth_unix.c are only used for the .tv_sec field, so we can just initialize .aup_time with time(3). ok? -- Scott Cheloha Index: lib/libc/rpc/auth_unix.c

Re: ports.7: double distfile fetch size: 20 -> 40

On Wed, Dec 27, 2017 at 04:12:49AM +0100, Marc Espie wrote: > On Tue, Dec 26, 2017 at 05:51:51PM +0100, Jeremie Courreges-Anglas wrote: > > On Tue, Dec 26 2017, Scott Cheloha <scottchel...@gmail.com> wrote: > > > Hey, > > > > > > I just did a full p

ports.7: double distfile fetch size: 20 -> 40

of the largest working directories, I'll incorporate those too and commit it. -- Scott Cheloha Index: share/man/man7/ports.7 === RCS file: /cvs/src/share/man/man7/ports.7,v retrieving revision 1.115 diff -u -p -r1.115 ports.7 --- share/man/man7

Re: mktemp: Clarify error message

ains two possible error cases in a single go. This necessitates more thinking on the part of the user. Why not just acknowledge the two errors differently? $ mktemp test.X mktemp: insufficient number of Xs in template: test.X $ mktemp test.XXC mktemp: invalid template suffix: test.X

pom: consolidate printing

Hey, Next up for pom(6): consolidate the printf(3) calls. The inline printing obfuscates what is otherwise a very simple classification algorithm. ok? -- Scott Cheloha Index: games/pom/pom.c === RCS file: /cvs/src/games/pom/pom.c

pom: use round(3), fmod(3)

) with its documented and, in this case, equivalent behavior is much clearer. thoughts? ok? -- Scott Cheloha Index: games/pom/pom.c === RCS file: /cvs/src/games/pom/pom.c,v retrieving revision 1.26 diff -u -p -r1.26 pom.c --- games/pom/po

cdio, ftp: use monotime for progress logging

Hey, Use the monotonic clock when logging progress in cdio(1) and ftp(1). This keeps the progress log from blipping or stalling if the system time is changed, e.g., in the midst of a transfer or rip. ok? -- Scott Cheloha Index: usr.bin/cdio/mmc.c

arp, date, pom, pr: gettimeofday(2) -> time(3)

: Operation not permitted is considerably more useful than this: date: adjtime Of some note is that pom(6) was one of the last programs in base calling gettimeofday(2) with a non-NULL timezone argument. ok? -- Scott Cheloha Index: bin/date/date.c

clock_gettime: add CLOCK_BOOTTIME clockid

their ok. Thoughts and feedback? -- Scott Cheloha [1] https://marc.info/?l=linux-kernel=129783004314557=2 [2] https://github.com/torvalds/linux/commit/420c1c572d4ceaa2f37b6311b7017ac6cf049fe2 Index: lib/libc/sys/clock_gettime.2 === RCS

rpc: use monotime for timeouts

of the if statement in clnt_udp.c. Its use makes the diff simpler. This is probably not adequately tested, though it compiles and I'm not seeing any issues in my (small) NFS setup. Thoughts and feedback? -- Scott Cheloha Index: lib/libc/rpc/clnt_tcp.c

TIMEVAL_TO_TIMESPEC, etc: use do-loop for compound macros

Hi, Per style(9), macros with compound statements are easier used in an if statement when do-loop wrapped. -- Scott Cheloha P.S. Is it just me or does the argument ordering for TIMESPEC_TO_TIMEVAL seem backwards? Index: sys/sys/time.h

grdc: simplify via clock_gettime

arate diff. -- Scott Cheloha Index: games/grdc/grdc.c === RCS file: /cvs/src/games/grdc/grdc.c,v retrieving revision 1.27 diff -u -p -r1.27 grdc.c --- games/grdc/grdc.c 13 Jul 2017 02:57:52 - 1.27 +++ games/grdc/grdc.c 10 Dec 201

tmux: selective application of monotonic clock

complicated because they are user-facing and serve multiple purposes: a mix of timestamps, heuristics, and interval measurements. So those merit a separate discussion and might not be worth the added complexity. Thoughts and feedback? -- Scott Cheloha Index: usr.bin/tmux/Makefile

Re: openssl s_time, speed: use monotime for absolute interval measurement

ere with the same. A subsequent diff will expose the separate functions to the rest of the modules via apps.h, and later diffs in, e.g., speed and s_time, can make use of the now-distinct timer routines at their leisure. -- Scott Cheloha > Index: apps.h > ===

Re: gettimeofday(2) does not conform to POSIX.1-2008?

ribe a system incompletely, > it makes it harder for software developers to consider them as a > proscriptive or leading agency. Errors result. How apropos that I write "behavior" when I meant "wording." Point well taken. -- Scott Cheloha

Re: gettimeofday(2) does not conform to POSIX.1-2008?

nly zero" behavior traces back at least as far as here (SUSv2, I think): http://pubs.opengroup.org/onlinepubs/7908799/xsh/gettimeofday.html so if it's an error it isn't a "new" error. > > Does this make our implementation non-conforming and does something > > in the manpage need to change? > > I don't think anything should change. Okay. Appreciate the quick reply! -- Scott Cheloha

gettimeofday(2) does not conform to POSIX.1-2008?

r implementation non-conforming and does something in the manpage need to change? I do note that gettimeofday(2) predates [3] POSIX (and me :p), so perhaps this is just an ancient compromise between BSD and the standards committees? Thoughts? -- Scott Cheloha [1] http://pubs.opengroup.org/

Re: isakmpd: use monotonic clock for event timeouts

On Mon, Nov 27, 2017 at 08:36:33PM -0600, Scott Cheloha wrote: > > > On Nov 27, 2017, at 9:54 AM, Jeremie Courreges-Anglas <j...@wxcvbn.org> > > wrote: > > > > On Fri, Nov 24 2017, Scott Cheloha <scottchel...@gmail.com> wrote: > >> Hi, &

Re: isakmpd: use monotonic clock for event timeouts

> On Nov 27, 2017, at 9:54 AM, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: > > On Fri, Nov 24 2017, Scott Cheloha <scottchel...@gmail.com> wrote: >> Hi, >> >> [...] >> >> Thoughts and feedback? > > This seems to mix re

fortune: typo: than -> then

Index: games/fortune/datfiles/fortunes2 === RCS file: /cvs/src/games/fortune/datfiles/fortunes2,v retrieving revision 1.48 diff -u -p -r1.48 fortunes2 --- games/fortune/datfiles/fortunes213 Jul 2017 02:45:56 - 1.48 +++

isakmpd: use monotonic clock for event timeouts

. Thoughts and feedback? -- Scott Cheloha Index: sbin/isakmpd/connection.c === RCS file: /cvs/src/sbin/isakmpd/connection.c,v retrieving revision 1.38 diff -u -p -r1.38 connection.c --- sbin/isakmpd/connection.c 6 Aug 2017 13:54:04

Re: openssl s_time, speed: use monotime for absolute interval measurement

> On Nov 24, 2017, at 6:58 AM, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: > > On Wed, Nov 22 2017, Scott Cheloha <scottchel...@gmail.com> wrote: >> Whoops, ignore that last patch, it lacked the >> static changes in apps_posix.c > > This l

isakmpd.8: define "SA" abbreviation before use

Hi, This makes parts of isakmpd(8) more immediately intelligible to a beginner. -- Scott Cheloha Index: sbin/isakmpd/isakmpd.8 === RCS file: /cvs/src/sbin/isakmpd/isakmpd.8,v retrieving revision 1.118 diff -u -p -r1.118 isakmpd.8

less: use monotonic clock for line number echo

Hi, The "Calculating line numbers" echo in less(1) is meant to fire after an interval has elapsed, so we should use the monotonic clock to measure. Currently, if the system time is changed during the execution of find_linenum() the echo fires too quickly or not at all. -- Scott Chel

Re: openssl s_time, speed: use monotime for absolute interval measurement

Whoops, ignore that last patch, it lacked the static changes in apps_posix.c -- Scott Cheloha Index: usr.bin/openssl/apps_posix.c === RCS file: /cvs/src/usr.bin/openssl/apps_posix.c,v retrieving revision 1.2 diff -u -p -r1.2

Re: openssl s_time, speed: use monotime for absolute interval measurement

On Sat, Nov 18, 2017 at 05:27:14PM +0100, Jeremie Courreges-Anglas wrote: > On Sat, Nov 11 2017, Scott Cheloha <scottchel...@gmail.com> wrote: > > [...] > > I doubt that timersub/timespecsub are a big problem to add to -portable, > they're just macros. clock_gettime and g

Re: pppd: explicit_bzero sensitive buffers

> On Nov 17, 2017, at 3:07 PM, Stuart Henderson <s...@spacehopper.org> wrote: > > On 2017/11/17 21:55, Jeremie Courreges-Anglas wrote: >> On Sat, Nov 11 2017, Scott Cheloha <scottchel...@gmail.com> wrote: >>> Hi, >>> >>> You want explicit

__warn_references: drop redundant "warning: " prefix

Hi, GNU ld has prefixed the contents of .gnu.warning.SYMBOL sections with "warning: " since 2003, so the messages themselves need not contain the prefix anymore. If LLVM ld ever acknowledges .gnu.warning sections I imagine it would emulate this behavior. Thoughts? -- Scott Cheloha

Re: pppd: explicit_bzero sensitive buffers

> On Nov 11, 2017, at 7:30 PM, Matthew Martin <phy1...@gmail.com> wrote: > > There's a stray whitespace change and explicit sorts below exit. [...] Whoops, here you go. -- Scott Cheloha Index: usr.sbin/pppd/auth.c =

pppd: explicit_bzero sensitive buffers

Hi, You want explicit_bzero(3) for these buffers. Zeroing a buffer is compiler- and system-dependent, so I added a new macro. I'll send a pull request upstream if this goes in. -- Scott Cheloha Index: usr.sbin/pppd/auth.c === RCS

openssl s_time, speed: use monotime for absolute interval measurement

. Is this a problem for libressl-portable? Thoughts and feedback? -- Scott Cheloha Index: usr.bin/openssl/apps.h === RCS file: /cvs/src/usr.bin/openssl/apps.h,v retrieving revision 1.19 diff -u -p -r1.19 apps.h --- usr.bin/openssl/apps.h 30 Aug

primes: use strtonum(3)

takers? -- Scott Cheloha Index: games/primes/primes.c === RCS file: /cvs/src/games/primes/primes.c,v retrieving revision 1.23 diff -u -p -r1.23 primes.c --- games/primes/primes.c 31 Aug 2016 04:48:43 - 1.23 +++ games

Re: mg: extract exit status from pclose return value

> On Aug 25, 2017, at 11:27 PM, Scott Cheloha <scottchel...@gmail.com> wrote: > > compile_mode() currently just reports the value returned by > pclose(3). This is incorrect because pclose gives you > whatever wait4(2) returned, which needs to be examined > wi

dd: exit nonzero on receipt of SIGINT

diff?r1=1.19=1.20_with_tag=MAIN=h This is the most unique interpretation I found. But my gut says that this is a misreading of "exit as though terminated by SIGINT," and that exiting with 128 + signo is closer to what was meant. Thoughts? -- Scott Cheloha

Re: mg: fgetln -> getline

> On Oct 11, 2017, at 2:36 AM, Florian Obser <flor...@openbsd.org> wrote: > > On Sun, Sep 17, 2017 at 02:56:32AM +, Scott Cheloha wrote: >> >> >> if (buf[len - 1] == '\n') >> buf[len - 1] = '\0'; > > the diff reads fine to m

files.macppc: fix recursive dependency, parallel build race

? -- Scott Cheloha Index: sys/arch/macppc/conf/files.macppc === RCS file: /cvs/src/sys/arch/macppc/conf/files.macppc,v retrieving revision 1.88 diff -u -p -r1.88 files.macppc --- sys/arch/macppc/conf/files.macppc 13 Jun 2017 01:44:27

Re: pthread_once: don't deadlock on cancel from init_routine

Hi, > On Oct 1, 2017, at 9:30 PM, Scott Cheloha <scottchel...@gmail.com> wrote: > > Per this bit from pthread_once(3): > >> The function pthread_once() is not a cancellation point. >> However, if init_routine() is a cancellation point and is >> c

pthread_once: don't deadlock on cancel from init_routine

ter and I'm out of my depth. And given the recent interface migrations I don't know which is most appropriate. Thoughts? -- Scott Cheloha P.S. I've never cvs-add'd directories or files before. Or written a bsd.regress.mk regression test. Did my best to make it look like the others in regress/lib/libp

mg: fgetln -> getline

do_cscope() looked like a typo so I deleted the semicolon. I also noticed that there were no error checks after the read loops so I added an echo print on ferror(). I don't know if this is sufficient, but we weren't doing anything before, so it's a start. Thoughts? -- Scott Cheloha Index:

vscsi.4, wsdisplay.4: add missing Dv tags to ioctl constants

splay_font Selects the font specified in the .Va name field. -- Scott Cheloha Index: share/man/man4/vscsi.4 === RCS file: /cvs/src/share/man/man4/vscsi.4,v retrieving revision 1.13 diff -u -p -r1.13 vscsi.4 --- share/man/man4/vscsi.4

Re: md5(1): use mono clock in time trial

> On Sep 11, 2017, at 9:25 AM, Theo de Raadt <dera...@openbsd.org> wrote: > >> Scott Cheloha: >> >>> Use a monotonic clock for the elapsed time trial. >> >> FreeBSD uses getrusage() to fetch the user time used. I think that >> makes more sens

Re: cdio: read_track: plug leak

> On Sep 10, 2017, at 9:35 PM, Michael W. Bombardieri wrote: > > Patch was also posted here, but I didn't test it. > https://marc.info/?l=openbsd-tech=149784342025304=2 omg we're twins

cdio: read_track: plug leak

. Feedback? -- Scott Cheloha Index: usr.bin/cdio/rip.c === RCS file: /cvs/src/usr.bin/cdio/rip.c,v retrieving revision 1.16 diff -u -p -r1.16 rip.c --- usr.bin/cdio/rip.c 20 Aug 2015 22:32:41 - 1.16 +++ usr.bin/cdio/rip.c 10 Sep

cdio: mono clock for progress printouts in rip, write

Hi, This keeps the progress printouts from stalling in the pathological case. We were also missing for gettimeofday(2). -- Scott Cheloha Index: usr.bin/cdio/mmc.c === RCS file: /cvs/src/usr.bin/cdio/mmc.c,v retrieving revision

md5(1): use mono clock in time trial

Hi, Use a monotonic clock for the elapsed time trial. -- Scott Cheloha Index: bin/md5/md5.c === RCS file: /cvs/src/bin/md5/md5.c,v retrieving revision 1.91 diff -u -p -r1.91 md5.c --- bin/md5/md5.c 22 May 2017 16:00:47 -

Re: tftp: use monotonic clock for statistics summary

3 week bump. -- Scott Cheloha > On Aug 16, 2017, at 8:46 PM, Scott Cheloha <scottchel...@gmail.com> wrote: > > Hi, > > Same deal here as in dd(1). We display the elapsed time so we want > a monotonic clock. > > -- > Scott Cheloh

Re: mg: extract exit status from pclose return value

~2 week bump. Any thoughts or feedback? -- Scott Cheloha > On Aug 25, 2017, at 11:27 PM, Scott Cheloha <scottchel...@gmail.com> wrote: > > Hi, > > compile_mode() currently just reports the value returned by > pclose(3). This is incorrect because pclose gives you >

readlink: be quiet about overlong argument without '-f' option

as part of a larger patch that didn't make sense in aggregate. Thoughts? -- Scott Cheloha Index: usr.bin/readlink/readlink.c === RCS file: /cvs/src/usr.bin/readlink/readlink.c,v retrieving revision 1.27 diff -u -p -r1.27 readlink.c

ftp: leak in progressmeter()

(3), but the code in progressmeter() is really hairy so I think this will do for now. Anyway, title gets nullified (NULL'd?) after it is freed in the successful case, and it is non-global and static and initialized to NULL, so adding a free before we allocate it plugs the leak. Feedback? -- Scott

Re: ftp: use mono clock for transfer estimates, stats

2 week bump. -- Scott Cheloha > On Aug 19, 2017, at 9:40 AM, Scott Cheloha <scottchel...@gmail.com> wrote: > > Hi, > > Same deal here as in dd(1). We're displaying an elapsed time > so we want a monotonic clock. > > Because everything printed is

lock(1): wipe hash before exit in one-time password case

Hi, In the one-time password case we want to wipe the hash itself before exit, right? This must have slipped through when tedu@ patiently rewrote and committed my botched patch a little while back. -- Scott Cheloha P.S. I didn't botch it this time, right? Index: usr.bin/lock/lock.c

Re: time(1): perror(3) -> err(3) and friends

Few weeks bump. Any feedback on this fabulous Scott Cheloha/ingo@ collaboration? Slightly re-tweaked patch below; while here: kill(getpid(), sig) -> raise(sig) I didn't even know there was a raise(3) function until this weekend, they really did think of everything. -- Scott Chel

ftp: use mono clock for transfer estimates, stats

? -- Scott Cheloha Index: usr.bin/ftp/util.c === RCS file: /cvs/src/usr.bin/ftp/util.c,v retrieving revision 1.84 diff -u -p -r1.84 util.c --- usr.bin/ftp/util.c 21 Jan 2017 08:33:07 - 1.84 +++ usr.bin/ftp/util.c 19 Aug 2017 14:24

Re: ksh.1: two typos

> On Aug 17, 2017, at 7:47 PM, Theo Buehler <t...@theobuehler.org> wrote: > > On Fri, Aug 18, 2017 at 02:37:51AM +0200, Theo Buehler wrote: >> On Thu, Aug 17, 2017 at 07:25:14PM -0500, Scott Cheloha wrote: >>> Spotted these when customizing my prompt. >>>

Re: setvbuf.3: document possible allocation failure

3 week bump. -- Scott Cheloha > On Jul 28, 2017, at 8:33 PM, Scott Cheloha <scottchel...@gmail.com> wrote: > > Hi, > > Unlikely to happen during normal use, but setvbuf(3) can fail > to allocate your buffer: > > /* prog.c */ > #include > >

Re: setvbuf.3: allocation is not "deferred" when size is zero

3 week bump. -- Scott Cheloha > On Jul 28, 2017, at 9:26 PM, Scott Cheloha <scottchel...@gmail.com> wrote: > > Hi, > > This bit from setvbuf(3): > > The size parameter may be given as zero to obtain > deferred optimal-size buffer allocation as usual.

tftp: use monotonic clock for statistics summary

Hi, Same deal here as in dd(1). We display the elapsed time so we want a monotonic clock. -- Scott Cheloha Index: usr.bin/tftp/tftp.c === RCS file: /cvs/src/usr.bin/tftp/tftp.c,v retrieving revision 1.24 diff -u -p -r1.24 tftp.c

Re: tetris: use monotonic clock for fall timeout

1 week bump. -- Scott Cheloha > On Aug 5, 2017, at 8:25 PM, Scott Cheloha <scottchel...@gmail.com> wrote: > > Hi, > > In tetris(6) we use gettimeofday(2) to determine (roughly) how > long we polled for user input. This then gets subtracted from > the time remain

dd: use monotonic clock for summary statistics

bit of a roundabout sort of way. Feedback? -- Scott Cheloha Index: bin/dd/dd.c === RCS file: /cvs/src/bin/dd/dd.c,v retrieving revision 1.23 diff -u -p -r1.23 dd.c --- bin/dd/dd.c 9 Oct 2015 01:37:06 - 1.23 +++ bin/dd/dd.c 13 Aug 2017

tetris: use monotonic clock for fall timeout

into poll(2). I've playtested a bit and it doesn't ~feel~ any different. If anything the game *should* feel less choppy under certain conditions, though I can't really prove that. Feedback? -- Scott Cheloha Index: games/tetris/input.c

Re: mg: print default choice before colon in echo line prompts

1 week bump, any other feedback on this? -- Scott Cheloha > On Jul 30, 2017, at 2:05 AM, Florian Obser <flor...@narrans.de> wrote: > > OK florian@ > > [...]

mg: print default choice before colon in echo line prompts

that case it's meant to evoke the utility of the same name. Feedback? -- Scott Cheloha Index: usr.bin/mg/buffer.c === RCS file: /cvs/src/usr.bin/mg/buffer.c,v retrieving revision 1.103 diff -u -p -r1.103 buffer.c --- usr.bin/mg/buffe

setvbuf.3: allocation is not "deferred" when size is zero

whether it's important to mention that the allocation occurs immediately as opposed to whenever I/O is first attempted, so I've just pared the remark down. -- Scott Cheloha Index: lib/libc/stdio/setvbuf.3 === RCS file: /cvs/src/lib/libc/stdi

Re: time(1): perror(3) -> err(3) and friends

n("whatever"); return 1; is preferred over err(1, "whatever"); in main(). -- Scott Cheloha

setvbuf.3: document possible allocation failure

icular circumstances described? Or is it better to just write the standard line?, i.e. "Insufficient storage space is available." As a reader I would want to know more precisely how the interface can fail. Still seems kind of messy. Maybe my wording could be improved. -- Scott

Re: style.9: discourage (void)ing unused return values

> Date: Sat, 22 Jul 2017 15:29:17 +0200 > From: Ingo Schwarze <schwa...@usta.de> > > Hi Scott, > > Scott Cheloha wrote on Fri, Jul 21, 2017 at 05:03:11PM -0500: > >> Per encouragement from deraadt@, > > Not sure what exactly he said, but i'm quite sure y

Re: crypt_checkpass.3: mention additional failure case for crypt_newhash

> On Jul 21, 2017, at 10:24 PM, Ted Unangst <t...@tedunangst.com> wrote: > > Scott Cheloha wrote: >> crypt_newhash(3) will return -1 and set errno to EINVAL if hashsize is >> too small to accommodate bcrypt's hash space. I imagine this would >> also be the case i

crypt_checkpass.3: mention additional failure case for crypt_newhash

;, hash2, sizeof(hash2)) == -1) err(1, "crypt_newhash 2"); return 0; } Attached patch documents the case. -- Scott Cheloha Index: lib/libc/crypt/crypt_checkpass.3 === RCS file: /cvs/src/lib/libc/crypt

style.9: discourage (void)ing unused return values

the lines of, "this was mainly done to appease lint(1), but now that we don't ship lint(1) it only makes code harder to read." If so, it might fit in better down at the end of the document after the bit about not using lint-style comments. Thoughts? -- Scott Cheloha Index: share/man/ma

Re: time(1): use monotonic clock for computing elapsed time

~1 week bump. Changes to time(1) were committed by tedu@. Any feedback on the ksh/csh portions of the patch? -- Scott Cheloha

<    4   5   6   7   8   9   10   >