On Tue, 19 Apr 2022 11:43:35 +0200, Martin Vahlensieck wrote:
> Neither openssl/evp.h nor openssl/hmac.h are required.
Right.
- todd
On Tue, 19 Apr 2022 11:42:52 +0200, Martin Vahlensieck wrote:
> malloc(3) and friends require stdlib.h, SIZE_MAX requires stdint.h.
You are correct. The other xmss files get these includes via
xmss_commons.h, but ssh-xmss.c does not.
- todd
On Tue, 19 Apr 2022 11:41:10 +0200, Martin Vahlensieck wrote:
> There is no need to duplicate options->send_env[i] only free it
> in all cases. Just use options->send_env[i] directly.
Good catch, match_pattern() takes const char * arguments so
there is no danger there.
- todd
On Fri, 15 Apr 2022 13:28:33 -0500, joshua stein wrote:
> Anyone want to bikeshed this language?
I think it is more helpful to refer to glob(7) than glob(3).
Perhaps something like this.
- todd
Index: share/man/man5/fbtab.5
===
On Fri, 15 Apr 2022 13:12:03 -0500, joshua stein wrote:
> Thanks, both applied.
Looks good to me but needs a man page update.
- todd
On Thu, 14 Apr 2022 17:52:37 -0500, joshua stein wrote:
> login_fbtab(3) supports wildcards but only for every file in a
> directory (/path/*).
>
> This makes it use glob(3) so it can also support more specific
> wildcards like /path/file*
Yes, it is better to use glob(3) than something
On Sun, 10 Apr 2022 13:24:15 +0200, Jeremie Courreges-Anglas wrote:
> The diff below keeps the same output by default and outputs the same as
> GNU gzip(1) is -k is given.
OK millert@
- todd
On Sun, 27 Mar 2022 15:05:00 +0200, Sebastien Marie wrote:
> The following diff removes vnode_hold_list, vnode_free_list extern references
> ,
> and `struct freelst` definition from sys/vnode.h
>
> `struct freelst` definition (TAILQ_HEAD) is moved where used, inside vfs_subr
> .c.
OK millert@
On Wed, 23 Mar 2022 16:59:06 +0100, Otto Moerbeek wrote:
> This is a bug that dlg reported last week. Serendepity or not? :-)
>
> This is my diff that uses an approach I like a litle bit better.
Since client_peer_init() is always called after new_peer() there's
no reason I can see for query to
On Wed, 23 Mar 2022 15:53:21 +0100, Alexander Bluhm wrote:
> Hi,
> is a big switch and when looking at a break you need more context
> to see where it jumps to.
>
> I would like to use goto fail consistently to leave the big switch.
> break is used for inner switches and loops.
This makes it
I think it makes sense to accept LOGIN_SETRTABLE for setclasscontext(3)
as well. Currently, it will be cleared out of the flags.
- todd
Index: lib/libc/gen/login_cap.3
===
RCS file: /cvs/src/lib/libc/gen/login_cap.3,v
retrieving
On Sun, 13 Mar 2022 12:02:03 -0500, Matthew Martin wrote:
> Ignoring -L which already honors rtable, su has three cases:
> -l (asme=0 asthem=1)
> -m (asme=1 asthem=0)
>(asme=0 asthem=0)
>
> -l should honor rtable; I am not sure about the other two. I think the
> least suprising would be
On Sun, 13 Mar 2022 13:26:13 +0100, Jeremie Courreges-Anglas wrote:
> Works fine. Here's an updated diff with suggestions:
> - "k" was not completely removed from compress's struct compressor opt
> string, and was not needed in null_method
> - try to keep the *flag variables ordered
> - rework
On Wed, 09 Mar 2022 19:20:08 -0600, Scott Cheloha wrote:
> The strdup(3) implementation in libc uses memcpy(3), not strlcpy(3).
>
> There is no upside to using strlcpy(3) here if we know the length of
> str before we copy it to the destination buffer.
Sure, using memcpy() here is fine since the
On Sun, 06 Mar 2022 02:58:30 +0100, Jeremie Courreges-Anglas wrote:
> I'm not sure what you mean here. Solene's diff added -k to both
> compress(1) and gzip(1) (and their uncompressor counterparts).
> Adding -k to gzip/gunzip only would indeed make the usage() slightly
> more complicated.
>
> So
On Thu, 03 Mar 2022 15:11:13 +, Miod Vallat wrote:
> > I think this makes sense if only for better GNU gzip compatibility.
> > OK millert@
>
> But does the `-k' flag needs to be added to compress(1) too?
No, it just makes usage() slightly more complicated.
But that diff was missing an update
On Thu, 03 Mar 2022 13:13:16 +0100, Solene Rapenne wrote:
> The following diff adds support for -k flag to keep the input file for
> gzip / compress when compressing, and the input file (the compressed
> one) for gunzip / uncompress
>
> This will improve uses cases like: zcat -f "${file}" >
On Wed, 02 Mar 2022 19:26:46 +0100, Theo Buehler wrote:
> I think it's easier to use a single snprintf call. Also drop a few
> unnecessary parentheses.
Seems like an improvement. OK millert@
- todd
On Sat, 26 Feb 2022 11:16:44 -0600, Matthew Martin wrote:
> Anton spotted a doas regression failure in t-run-keepenv-path after the
> change to doas for LOGIN_SETALL. Since that test runs doas in a chroot
> and the setup does not create a login.conf, login_getclass in
> login_cap.c will return a
On Wed, 23 Feb 2022 00:04:07 +0100, Theo Buehler wrote:
> Hard to hit. Nevertheless it seems better to error out than to
> crash in strcmp()
Sure. OK millert@
- todd
On Sun, 13 Feb 2022 12:07:31 -0800, Greg Steuck wrote:
> I noticed that despite the OKs the code didn't submitted. Should we
> revive this diff now and continue in the tree?
>
> I have vested interest: I don't want to fix up lang/ghc test suite which
> is full of seq(1).
Here's an updated diff
On Tue, 15 Feb 2022 20:18:45 +0100, Florian Obser wrote:
> Also fixes a whitespace issue while here.
>
> if (dho_len < 1)
> goto wrong_length;
>
> is redundant now, but I want to keep the pattern of checking the length
> right after identifying the option.
Right, makes sense.
On Tue, 15 Feb 2022 20:01:52 +0100, Florian Obser wrote:
I think you need that to be:
/* MUST delete trailing NUL, per RFC 2132 */
slen = dho_len;
while (slen > 0 && p[slen - 1] == '\0')
slen--;
to avoid underflow if the string happens to consist entirely
On Fri, 11 Feb 2022 08:21:38 +0100, alf wrote:
> there seem to be some superfluous words in
> lib/libc/gen/statvfs.3 and sys/sys/statvfs.h .
> "(unit f_frsize)" can be removed since in the man page
> it is explicitely mentioned directly below:
> " The fields of type fsblkcnt_t are reported in
On Thu, 10 Feb 2022 09:13:25 +0100, Theo Buehler wrote:
> This is purely cosmetic. I did some testing on fedora which ships with
> btrfs by default. btrfs is special in that df -i and other tools always
> report 0 inodes. As a consequence, each rpki-client run prints the disk
> space warning,
On Wed, 09 Feb 2022 11:35:58 +0100, Theo Buehler wrote:
> On clang we can use __has_feature(), but that doesn't exist on
> gcc which defines __SANITIZE_ADDRESS__ if it compiles with
> -fsanitize=address.
>
> This doesn't warn on sparc64 and works in my test setups.
It's a little ugly but since
On Tue, 08 Feb 2022 19:37:26 -0600, Scott Cheloha wrote:
> - pledge(2) initially with "stdio rpath" at the top of main().
> We know we need to read a file at this point but don't yet
> know which one.
>
> - pledge(2) down to "stdio" after we have opened the file
> in question and called
On Tue, 08 Feb 2022 10:40:00 -0600, Scott Cheloha wrote:
> We don't need "rpath" if we're only processing the standard input.
Sure. OK millert@
- todd
On Sun, 06 Feb 2022 23:41:26 -0600, Scott Cheloha wrote:
> > On Feb 6, 2022, at 20:07, Todd C. Miller wrote:
> >
> > Since the input is opened read-only I don't see the point in checking
> > the fclose() return value. However, if you are going to do so, you
&
Since the input is opened read-only I don't see the point in checking
the fclose() return value. However, if you are going to do so, you
might as well combine it with the ferror() check. E.g.
if (ferror(fp) || fclose(fp) == EOF) {
warn("%s", name);
status
On Sat, 05 Feb 2022 14:38:14 +0100, Christian Weisgerber wrote:
> Anybody?
> The commit history of ypldap does not suggest a single responsible
> person I could pin down.
OK millert@
- todd
On Sat, 05 Feb 2022 23:06:32 +1100, Jonathan Gray wrote:
> drop please from manual pages excluding third party parts of tree
> suggested by multiple documentation style guides
OK millert@
- todd
On Fri, 04 Feb 2022 20:46:48 -0800, Greg Steuck wrote:
> How do people feel about shipping the minimal UBSan runtime library[1]
> in the base system? It takes very little to build (Makefile + a few
> ifdefs that both jca@ and I hacked together). The library is tiny and
> useful enough for finding
On Tue, 01 Feb 2022 17:00:29 -0700, "Theo de Raadt" wrote:
> I don't see a problem with explaining what a program does in simple,
> clear english.
Agreed.
- todd
On Tue, 01 Feb 2022 09:59:51 -0600, Scott Cheloha wrote:
> To recap:
>
> - Refactor the open/close portions of cook_args() and raw_args() into a
>single function, cat_file().
>
> - Push the flag-check branch in main() down into cat_file().
>
> - Pull the argv loop in cat_file() up into
On Fri, 28 Jan 2022 09:37:33 -0600, Scott Cheloha wrote:
> Alright, you have both convinced me.
>
> We'll go with this patch?
Sure. OK millert@
- todd
On Thu, 27 Jan 2022 20:02:18 -0800, Philip Guenther wrote:
> > I think futimens(2) and close(2) failures are exotic enough to warrant
> > printing the system call name.
> >
>
> I don't understand this. Can you give an example of an error message that
> touch currently might emit where knowing
On Thu, 27 Jan 2022 08:52:52 -0600, Scott Cheloha wrote:
> Just like with head(1), rev(1)'s main loop is obfuscated.
>
> This patch moves the open/read/write/close portion of the main loop
> out of main() into a separate function, rev_file(). "multibyte"
> becomes a global.
OK millert@
- todd
On Wed, 26 Jan 2022 22:50:27 -0600, Scott Cheloha wrote:
> The main loop in head(1) is obfuscated. In particular, the path
> through the loop to exit(3) is extremely clever. Clever in a bad way.
>
> This patch moves the open/read/write/close portions of the loop out
> into a separate function,
On Sat, 22 Jan 2022 14:24:17 +0100, =?UTF-8?Q?S=C3=B6ren?= Tempel wrote:
> The patch below fixes this issue by flushing all open output streams
> before executing the command using system(3). Alternatively, it may also
> be sufficient to only flush stdout and (maybe) stderr.
Just flushing
On Thu, 20 Jan 2022 15:04:07 +0100, Alexander Bluhm wrote:
> snprintf(9) allows NULL pointer if size is 0. But doing NULL pointer
> arithmetic is undefined behavior. Check that size is positive
> before doing that. While the use NUL char for string termination.
>
> Pfkey import_flow() must do
On Fri, 14 Jan 2022 14:53:21 +, Visa Hankala wrote:
> I think the tool is useful. However, installing it from ports is good
> enough for me.
Same here.
- todd
On Tue, 11 Jan 2022 13:10:49 +0100, Theo Buehler wrote:
> This is completely mechanical, but a second set of eyes won't hurt.
>
> It won't build on -current since the API will only be exposed in the
> next bump.
Conversion looks correct. OK millert@
- todd
On Mon, 10 Jan 2022 16:02:31 +, Visa Hankala wrote:
> This removes a dead store to variable `f' from libsa's readdir(),
> which also avoids suspicious use of `fd' without validation.
OK millert@
- todd
OK millert@
- todd
On Mon, 10 Jan 2022 15:23:42 +0100, Martijn van Duren wrote:
> The lputs case is fairly straight forward and I'd like to get an OK
> for that part.
I agree that fixing lputs() to honor psl is the best approach.
Wouldn't the diff be simpler if you left the handling of 's' as-is
but make the loop
On Sat, 08 Jan 2022 08:30:20 +0100, Martijn van Duren wrote:
> Why not go for the following diff?
> It has a comparable speed increase, but without the added complexity of
> a second inner loop.
Personally, that is what I would have done as well, but I am OK
with either direction.
- todd
On Fri, 07 Jan 2022 15:00:52 -0600, Scott Cheloha wrote:
> Updated: make the for-loop update expressions match.
Looks good to me. OK millert@
- todd
On Fri, 07 Jan 2022 09:29:01 -0800, Greg Steuck wrote:
> Ah, so it's our ksh after all. Unless there's a good reason for it to be
> different, should we change it to match the rest of the pack behavior?
Probably, it is just not the nicest code base to play with ;-)
- todd
Why not just store the result of MB_CUR_MAX in a variable and use
that? It's value is not going to change during execution of the
program. This made a big difference in sort(1) once upon a time.
- todd
On Fri, 07 Jan 2022 00:45:47 -0800, Philip Guenther wrote:
> No where. The difference in behavior is that of 'sh' when signaled. Run
> your test programs under "ktrace -i" and compare the behavioral difference
> of the child 'sh' process after reception of the SIGINT.
To add to this, the shell
On Wed, 05 Jan 2022 17:37:19 +0100, Theo Buehler wrote:
> Right, thanks. Changed to use EVP_DigestInit_ex, EVP_DigestFinal_ex and
> dropping EVP_MD_CTX_reset() which is no longer needed.
>
> I included the radiusctl diff here since it is really the same diff.
Looks good to me. OK millert@
-
On Wed, 29 Dec 2021 15:28:57 -0600, Joe Nelson wrote:
> Here's a patch.
That looks correct to me. Since fpos_t just an alias for off_t on
OpenBSD I don't think we need any shared library version bumps.
- todd
On Wed, 05 Jan 2022 10:56:02 +0100, Theo Buehler wrote:
> Another change needed for the upcoming libcrypto bump. Unfortunately,
> the code is structured in a way that it makes error checking hard since
> there are several layers of void functions.
Should this not be using EVP_DigestInit_ex()
On Wed, 29 Dec 2021 07:53:03 -0600, Scott Cheloha wrote:
> uniq(1) defaults to using stdin and stdout, has exactly one input and
> one output, and allows changing the input and/or output to a given
> file.
>
> So, freopen(3) is the idiomatic thing to use here. It simplifies and
> shortens the
On Mon, 27 Dec 2021 15:18:38 -0600, Joe Nelson wrote:
> I recently discovered the funopen function, and was confused by its
> declaration. Specifically, one of its arguments is
>
> fpos_t (*seekfn)(void *, fpos_t, int)
>
> I wondered how seekfn would be able to return an error code, since
On Tue, 14 Dec 2021 11:25:34 -0600, Scott Cheloha wrote:
> In uniq(1), calling skip() to skip fields and/or characters on each
> input line is extremely expensive. One way to reduce the cost is to
> only do it once for a given line, instead of doing it repeatedly for
> the most recent unique
On Sun, 12 Dec 2021 19:15:51 -0600, Scott Cheloha wrote:
> cat(1) sizes its I/O buffer according to the st_blksize of the first
> file it processes. We don't do this very often in the tree. I'm not
> sure if we should trust st_blksize.
It sizes the buffer based on st_blksize of stdout, not the
On Thu, 09 Dec 2021 15:38:36 +, Visa Hankala wrote:
> The system now has two flags for poll and select system calls,
> __EV_POLL which currently covers both calls, and __EV_SELECT which is
> used with select only.
>
> To make the code easier to follow, this diff makes __EV_POLL specific
> to
On Tue, 07 Dec 2021 16:25:59 +, Visa Hankala wrote:
> In simple cases that do not have out-of-band data, the system can skip
> registering the EVFILT_EXCEPT filter. A new flag could indicate when
> the registration is done for select(2). The patch below does the
> tweaking for FIFOs and
On Mon, 06 Dec 2021 17:05:39 +, Visa Hankala wrote:
> This adds EVFILT_EXCEPT handler for pipes. It is a subset of
> EVFILT_READ; it triggers on EOF only. This captures the POLLHUP
> condition of pipe_poll(), used with select(2)'s exceptfds and when
> poll(2) has events without (POLLIN |
On Mon, 06 Dec 2021 22:37:02 -0600, Scott Cheloha wrote:
> lsearch(3) is just lfind(3) + append. If we write it that way we
> shrink lsearch.c. The third function, linear_base(), is just added
> complexity. The indirection buys us nothing.
>
> I don't think we need to keep the historical
On Mon, 06 Dec 2021 19:29:55 -0600, Scott Cheloha wrote:
> This?
I think this is fine. OK millert@
- todd
On Mon, 06 Dec 2021 09:03:43 -0600, Scott Cheloha wrote:
> In lsearch(3), the key is allowed to overlap with the last element in
> base. We need to memmove(3), not memcpy(3), or we could corrupt the
> key in that edge case.
OK, but does this deserve a comment so to that effect to prevent
On Tue, 30 Nov 2021 23:18:23 +0100, Mark Kettenis wrote:
> Maybe add a comment here that libfido2 depends on libz?
>
> > +SUBDIR+=libfido2
Yes, please. With a comment this is OK millert@
- todd
On Mon, 22 Nov 2021 17:53:48 -0700, "Theo de Raadt" wrote:
> > This is the usr.sbin part; I am not touching nsd
> > and other third-party stuff.
>
> Well, some of our programs do have -portable variations (not just openssh),
> and some of them will have to cope.
I don't think we really care
On Sat, 20 Nov 2021 20:19:47 -0600, Scott Cheloha wrote:
> It's not the idiomatic loop from the manpage, but near as I can tell
> it is equivalent.
You are right, I didn't look closely enough.
> ... should we make it idiomatic? Saves a few lines, is less
> confusing, etc.
OK millert@
- todd
On Sat, 20 Nov 2021 11:19:13 -0600, Scott Cheloha wrote:
> > One advantage to using stdio is that
> > it will use the optimal I/O blocksize automatically so you could
> > try using that instead of write(2) and see how it performs.
>
> tee(1) needs to write input to N drains, N >= 1. If we use
On Fri, 19 Nov 2021 21:31:12 -0600, Scott Cheloha wrote:
> Is there a nicer way to pick a "reasonable" buffer size when we just
> want to move as many bytes as possible on a given platform without
> hogging the machine?
Not really. But I don't think you need to worry about "hogging the
machine"
On Tue, 16 Nov 2021 13:53:25 -0600, Scott Cheloha wrote:
> How would you do it? This seemed like the smallest diff to me because
> we don't have to change all the warn(3) calls. Is there an easier thing?
Nevermind, I missed that print_counts() needs to easily distinguish
between stdin and a
On Tue, 16 Nov 2021 12:35:59 -0600, Scott Cheloha wrote:
> In wc(1), the "file" argument to cnt() is NULL when we're enumerating
> the standard input. This causes a NULL pointer dereference if we ever
> hit one of the warn(3) calls in that function.
>
> To fix, change the argument name to "path"
On Sat, 13 Nov 2021 08:41:58 -0700, "Theo de Raadt" wrote:
> Great that it is fixed now for us, however this remains a big problem on
> older systems. So the question is should we mention this as a coding
> hazard for developers, or should we ignore the problem.
This is an implementation detail
On Wed, 10 Nov 2021 17:29:55 +0100, Jan Stary wrote:
> With included, there is no need
> to declare extern int optind and friends again.
Right, most of this is old code that dates from before those were
declared in unistd.h. OK millert@
- todd
On Tue, 02 Nov 2021 22:22:16 -, Klemens Nanni wrote:
> I looked at
> I had to look at the source to be sure what the three different return
> codes 0, 1 and 2 would mean and if there was more to it.
>
> Depending on the error, config(8) exists 1 or 2. 0 on success as usual.
OK millert@
-
uniq appeared in research Unix version 3.
- todd
Index: usr.bin/uniq/uniq.1
===
RCS file: /cvs/src/usr.bin/uniq/uniq.1,v
retrieving revision 1.21
diff -u -p -u -r1.21 uniq.1
--- usr.bin/uniq/uniq.1 23 Dec 2017 00:52:33 -
Actually, the historic version of uniq used static 1000 byte buffers.
Solaris 2.6 includes a version that realloc()s the buffer but I
don't know when exactly that behavior was added.
- todd
On Mon, 01 Nov 2021 21:04:54 -0500, Scott Cheloha wrote:
> Yes it would be simpler. However I didn't want to start changing the
> input -- which we currently don't do -- without discussing it.
>
> The standard says we should "write one copy of each input line on the
> output." So, if we are
On Mon, 01 Nov 2021 20:20:49 -0500, Scott Cheloha wrote:
> On the one hand, it is intuitive that two buffers are not literally
> the same if one has a newline and the other does not. strcmp(3)
> agrees with this.
>
> ... On the other hand, it also seems intuitive that two records are
> the same
On Mon, 01 Nov 2021 10:36:08 -0500, Scott Cheloha wrote:
> My own testing here with pathological inputs didn't show that large of
> a performance difference between fgets(3) and getline(3). There was
> a difference but it was closer to like 5-10%.
With your updated patch I see:
% wc -l /tmp/z
On Sun, 31 Oct 2021 17:28:55 -0500, Scott Cheloha wrote:
> In tr(1), if we have already generated a given character class we
> don't need to do it again.
OK.
> Further, we don't need to keep all the memory we allocate for the set
> of characters in the class. NCHARS + 1 is just an upper bound
On Sun, 31 Oct 2021 12:22:22 -0500, Scott Cheloha wrote:
> Thoughts? OK?
Looks good to me. OK millert@
- todd
On Wed, 27 Oct 2021 21:56:16 +0100, Martijn van Duren wrote:
> Maybe it's not sufficient, but:
>
> sysDescr OBJECT-TYPE
> SYNTAX DisplayString (SIZE (0..255))
> MAX-ACCESS read-only
> STATUS current
> DESCRIPTION
> "A textual description of the entity. This
On Wed, 27 Oct 2021 17:14:28 +0100, Martijn van Duren wrote:
> Trying to search for memory leaks in my new snmpd code I found some
> harmless, but annoying ones in system from SNMPv2-MIB.
>
> We call uname(3) every time (even if we don't even need info from
> that call) and ones set we save it
On Tue, 26 Oct 2021 15:30:17 -, Klemens Nanni wrote:
> > i think either saying to the route socket or broadcast are clear and
> > would read better.
>
> The latter is great, thanks.
OK millert@
- todd
On Mon, 25 Oct 2021 09:13:40 -0400, Dave Voutila wrote:
> I don't know the vi codebase, so I can't tell if this is the right way
> to fix this. It's a minimal change, but I use vi mostly for quick edits
> and commit messages so would appreciate anyone with more knowledge here
> to chime in.
With
On Mon, 25 Oct 2021 12:48:01 +1100, Jonathan Gray wrote:
> Shouldn't lld instead be changed to show warnings?
That was my thinking as well.
- todd
On Fri, 22 Oct 2021 14:25:18 +0100, Martin Pieuchot wrote:
> Last year we added the new EVFILT_EXCEPT filter type to kqueue in
> order to report conditions currently available via POLLPRI/POLLRDBAND
> in poll(2) and select(2).
>
> This new filter has been implemented in tty and socket by re-using
On Tue, 19 Oct 2021 18:08:04 +1100, Jonathan Gray wrote:
> There are many others along those lines in the kernel, for example
> sparse complains about these in vfs_subr.c
>
> /sys/kern/vfs_subr.c:274:64: warning: Using plain integer as NULL pointer
> /sys/kern/vfs_subr.c:275:64: warning: Using
On Thu, 14 Oct 2021 23:06:01 +0200, Mark Kettenis wrote:
> This doesn't work because of the hidden symbol madness. The way
> things currently are we need one copy (s_lrint.c) with:
>
> DEF_STD(fn);
> LDBL_MAYBE_CLONE(fn);
>
> another version (s_lrintf.c) with
>
> DEF_STD(fn);
>
> and a final
On Thu, 14 Oct 2021 01:15:56 +0200, Mark Kettenis wrote:
> Currently the lib/libm/msun/run-lrint_test regress fails on powerpc64
> and other platforms. Our implementation came from NetBSD, but NetBSD
> switched to the implementation from FreeBSD some time ago. That is
> the same implementation
On Sun, 10 Oct 2021 19:13:55 -0500, Scott Cheloha wrote:
> This unifies the input maximums on 32-bit and 64-bit platforms.
This really feels like a solution in search of a problem.
- todd
On Sat, 09 Oct 2021 20:43:12 -0500, Scott Cheloha wrote:
> head(1) currently only validates the last count argument given. I
> think we ought to be stricter. You can specify the -n option an
> arbitrary number of times.
Yes, it is better to perform the check during argument processing.
OK
On Sat, 09 Oct 2021 13:15:39 +0200, Tobias Stoeckmann wrote:
> this merges latest bugfixes from upstream to our version of less.
> No new features introduced. Upstream commits and issues are linked as
> references.
OK millert@
- todd
On Thu, 30 Sep 2021 22:15:39 +0200, Christian Weisgerber wrote:
> E.g. like this?
Yes, that looks correct.
However, this is a bit ugly:
if (pushback_index < MAXPUSHBACK-1)
return (unsigned char)(pushback_buffer[pushback_index++] = c);
else
return
On Thu, 30 Sep 2021 21:37:06 +0200, Christian Weisgerber wrote:
> Unfortunately that also affects the parsebuf/pushback_buffer complex
> used in some parser.y files.
That would require a few extra casts but it is straightforward.
- todd
On Thu, 30 Sep 2021 12:33:58 +0100, Stuart Henderson wrote:
>
> revision 1.628
> date: 2013/11/25 12:52:45; author: benno; state: Exp; lines: +7 -7;
> use u_char for buffers in yylex, for ctype calls
> found by millert@, ok deraadt@
>
On Wed, 22 Sep 2021 15:46:13 +0200, Eric Faurot wrote:
> A user reported that decoded SRS addresses are not correctly evaluated
> against the ruleset. That's because the ruleset always matches against
> the expanded address ("dest") and not the original address ("rcpt").
> This diff should fix
On Fri, 17 Sep 2021 17:30:24 +0200, Alexander Bluhm wrote:
> The LocalDomain in syslogd(8) is not used, remove variable.
> Use RFC 5424 NILVALUE as fallback for LocalHostName.
OK millert@
- todd
The man page for OpenSSL_add_all_digests() says it is deprecated
and should not be called by user code. However, EVP_DigestInit.3
says it must be used.
One of those is wrong...
- todd
Index: lib/libcrypto/man/EVP_DigestInit.3
===
On Tue, 07 Sep 2021 21:38:27 +0200, Mark Kettenis wrote:
> I'm not convinced the original diff is right:
>
> * We have several places in the kernel where we store numbers of pages
> in a (32-bit) int. Changing just one of these places is dangerous.
>
> * Changing the type of just vm_dsize
201 - 300 of 1493 matches
Mail list logo
