On Wed, 25 Oct 2023 13:38:37 +0200, Alexander Bluhm wrote:
> Since 7.4 patch(1) does not work if an explicit patchfile is given on
> command line.
>
> https://marc.info/?l=openbsd-cvs=168941770509379=2
OK millert@
- todd
On Mon, 16 Oct 2023 10:33:18 -0500, Scott Cheloha wrote:
> Per deraadt@, update EXIT STATUS, too.
Looks good to me.
> Do we need to keep the "128 + signal" bit? I thought that was a
> normal Unix thing, and we tend to avoid saying things that are
> implicitly true for every utility.
I could
On Sun, 15 Oct 2023 13:53:46 -0500, Scott Cheloha wrote:
> Align timeout(1)'s execvp(3) failure statuses with those of GNU
> timeout. 127 for ENOENT, 126 for everything else.
Looks correct to me. OK millert@
- todd
On Tue, 10 Oct 2023 10:14:10 -0700, Chris Cappuccio wrote:
> The Message-ID should be added to any message that doesn't have one.
> An existing Message-ID should not be removed or changed.
>
> The RFC says it "MAY be applied when necessary by an originating SMTP server"
> so the port numbers
On Tue, 10 Oct 2023 10:50:08 +0100, Stuart Henderson wrote:
> Presumably 465 should be treated the same, though the hardcoded ports
> don't feel entirely right here - this is presumably something that would
> want adding for any connection which is allowed to relay ..
Yes, I think so.
On Wed, 04 Oct 2023 11:53:51 -0600, Todd C. Miller wrote:
> Yes, this should be fixed. One difference is that in FreeBSD,
> __swsetup() sets errno whereas in OpenBSD we set errno in the caller
> when cantwrite() is true. I think it makes sense to set both errno
> and the __SERR flag
On Tue, 03 Oct 2023 16:09:12 -0700, enh wrote:
> looks like OpenBSD is missing this patch from FreeBSD? llvm libc++ hit
> this (a test worked on other OSes, including FreeBSD-based macOS) but
> failed on OpenBSD-based Android.
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=127335 was the
>
On Wed, 27 Sep 2023 10:59:26 -0600, "Todd C. Miller" wrote:
> I think we want support for arbitrary line lengths. There is only
> one place where we need to reallocate the line buffer.
The correct check is for "lp - line == linesz - 1". The code will
overwrite th
On Wed, 27 Sep 2023 08:37:49 -0300, Crystal Kolipe wrote:
> So what do we want?
>
> 1. Traditional OpenBSD behaviour of breaking input lines at 2047,
>(which never actually worked correctly up to now).
> 2. Breaking input at 2048.
> 3. Support for arbitrary line length with no breaking.
>
>
On Sun, 24 Sep 2023 09:58:53 +0200, Otto Moerbeek wrote:
> The wayland issue was found as well, using the same method.
> I'm working on programming the heuristic that is quite effective into
> malloc itself. It currently looks like this for the X case above:
>
> X(67417) in malloc(): write to
On Tue, 12 Sep 2023 07:49:27 +0200, Theo Buehler wrote:
> While this looks like an improvement to me, this uses a new non-portable
> construct in ksh. I don't know how much we care.
I don't think we care. If someone wants to ports our ksh it
is easy enough to supply TIMEVAL_TO_TIMESPEC if
On Mon, 11 Sep 2023 22:10:49 -0500, Scott Cheloha wrote:
> p_tv() is identical to p_ts() in every way except for the subsecond
> conversion constants.
>
> Better to write p_ts() once: in p_tv(), convert from timeval to
> timespec and call p_ts().
OK millert@
- todd
On Wed, 06 Sep 2023 10:43:34 +1000, Jonathan Gray wrote:
> tb updated us to the newer version a while ago
OK millert@
- todd
On Mon, 04 Sep 2023 13:54:18 +0100, Jeremie Courreges-Anglas wrote:
> Two code sets are currently guarded with #ifdef SMALL in pax(1) and
> tar(1): reading 'pax' format extended headers, and identifying various
> compressed formats for user-friendliness. As noted by Caspar, the SMALL
> path
On Wed, 23 Aug 2023 18:23:40 -0700, Andrew Hewus Fresh wrote:
> I would have to see an example of doing that between ksh and perl.
Standard output should already be a pipe in the perl process by
virtue of running as a co-process. In theory you should be able
to poll on it checking for POLLHUP.
On Tue, 22 Aug 2023 19:55:56 -0700, Andrew Hewus Fresh wrote:
> I noticed this when testing how signal handling worked in fw_update, it
> turns out that if you `pkill -KILL -f fw_update` it may leave behind a perl
> process that is locking the package database. Instead of just waiting
> to be
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 Wed, 19 Jul 2023 16:44:23 +0100, Stuart Henderson wrote:
> When /etc/crontab is used, cron only skips over a single whitespace
> character between the username and -n/-s/-q flags; more than one and
> the flag is taken as part of the command:
>
> printf '*\t*\t*\t*\t*\tnobody\t-n true 1\n' |
On Wed, 28 Jun 2023 18:37:43 +0200, Omar Polo wrote:
> since fetch.c revision 1.211 ("strip spaces at end of header lines and
> in chunked encoding headers") ftp removes trailing whitespaces early
> so we don't need to re-do that upon every header we parse.
>
> it can also be misleading since one
If the mtime in the file header is larger than MAX_TIME_T, trucate
it to MAX_TIME_T, not INT_MAX. The existing assignment dates from
before we had a MAX_TIME_T definition in pax.
OK?
- todd
Index: cpio.c
===
RCS file:
On Mon, 26 Jun 2023 17:24:38 +0200, Paul de Weerd wrote:
> Having never heard of posix_spawn(3), I read the full manpage and
> (besides wondering "what's the point"), found that it's misspelled Ed
> Schouten's name:
Yes, that should be fixed.
- todd
Other implementations of "time -p" (both builtin and standalone)
only display two digits after the radix point. I'm a little concerned
about breaking scripts that consume out the output of "time -p".
Changing the precission of the non-portable output format is fine.
- todd
On Fri, 23 Jun 2023 11:58:47 +0200, Omar Polo wrote:
> another diff from the -portable repo:
>
> https://github.com/OpenSMTPD/OpenSMTPD/pull/1150
>
> per rfc-5321 ยง 4.1.1.9 the NOOP command allows optionally one argument
> that we SHOULD ignore.
>
> The original diff set the check function
On Tue, 07 Feb 2023 20:35:10 -0700, Todd C. Miller wrote:
> On Tue, 07 Feb 2023 17:17:02 -0700, Todd C. Miller wrote:
>
> > Yes, the bug is that the number is not displayed. The following
> > diff fixes that but there is still a bug because the resulting line
> >
On Wed, 21 Jun 2023 19:11:09 +0200, Omar Polo wrote:
> On 2023/06/20 14:38:37 -0600, Todd C. Miller wrote:
> > > qid = ep+1;
> > > - if ((ep = strchr(qid, '|')) == NULL)
> > > - fatalx("Missing reqid: %s", line);
> > > - ep[0] = '\0';
On Tue, 20 Jun 2023 21:38:49 +0200, Omar Polo wrote:
> Then I realized that we don't need to copy the line at all. We're
> already using strtoull to parse the number and the payload is the last
> field of the received line, so we can just advance the pointer. The
> drawback is that we now need
On Tue, 20 Jun 2023 17:49:46 +0200, Claudio Jeker wrote:
> In open_memstream() the code does a bzero() of the new memory even though
> recallocarray() used which does this already.
>
> In open_wmemstream() the code does the same but is still using
> reallocarray(). So adjust that code to be like
On Sun, 18 Jun 2023 16:49:30 +0200, Omar Polo wrote:
> some imsg types are missing from the big switch in imsg_to_str(),
> noticed after a report in m...@opensmtpd.org. Tracing shows:
>
> : imsg: lka <- dispatcher: IMSG_??? (139) (len=42)
>
> (imsg #139 should be IMSG_REPORT_SMTP_FILTER_RESPONSE
On Wed, 14 Jun 2023 16:34:39 +0200, Omar Polo wrote:
> the `link-auth' event hash the user first and the result of the
> operation after; this breaks when a username has a '|' character in
> it. Since this is triggered by the `auth login' command, anyone could
> send a user with a '|' and,
On Mon, 12 Jun 2023 18:48:56 +0100, Stuart Henderson wrote:
> Neither of these are really ideal, and mean that we still need gseq
> for integers >= 1,000,000
>
> $ seq 99 99
> 99
> $ seq 100 100
> 1e+06
>
> $ gseq 105 105
> 105
That probably requires a separate
For context, see:
https://chaos.social/@Gottox/110527807405964874
https://github.com/chimera-linux/chimerautils/commit/1ecc1e99d4a309631e846a868b5a422f996704ac
We need to compare the printable version of the last value displayed,
not the floating point representation. Otherwise, we may print the
last value twice.
Old:
$ seq 105 105
1.05e+06
1.05e+06
New:
$ seq 105 105
1.05e+06
We really need seq regression tests.
On Fri, 09 Jun 2023 07:25:04 +0200, Florian Obser wrote:
> OK?
>
> p.s. I'm currently busy writing an ISC licensed bash in rust to safely
> support HiCA. So this might take a while...
Have you considered implementing wordexp(3) to allow command
substitution? It may be necessary to add inline
On Sat, 03 Jun 2023 11:55:46 +0200, Omar Polo wrote:
> As per subject. While here I couldn't resist simplifying the "From "
> check too, although it is indipendent from the rest of the diff.
> (could commit separately if preferred.)
OK millert@
- todd
On Wed, 31 May 2023 11:00:37 +0200, Omar Polo wrote:
> After a report of a build fail with some old gcc on RHEL7 / Centos, I
> noticed that we're lacking the include time.h for time(3),
> clock_gettime(3) and localtime(3). Diff below adds it in all the
> missing files. I'm also including
I just checked and it seems that while zsh supports the pre-POSIX
behavior of "test -t" using fd 1, both dash and bash treat "-t" as
a string by default when there is no fd specified. So I think this
change is fine.
OK millert@ for your revised dif if you add the missing ';' after
the "return
On Tue, 30 May 2023 09:47:08 +0200, Omar Polo wrote:
> fwiw I agree. Although it doesn't makes much sense to pass an
> argument to id -R, not failing may give the wrong impression.
>
> ok op@ (i'll wait a bit before commiting this in case someone
> disagrees)
OK millert@ as well if you want to
On Thu, 25 May 2023 06:54:08 +0100, Stuart Henderson wrote:
> > As Aisha pointed out, pkg_delete hints could be updated too.
>
> If that is done, pkg_delete would need to check whether the group will
> actually get removed i.e. make sure that no other user has been added
> to the group.
If
On Tue, 23 May 2023 23:41:32 +0200, Christian Weisgerber wrote:
> This replaces "$(cat file)" with the ksh construct "$( Admittedly cosmetic.
>
> I have left the line
>
> local _sec=$(cat $HTTP_SEC 2>/dev/null)
>
> unchanged, since it would require
>
> { local var=$(<$HTTP_SEC); }
On Wed, 24 May 2023 16:04:13 +0200, Omar Polo wrote:
> It makes `man -k any=S_ISVTX' slightly more useful by pointing at
> sticky(8) too other than strmode(3); may help if someone (like me :-)
> forgot about sticky(8) files.
OK millert@
- todd
On Tue, 23 May 2023 22:22:04 -, Klemens Nanni wrote:
> I'm pointing this out because the error message we'd get provides less
> information with your diff:
>
> $ echo $(cat /nope) 2>/dev/null
> cat: /nope: No such file or directory
> vs.
> echo $(< /nope) 2>/dev/null
>
On Fri, 19 May 2023 12:52:30 -0400, A Tammy wrote:
> Will this not potentially break people's setups? I like this change though.
I hope not. The group would only be removed if it matches the user
name and ID and there are no other members.
> This would also make the post pkg_delete output
If /etc/usermgmt.conf has a line like:
group =uid
where a new user's group ID in the passwd file is the same as their
user ID, remove that group when the user is removed. The group is
only removed if it matches the login name, has a gid that matches
the user's uid, and has no other
On Fri, 19 May 2023 13:06:32 +0200, Omar Polo wrote:
> it's currently rendered as
>
> maildir [pathname [junk]]
>
> whereas it really is
>
> maildir [pathname] [junk]
>
> i.e. both the path and `junk' are optional but indipendently so. it's
> quite clear from the grammar in parse.y.
On Thu, 18 May 2023 18:13:57 +0200, Omar Polo wrote:
> existing code just used 0 and 1 (e.g. creategid.) lone zeros as
> arguments are not really readable, but still I can't make myself
> liking stdbool. not that my tastes matters, but it seems to be used
> very sparsingly in usr.sbin
This was
The way user(8) runs commands via system(3) is fragile. It does
not correctly handle paths with whitespace or shell metacharacters.
Rather than try to quote everything (which is also fragile) I think
it is safest to just exec the commands directly.
OK?
- todd
Index: usr.sbin/user/user.c
On Tue, 16 May 2023 19:26:07 +0200, Alexander Bluhm wrote:
> On Tue, May 16, 2023 at 11:15:31AM -0600, Todd C. Miller wrote:
> > Would it be possible to move the forward declaration of struct tdb
> > to netinet/tcp_var.h so it is not required in every driver?
>
> sure
Than
We can just use "cp -a skeldir/. homedir" to copy the skeleton dot
files to the new user's homedir. There's no good reason to use pax
when cp will do and this will simplify a future commit of mine.
- todd
Index: usr.sbin/user/user.c
On Tue, 16 May 2023 14:51:44 +0200, Omar Polo wrote:
> while debugging a pebkac in -portable, I noticed that in various
> places we use fatal() for libtls failures. errno doesn't generally
> contains anything useful after libtls functions, and in most it's
> explicitly cleared to avoid misuse.
>
All the callers of memsave() pass strlen(s) as the size argument.
We can eliminate the size argument and just use strdup(3) instead.
OK?
- todd
Index: user.c
===
RCS file: /cvs/src/usr.sbin/user/user.c,v
retrieving revision 1.128
On Mon, 15 May 2023 13:54:35 +0200, Omar Polo wrote:
> almost always (cast)var. I've adjusted the spacing in the line I was
> touching, grepping for common types I could only find one instance of
> a '(long long) src' in envelope.c which I'm not addressing here.
OK millert@. It would be nice
On Wed, 10 May 2023 20:55:24 +0200, Jan Klemkow wrote:
> For tcprecvoffload and ix(4) it's not possible to enable/disable it per
> address family. Its just one flag for the hardware.
>
> For tcpsendoffload its possible, but I won't do that till its necessary.
>
> Why would you want to
The sigsuspend(2) man page doesn't spell out explicitly what happens
for signals that are discarded, either as the default action or
where the handler is set to SIG_IGN. I think it should.
OK?
- todd
Index: lib/libc/sys/sigsuspend.2
On Wed, 10 May 2023 19:03:58 +0200, Jan Klemkow wrote:
> This diff introduces separate flags for TCP offloading. We split this
> into LRO (large receive offloading) and TSO (TCP segmentation
> offloading). Thus, we are able to turn it on/off separately.
>
> For ifconfig(8) we use
On Wed, 10 May 2023 09:25:43 +0200, Omar Polo wrote:
> I forgot to include one off_t cast since it was in a different
> directory and -even if off topic because it's not in portable- instead
> of "const"-ify only tz why don't mark as const also the two arrays day
> and month?
Sure. OK millert@
On Wed, 10 May 2023 00:55:54 +0200, Omar Polo wrote:
> As per subject, here's a few misc nits that would reduce the
> difference with -portable. There's some printing of time_t via
> casting to long long, some missing includes (even if in tree it builds
> nevertheless) and a const for a variable
On Tue, 09 May 2023 21:45:30 +0200, Theo Buehler wrote:
> Some expressed concern that it should be done the other way around,
> i.e., leave the default at letsencrypt. Perhaps it's indeed better
> this way to avoid creating servers with bad certs.
OK millert@ for this version
- todd
On Mon, 08 May 2023 16:17:51 -, Tobias Stoeckmann wrote:
> Turns out that we have yet another possibility to trigger a theoretical
> signed integer overflow if pwd_tries is INT_MAX. This one avoids such
> situation as well.
OK millert@
- todd
Now that the random range changes are committed I would like to
revisit this diff.
This fixes two issues with the parsing of random values:
1) Garbage after a random value is now detected. This fixes a bug
in the random range parsing that handles the optional final
number. For example:
There appears to be a strong preference for a syntax like "~/10"
instead of "*/~10". The following diff implements that instead and
also supports random ranges like "1~58/10". When a high and/or low
value is used with a random range, the initial offset is a random
value less than eiter the step
On Fri, 05 May 2023 17:05:05 -, Tobias Stoeckmann wrote:
> On Fri, May 05, 2023 at 11:00:12AM -0600, Todd C. Miller wrote:
> > This looks OK but I'd like to see an error message if waitpid()
> > really does fail. How about something like this, which also avoid
> > needi
On Fri, 05 May 2023 16:46:51 -, Tobias Stoeckmann wrote:
> In getnewpasswd we increment "tries" every time we try to enter a new
> password. The code allows this to be repeated endlessly by defining
> passwordtries to be 0 in /etc/login.conf. But unfortunately we even
> increment the int
On Fri, 05 May 2023 16:13:01 +1000, Mark Jamsek wrote:
> I found kn's attempted syntax intuitive though; it feels like a natural
> extension of the existing random and step syntax. I also assumed ~/15
> would run every 15 minutes starting with a random minute, and since
> discovering it didn't
On Thu, 04 May 2023 21:41:26 -, Klemens Nanni wrote:
> On Thu, May 04, 2023 at 03:30:30PM -0600, Todd C. Miller wrote:
> > This fixes two issues with the parsing of random values:
> >
> > 1) A random value with a step is now rejected. For example:
> >
> >
This fixes two issues with the parsing of random values:
1) A random value with a step is now rejected. For example:
~/10* * * * echo invalid
0~59/10 * * * * echo invalid
10~/10 * * * * echo invalid
~40/10 * * * * echo invalid
Previously, the '/' would just be
Fix a bug introduced in rev 1.86 (fchown removal). Currently, if
the second seteuid(2) were to fail (not really possible) we would
leave a temporary file in the spool dir. This will be ignored by
cron but we still want to clean it up.
- todd
Index: usr.sbin/cron/crontab.c
On Thu, 04 May 2023 07:32:18 -0700, Navan Carson wrote:
> Any chance the syntax could be:
>
> ~/20 * * * * command
>
> To align with how ~ is used currently.
That is already a valid syntax, though not a terribly useful one.
It currently results in a random number with a step of 20.
- todd
Crontab supports things like "*/20" in the minutes column to run
every 20 minutes. For example, given:
*/20 * * * * echo I am right on time
The job above would run at 0, 20, and 40 minutes of every hours.
job@ asked whether we could support a random offset so that jobs
would not always start
On Tue, 02 May 2023 14:13:27 +0200, Claudio Jeker wrote:
> Add a json_do_string() a function to print a JSON string.
> This function does the needed encoding of control chars and escape chars.
> I skipped the optional encoding of the forward slash (/) since this is
> only needed if the json
On Thu, 20 Apr 2023 19:40:49 +0200, Christopher Zimmermann wrote:
> delivery success DSNs include the message body if not explicitely
> disabled by RET HDRS.
> But according to rfc3461 4.3 the body should _only_ be included for
> failure DSNs.
>
> To me it seems more sane to not include the
I recently ran into a problem with busybox tar generating archives
where the size field is base-256 encoded for files larger than 8GB.
Apparently this is a GNU tar extension.
Do we want to support this in pax? Below is an initial diff that
at least produces the correct results when listing the
On Wed, 12 Apr 2023 23:27:08 +0200, Stefan Sperling wrote:
> The iwm_updatechan and iwx_updatechan callbacks are not reachable
> because they were never wired up. Only the iwn driver already has
> this callback pointer set as intended.
>
> With the patch below iwm/iwx should get triggered when an
On Sat, 08 Apr 2023 08:48:31 -0600, "Theo de Raadt" wrote:
> Mark Kettenis wrote:
>
> > > +{
> > > + int len;
> > > +
> > > + len = OF_getprop(handle, prop, buf, buflen);
> > > + if (buflen > 0)
> > > + buf[min(len, buflen - 1)] = '\0';
> > > +
> > > + return (len);
> >
>
> I've mailed
On Thu, 30 Mar 2023 17:26:17 +0200, Omar Polo wrote:
> noticed because it renders oddly:
>
>kill %job
>kill[-s signal_name] pid
>kill -sig pid ...
>
> The Op on its own line becomes part of the item body instead of the
> item itself. Use an in-line Oo ...
On Tue, 28 Mar 2023 16:19:42 +0200, Omar Polo wrote:
> sigh... forgot to advance the pointer after strrchr otherwise argv[0]
> would have been /ksh instead of "ksh".
OK millert@ for this version.
- todd
On Mon, 27 Mar 2023 20:06:30 +0200, Omar Polo wrote:
> Is _PATH_BSHELL portable though? I can see a few stuff that uses it
> (vi among others) but I'm not sure.
The paths.h header is a BSD invention, though it may be present on
some other systems. I don't think that's a reason not to use it
On Sat, 25 Mar 2023 20:13:35 +0100, Otto Moerbeek wrote:
> Last arg also is a pointer, so pass NULL.
Looks like it's been that way since the initial CSRG commit.
OK millert@
- todd
The current code for extracting the token name from %{name} can be
simplified by computing the token name length. The existing code
copies "name}" to token[] using memcpy(), then strchr() to find the
'}' and replace it with a NUL. Using strchr() here is fragile since
token[] is not yet
On Thu, 16 Mar 2023 18:52:23 +0100, Alexander Bluhm wrote:
> When syslogd is sending messages per UDP, it stops if there is a
> permanent error. It has a list of transient errors.
>
> Since OpenBSD 6.5 pf has changed its error code to EACCES. If pf
> blocks your outgoing syslog packets and your
On Wed, 08 Mar 2023 09:02:08 -0600, joshua stein wrote:
> In the non-fail case, done is set to NULL and then free()d.
> free(NULL) is legal but maybe worth removing?
Please leave this as-is. I don't think it is worth appeasing
cppcheck in this case.
> diff --git usr.bin/ssh/scp.c
On Wed, 08 Mar 2023 01:37:18 +0100, Tobias Heider wrote:
> It look like this was broken in 1.83 which introduces print_comm_name() but
> wrongly assumes the returned value is the length difference when it actually
> is the updated length value. With this fixed I get a correctly aligned output
OK
On Thu, 02 Mar 2023 07:25:17 +, Klemens Nanni wrote:
> The TERM handler also just sets a flag today, but etc/rc.d/mountd still
> has `rc_stop=NO' since 2013
>
> Do not allow stopping/restarting mountd using the rc.d(8) framework;
> if there is need to send a SIGTERM to mountd(8), it
The SIGHUP handler only sets a flag these days, there is no longer
any need to block it while using the exports list.
OK?
- todd
Index: sbin/mountd/mountd.c
===
RCS file: /cvs/src/sbin/mountd/mountd.c,v
retrieving revision 1.90
On Wed, 22 Feb 2023 17:11:47 +0100, Moritz Buhl wrote:
> The tool finds a path to ex_search where fsb.f_fsid is uninitialized.
>
> ex_search compares the potentially uninitialized stack data:
>
> ex_search(fsid_t *fsid)
> {
> struct exportlist *ep;
>
> ep = exphead;
> while (ep)
On Wed, 15 Feb 2023 09:03:55 -0700, "Todd C. Miller" wrote:
> It should not be removing .shstrtab. What happens if you tell
> llvm-strip to preserve .shstrtab? E.g. --keep-section .shstrtab?
Nevermind, I misread the readelf output, the stripped binary does
actually have .shstrtab.
- todd
It should not be removing .shstrtab. What happens if you tell
llvm-strip to preserve .shstrtab? E.g. --keep-section .shstrtab?
- todd
On Tue, 14 Feb 2023 17:47:00 -0800, Andrew Hewus Fresh wrote:
> With the perl update, we get a new version of unicode available to
> update this file as well. This was just running the script with the new
> perl version.
OK millert@
- todd
On Sun, 05 Feb 2023 10:43:58 -0500, aisha wrote:
> The auth_getchallenge function doesn't seem to exist in the code base.
> OK to remove this reference?
Yes, that should be removed. OK millert@
- todd
Unfortunately we cannot use strtonum(3) here since there may be
non-digit characters following the number. So, strtoll(3)
it is then.
- todd
Index: lib/libc/time/strptime.c
===
RCS file: /cvs/src/lib/libc/time/strptime.c,v
On Thu, 26 Jan 2023 10:29:36 -0800, enh wrote:
> yeah, but that's the copy & paste-o, no? (apologies if it's just too early
> for me to be looking at code yet...)
>
> doesn't this need to be int64_t?
>
> int result = 0;
Yes, it does, thanks.
>
On Thu, 26 Jan 2023 09:36:52 -0800, enh wrote:
> it's quite possible that this could use _conv_num64(), but it wasn't
> obvious to me that that function's correct? (i haven't thought too hard
> about the overflow logic, but just the fact that result is an `int` seems
> odd?)
It just returns a
Is there a reason you didn't just change the gmtime_r() in the 's'
case to localtime_r()? That seems like the simplest fix. Using
strtol() for what may be a 64-bit value on an 32-bit system looks
wrong.
- todd
On Fri, 20 Jan 2023 11:29:15 -0700, "Theo de Raadt" wrote:
> During this mimmmutable and xonly work, I keep finding test machines where
> I enabled kern.allowkmem, and have to disable it. Sometimes weeks later.
> Both kern.allowkmem and securelevel disabling are dangerous, especially in
> our
On Fri, 20 Jan 2023 09:32:38 -0700, Bob Beck wrote:
> So isdigit(3) says in the first paragraph that
>
> 'The complete list of decimal digits is 0 and 1-9, in any locale.'
>
> Later on it says:
>
> 'On systems supporting non-ASCII single-byte character encodings,
> different c arguments may
On Wed, 04 Jan 2023 13:13:28 -0800, Nathan Houghton wrote:
> This patch removes a few remnants of the unsupported diff -l
> option from diff.c and the diff manual page.
>
> The diff.c usage() print is already correct, so no changes are
> needed there.
Thanks, committed.
- todd
On Mon, 29 Aug 2022 13:51:13 +0200, =?utf-8?B?0L3QsNCx?= wrote:
> In that case, how about this scissor-patch?
> It has the added benefit of removing the existing floating-point usage.
That version looks good to me, committed.
- todd
Updated version. I kept "The BLOCKSIZE environment variable" in
the -P description since it is the first time the man page metions
BLOCKSIZE.
- todd
Index: bin/df/df.1
===
RCS file: /cvs/src/bin/df/df.1,v
retrieving revision 1.48
On Sat, 31 Dec 2022 19:05:20 +0100, Mark Kettenis wrote:
> Bad idea. The setitimer(2) interface is marked as "OB XSI" in POSIX,
> which means that it is considerent "Obsolescent" and may be removed in
> a future version of POSIX. Since we want ssh to be as portable as
> possible we shouldn't
In POSIX mode, df(1) does not honor the BLOCKSIZE environment
variable.
Any comments on the wording?
- todd
Index: bin/df/df.1
===
RCS file: /cvs/src/bin/df/df.1,v
retrieving revision 1.48
diff -u -p -u -r1.48 df.1
--- bin/df/df.1
On Sat, 31 Dec 2022 10:33:26 -0500, Scott Cheloha wrote:
> The progress meter in scp(1) and sftp(1) updates periodically, once
> per second. But using alarm(3) to repeatedly rearm the signal causes
> that update period to drift forward:
OK millert@
- todd
1 - 100 of 1493 matches
Mail list logo
