Raphael Graf wrote:
> The diff inserts some space above the footer.
> This improves readability and makes it similar to the other output formats.
>
> Here is an example found in the wild, demonstrating the problem:
> https://webassembly.github.io/wabt/doc/wasm-objdump.1.html
So I think one answer
Ingo Schwarze wrote:
> 2. When calling "mandoc -T html" without specifying "-O style=",
> fall back to "-O style=/var/www/htdocs/mandoc.css" by default.
> That might be sensible because it is adequate for local
> viewing of the file, which is likely intended with files
> generated
Ingo Schwarze wrote:
> What about making -O style= *compulsory* unless "option style" is
> defined in man.conf(5)? Just error out when no style sheet is
> configured? That can be combined with inlining the full set of
> rules when -O style=inline is explicitly specified.
This seems unnecessarily
Daniel Jakots wrote:
> Hi,
>
> With nc(1) you can do:
> nc -zv example.com 80
> or
> nc -zv example.com http
> which does the same. This works well unless the service name has a dash:
> $ nc -zv example.com syslog-tls
> nc: service "tls" unknown
>
> This is because nc(1) is able to do some port s
Theo de Raadt wrote:
> If you are going to introduce such complicated semantics, please
> include a proposal for the manual page change so that we can see
> if this can be simply described. Being dimply described in the
> manual page is a marker for whether a change is suitable.
Stealing some wor
Stuart Henderson wrote:
> But I can't imagine scanning a range by name as being much used
> (tcpmux-socks or something just doesn't make sense).
>
> What I think would be least disruptive is to continue to allow - where
> the rest of the parameter is numeric. For alphabetic parameters try
> parsin
Ingo Schwarze wrote:
>
> > That would be fine with me. I definitely think it should be installed
> > somewhere. I found it odd that I had to look for mandoc.css in the
> > source tree when I needed it.
>
> That would be the following patch.
ok to install.
And then update the mandoc man page i
Scott Cheloha wrote:
> - A tick is a 32-bit signed integer on all platforms. If HZ=100, we
>can represent at most ~248 days in ticks. This is plenty. If HZ=1000,
>we now only have ~24.8 days. Some may disagree, but I don't think this
>is enough.
So the question is what happens whe
Scott Cheloha wrote:
> I might have a winner already, though. Earlier today I saw iridium busy
> sleeping: repeat nanosleeps with zero'd timespec structs. I have a ktrace
> here, but I have yet to reproduce. Need to fuss with it a bit more.
>
> fwiw, here's an exerpt:
>
> 90240/241378 iridiu
Raphael Graf wrote:
> The diff inserts some space above the footer.
> This improves readability and makes it similar to the other output formats.
>
> Here is an example found in the wild, demonstrating the problem:
> https://webassembly.github.io/wabt/doc/wasm-objdump.1.html
okay, now that other
Alexander Bluhm wrote:
> Hi,
>
> when there is an invalid character in the uuencoded stream, uudecode(1)
> prints this error message:
>
> uudecode: in: out: character out of range: [33-96]
>
> Problem is that you don't know what is wrong. So I would like to
> print the invalid character. As pr
Bryan Steele wrote:
> It is not possible to unveil(2) all arguments passed to file(1), as this
> would require walking *argv. Instead, we can unveil("/", "r") to permit
> readonly access to the entire filesystem, while restricting all execute
> write, and create operations.
Why not? Because of the
Ted Unangst wrote:
> Bryan Steele wrote:
> > It is not possible to unveil(2) all arguments passed to file(1), as this
> > would require walking *argv. Instead, we can unveil("/", "r") to permit
> > readonly access to the entire filesystem, while rest
Theo de Raadt wrote:
> > unveil isn't really buying much if you pledge "rpath" immediately after,
> > so if you want just add another pledge here instead, that is fine.
>
> "rpath" is obviously cheaper than unveil of even 1 file.
here is a diff that simply adds another pledge.
the attack surface
The sample server doesn't work for me, and while the example is a fun hint at
the alternate universe of "right" and "legal" times, I don't think this is a
good place to suggest actually changing the system timezone.
Demonstrate printing a time modified by TZ instead.
Index: rdate.8
=
There should be a nicer way to quit than ctrl-c. This lets you press q to
quit. (and also checks for esc, for users who don't read the manual.)
Index: grdc.6
===
RCS file: /cvs/src/games/grdc/grdc.6,v
retrieving revision 1.10
diff -u
Theo de Raadt wrote:
> First off, what a weird example you found.
>
> But more on the matter. Is your change even good advice? pool.ntp.org
> is attackable via unauthenticated DNS, and based upon past experience
> who can say if their administrators can even keep their infrastructure
> secure.
Ingo Schwarze wrote:
> Congrats, you found a documentation bug.
>
> Apparently, the rdate(8) program supports the TZ environment variable,
> but the manual page does not say so. An ENVIRONMENT section is missing
> and should be added. It is not a good idea to give EXAMPLES for stuff
> that is ac
Lauri Tirkkonen wrote:
> Hi, another simple diff converting fgetln usage to getline.
>
> I also considered converting grep_fgetln to grep_getline, but that would
> mean that for FILE_MMAP we'd have to copy the string. So this diff keeps
> the grep_fgetln interface as is, but avoids using fgetln fr
Lauri Tirkkonen wrote:
> On Sun, Jan 06 2019 14:02:16 -0500, Ted Unangst wrote:
> > Lauri Tirkkonen wrote:
> > > Hi, another simple diff converting fgetln usage to getline.
> > >
> > > I also considered converting grep_fgetln to grep_getline, but that would
>
Lauri Tirkkonen wrote:
> Hi, it seems install(1) has a race condition: in create_newfile, it
> first unlinks the target file and then tries to open it with
> O_CREAT|O_EXCL.
> The below diff essentially removes the -S option and makes install
> always use temp files (ie. -S is always on), eliminat
Artturi Alm wrote:
> display.width=1920
> display.height=1200
> display.depth=32
> display.emulations=vt100
> display.col_x_row=120x37
> display.font_wxh=16x32
now that we've all had a chance to weigh in on the font, why are you adding
this weird x format? speaking of ugly... it should print colum
Lauri Tirkkonen wrote:
> On Mon, Jan 07 2019 15:48:25 -0500, Ted Unangst wrote:
> > Lauri Tirkkonen wrote:
> > > Hi, it seems install(1) has a race condition: in create_newfile, it
> > > first unlinks the target file and then tries to open it with
> > > O_CRE
Todd C. Miller wrote:
> On Mon, 07 Jan 2019 22:55:54 +, Christian Weisgerber wrote:
>
> > Oooh, that short period can be the time between disk flushes (30s?)
> > with softupdates. I think that's one of the scenarios where you
> > can run out of disk space if you have softupdates enabled.
>
>
Mark Kettenis wrote:
> Index: dev/acpi/dsdt.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
> retrieving revision 1.243
> diff -u -p -r1.243 dsdt.c
> --- dev/acpi/dsdt.c 19 Aug 2018 08:23:47 - 1.243
> +++ dev/acpi/dsdt.c
Ted Unangst wrote:
>
> Does 0x come from ACPI? Can we give that a name?
>
> I thought sleeping for one tick is kinda weird, but I see what it's doing with
> the acpi_dotask loop. This feels precarious, but whatever.
So upon further thought, this is pretty bad. If the new
Jan Stary wrote:
> calendar imho doesn't need to setlocale(LC_TIME, ...)
> before and after strftime(3), as LC_TIME is ignored.
iirc, our current practice is to delete locale related calls where the
functionality isn't implemented, so this and the other diffs are ok.
Scott Cheloha wrote:
> > On Jan 10, 2019, at 14:35, Jan Stary wrote:
> >
> > Does locate(1) need to setlocale(3)?
>
> locate(1) uses tolower(3), the results of which can be affected by
> locale settings. locate(1)'s database is, at least in theory, portable.
> If you don't explicitly set the lo
Ingo Schwarze wrote:
> That stuff is a very serious trap not only for the unwary, but also
> for experienced programmers. Less than a month ago, i discussed
> the matter with a senior programmer from the GNU project who has
> been maintaining important software over there for a long time and
> gue
Stefan Fritsch wrote:
> +#define CREAD(sc, memb)
> \
> + ({
> \
> + struct virtio_pci_common_cfg c;
> \
> +
Stefan Fritsch wrote:
> On Fri, 11 Jan 2019, Ted Unangst wrote:
> A simple inline function does not work because memb is the name of a
> member of a struct. But combined with a macro it would work. Like this:
yeah, that looks pretty normal.
Ingo Schwarze wrote:
> So, here is some cleanup:
> * garbage collect useless hand-rolled lookup tables
> * merge one-line helper functions into callers
> * garbage collect obfuscating macros
> * fix one format string error (%d used for u_int)
> * garbage collect setlocale(3) and
> * garbage
By inspection, it appears possible this access will underrun if the first
character is a %.
Index: mail.c
===
RCS file: /cvs/src/bin/ksh/mail.c,v
retrieving revision 1.25
diff -u -p -r1.25 mail.c
--- mail.c 7 Jan 2019 20:50:43 -
Ingo Schwarze wrote:
> Feel free to either commit the complete patch below or commit
> only your part and optionally OK one, two, or three of my additional
> changes.
These look ok with one comment.
> @@ -141,8 +141,11 @@ mpset(char *mptoparse)
> mmsg = strchr(mpath, '?');
>
Matteo Niccoli wrote:
> Didn't find any other examples. At the moment rust code is recognized
> as ASCII C program text.
src/usr.bin/file/text.c has an array of special matches for text.
It has various omissions, though.
is matched as SGML.
import means Java, but not python or go.
etc. I suppo
Nicholas Marriott wrote:
> I think I would avoid adding more of these at the moment, especially
> ones that aren't very specific (why is "package" Go and not Java?) and
Because I've never written a java package. :)
Theo Buehler wrote:
> According to our documentation and all the standards I checked,
> snprintf() returns a negative value on error, not necessarily -1.
> This confused me quite a bit recently so I suggest to adjust the
> example code as follows:
I don't know. I guess it's technially correct, bu
Bryan Linton wrote:
> Hello tech@,
>
> I'd appreciate it if someone could review both this patch and my
> analysis.
There is no reason for etime to be a global. We can make it a local with the
correct value in the two functions that use it, avoiding future problems as
well.
Index: vmstat.c
mlarkin discovered that if the treasure lands on the snake, you won't see it.
it's still there, but invisible. this fixes the display to draw the correct
character.
Index: snake.c
===
RCS file: /cvs/src/games/snake/snake.c,v
retrievi
Scott Cheloha wrote:
> > > diff --git sys/arch/sparc64/dev/fd.c sys/arch/sparc64/dev/fd.c
> > > index 8d548062f83..654d8c95524 100644
> > > --- sys/arch/sparc64/dev/fd.c
> > > +++ sys/arch/sparc64/dev/fd.c
> > > @@ -1632,7 +1632,7 @@ loop:
> > > fdc->sc_state = RECALCOMPLETE;
> > >
We recently had a thread about adding more sensors, but then the browser will
use them to spy on us, and everybody was sad. We allow hw.sensors even for
pledge processes because ntpd needs to read the time. However, ntpd only needs
to read the time.
This diff zeroes out sensors other than timedelt
The persist feature in doas (actually the kernel side implementation) has some
additional checks. The idea was to prevent accidental usage, but in practice
it seems this is making life more difficult than necessary. It's cost without
benefit. This diff relaxes the session checks so it should be pos
Stuart Henderson wrote:
> On 2019/01/22 21:46, Ted Unangst wrote:
> > The persist feature in doas (actually the kernel side implementation) has
> > some
> > additional checks. The idea was to prevent accidental usage, but in practice
> > it seems this is making life mo
Lauri Tirkkonen wrote:
> > > oh, interesting. that's sloppy. can you please fix that first, separately?
> >
> > Sure, here it is.
>
> Could you please take a look at it? It's been a couple weeks.
yup, sorry, slipped by. committed.
Maximilian Lorlacks wrote:
> Good day,
>
> It seems that fsync(2) may data after returning EIO once[1]. This
> behaviour seems to cause problems with databases such as PostgreSQL
> and goes contrary to the man page's description, which says that
> "fsync() and fdatasync() should be used by progra
Ted Unangst wrote:
> Maximilian Lorlacks wrote:
> > Good day,
> >
> > It seems that fsync(2) may data after returning EIO once[1]. This
> > behaviour seems to cause problems with databases such as PostgreSQL
> > and goes contrary to the man page's descrip
Ingo Schwarze wrote:
> If people here agree with the general direction of making -S the
> default and removing the fragile non-S mode (see the patch below),
> i'll run a full make build and make release and then ask for OKs.
Just checking we didn't forget about this. Seems the right thing to do.
Run calendar without a calendar file.
calendar: no calendar file: ``calendar'' or ``~/.calendar/calendar''
I think these fake double quotes are really ugly. It's been a long time since
the typical font rendered them symmetrically.
Also, fix another instance in the man page. There's more to be fo
Kristaps Dzonsons wrote:
> > Attached is a manpage for ASN1_get_object(3), ASN1_put_object(3), and
> > ASN1_put_eoc(3). Having the first function documented would have saved
> > me a lot of time. (I did the others for symmetry.)
> >
> > In short, they encode or decode ASN.1 data structures from/
Lauri Tirkkonen wrote:
> In summary: sorry for the bug I introduced - please apply the diff above
> to fix memory mapping files in grep. As for the fgetln->getline
> conversion, I think this result should show that fgetln is not
> particularly smart about how it's calling mmap -- getline seems bett
I have a very large (gzipped) archive and I've forgotten exactly how the
contents are structured. (is it stuff, tedu/stuff, etc.)
I run tar ztf bananas.tgz | head. This prints out a few lines, and then...
nothing. For a long time. head is long gone, but tar is still chugging away.
Aren't processes
Amit Kulkarni wrote:
> This comment below is misleading. There are no such sysctl's. The defines are
> only used in kern/subr_pool.c
>
... to implement the sysctls. What are you talking about?
>
>
> diff --git sys/pool.h sys/pool.h
> index d2f05227b7a..e97f774a272 100644
> --- sys/pool.h
> ++
Anthony J. Bentley wrote:
> Jason McIntyre writes:
> > in the man page you have used Sq. that will make it mark up the same as
> > it already does:
> >
> > (`*')
fwiw there was already an existing sq in the man page. I only fixed the one
using literal single quotes.
> There's a difference: Te
Ted Unangst wrote:
> > Keeping a buf with an error in the delayed write list would probably have
> > some
> > serious consequences. When would we ever remove it?
>
> Thought about this some more. The best approach may be to set a flag in
> the vnode that there was a
Alex Holst wrote:
> Quoting Mark Kettenis (mark.kette...@xs4all.nl):
> > An accurate description would be that the percentage is actually the
> > percentage of "DMA-reachable" physical memory the buffer cache may
> > use. The minimum percentage is 5% and the maximum is 90%.
> >
> > But documentin
Jason McIntyre wrote:
> though i suspect "asperity" would have most of us reaching for our
> dictionaries, it's not neccessarily a bad thing. it seems the
> best fit to me.
That may be construed as the one going to the stars is the one with the
asperity, however. I think the intention is to descri
enh wrote:
> it seems like OpenBSD did cherrypick this FreeBSD regex fix...
>
> https://github.com/freebsd/freebsd/commit/981dd2aa38f37e4d0dd86225c619e900fc03d82e#diff-d7c26714f9432399b202eefcedb97491
That's an odd way to phrase applying a diff that was sent to OpenBSD...
> ...but not this one,
We have iterated on various designs to reduce pressure on kmem map over time.
One of the problems is that sometimes you want to allocate something in intr
context (NOWAIT), and other times in process context (WAITOK), but then at
free time they get all glommed together. This happens in pool.
Since
gwes wrote:
>
>
> On 02/08/19 15:35, Jeremie Courreges-Anglas wrote:
> >
> > I think it's fair to give the user a chance to understand why
> > scan_ffs(8) won't help in this case.
> >
> > ok?
> >
> >
> > --- scan_ffs.8.~1.16.~ Mon Mar 24 00:28:46 2008
> > +++ scan_ffs.8 Fri Feb 8 21:31
Marc Espie wrote:
> hey, your commit to install(1) broke something.
>
> Specifically lang/go-boostrap now produces a broken package which can't
> be used to build go.
>
> All the go/bootstrap/pkg/tool/openbsd_amd64/*
> have lost their x bit
>
> Relevant fake install information, it definitely lo
Marc Espie wrote:
> Something similar to this perhaps ?
> Not fully tested yet, but it should avoid the race of trying to
> unlink tempfile several times, and also fix the file name in error messages.
That's probably better.
Alexander Bluhm wrote:
> GNU dd has the conv=fsync feature which does an fsync(2) after final
> write to output. I find this useful for write performance measurement
> through the file system without buffer cache optimization. Others
> may like the reliable storage guarantee of fsync(2).
>
> Do
Alexander Bluhm wrote:
> We should not implement the magic which device allows fsync(2) into
> dd(1). Just do what the user says, if it is nonsense, give him an
> error.
sure. ok.
Klemens Nanni wrote:
> I came across this thanks to a nicely detailed bug report about
> mail/isync's `CopyArrivalDate' feature, which uses strptime(3). Quote:
>
> The IMAP protocol specifies a date format beginning with a
> day-of-month space-padded to two characters. The %d specifie
UFS dirhash has a limit on how much memory is used to prevent runaway
allocations. I believe the default limit (2MB) is rather conservative.
It was picked to avoid causing trouble back when machines were tiny and
dirhash was new.
For example, a maildir with 100K files takes about 3MB of memory. Be
Jeremie Courreges-Anglas wrote:
> I may be naive, but shouldn't dirhash memory be accounted with/like
> buffer cache memory (freed when other sybsystems need it)?
Probably. The limit exists in part because there is no backpressure.
There's exactly one global variable in signify, but it could be local.
We do write to this variable, but not to move data between functions.
Index: zsig.c
===
RCS file: /cvs/src/usr.bin/signify/zsig.c,v
retrieving revision 1.15
diff
signify -z adds a date= line to the header, but nothing reads it. It's also
not very useful, since it's outside the signature. It would still not be
useful, because nothing about the signify design cares about when something
was signed. It does cause trouble, however, because signing the same thing
Stuart Henderson wrote:
> On 2019/02/23 18:02, Ted Unangst wrote:
> > signify -z adds a date= line to the header, but nothing reads it. It's also
> > not very useful, since it's outside the signature. It would still not be
> > useful, because nothing about the
Andre Stoebe wrote:
> Hi,
>
> I, too, would like to have a way of signing the gzip archive in a
> reproducible way, so here's a diff that uses -n, similar to gzip(1).
>
> However, if that's a bad idea, I'm fine with continuing to use an
> unsigned gzip archive and creating a sigfile with signify.
Matthias Schmidt wrote:
> Hi,
>
> while looking at signify's man page I noticed that the names of the
> arguments in the EXAMPLES section change (newkey.sec vs key.sec, etc).
> The diff harmonizes the examples. It makes it easier to follow the examples.
I don't think the intention was to presen
Marc Espie wrote:
> On Mon, Feb 25, 2019 at 03:02:42PM -0500, Ted Unangst wrote:
> > Andre Stoebe wrote:
> > > Hi,
> > >
> > > I, too, would like to have a way of signing the gzip archive in a
> > > reproducible way, so here's a diff that use
apm should not silently ignore bonus args.
Index: apm.c
===
RCS file: /cvs/src/usr.sbin/apm/apm.c,v
retrieving revision 1.34
diff -u -p -r1.34 apm.c
--- apm.c 14 Aug 2018 06:38:33 - 1.34
+++ apm.c 28 Feb 2019 16:
I used to use synclient to configure taps for only a single button. I find two
and three button taps problematic, resulting in crazy highlighting and
pasting. New computer uses wstpad, however, so there's no more synclient.
Patch below changes wstpad to only report button clicks for single taps. T
One more quick hack. I have become accustomed to scroll going in the reverse
direction. Previously set a negative delta with synclient.
Again, not sure how to connect this to wsconsctl, but here's what I'm running.
Index: wstpad.c
==
Ulf Brosziewski wrote:
> BTW, reverting the scroll direction is also possible by configuring
> a "ZAxisMapping" in ws(4), with an xorg.conf like this one:
>
> Section "InputClass"
> Identifier "touchpad_scroll_buttons"
> MatchIsTouchPad "true"
> Option "ZAxisMapping" "5 4"
> EndSection
Lauri Tirkkonen wrote:
> in other words, xterm is (and was) using its own idea of how many
> columns characters take up. The way this manifested itself to me was
> that I received some email that contained emoji characters in the
> subject, and they look fine in mutt when I use another terminal (st
Matthieu Herrb wrote:
> I would prefer a diff that just add a &&!defined(__OpenBSD__) to the
> condition before the definition of systemWcwidthOk(). This will cause
> less risk of conflicts in future updates and clearly show the
> intention.
If you prefer that, I would suggest the following to avo
Hiltjo Posthuma wrote:
> Not all BSD man pages reference the same RFCs, like RFC5322. The OpenBSD
> strptime(3) man page (%z) describes military/nautical zones are supported.
>
> - NetBSD supports it (correctly since only a few months ago and it is not in
> stable or backported).
> - FreeBSD and
Andre Stoebe wrote:
> Hi,
>
> I, too, would like to have a way of signing the gzip archive in a
> reproducible way, so here's a diff that uses -n, similar to gzip(1).
Thanks. I think it's more consistent to store a zero time stamp. This diff is
a little simpler and avoids some variable reabuse.
Alexandr Nedvedicky wrote:
> it is, however -Fall operates on main ruleset only. -Fall also does
> not reset limits and timeouts. Hence my first idea was to introduce
> '-FNuke', which kills all rulesets and tables.
>
> I don't want to change behaviour of existing option ('-Fall'),
Frederic Cambus wrote:
> On Mon, Mar 18, 2019 at 08:02:09PM +0200, Artturi Alm wrote:
>
> > > Revised diff below iterating on what Artturi previously sent, and
> > > a snippet of wsconsctl output with the diff applied:
> > >
> > > display.width=1600
> > > display.height=900
> > > display.depth
Mark Kettenis wrote:
> > Date: Thu, 28 Mar 2019 09:00:35 -0700
> > From: Chris Cappuccio
> >
> > I think the current MSI-X implementation is a minimal skeleton,
> > enough for some devices under virtualization. I don't know if it's
> > enough for NVMe on real hardware.
>
> The main problem is th
Alexandr Nedvedicky wrote:
> below is the diff I'd like to commit.
this is fine with me.
Oh, right, I reworded it slightly, but I think this is something we should
note.
Index: fsync.2
===
RCS file: /home/cvs/src/lib/libc/sys/fsync.2,v
retrieving revision 1.14
diff -u -p -r1.14 fsync.2
--- fsync.2 10 Sep 2015 17:55:2
Theo de Raadt wrote:
> So the diff presented falls short of what should be done here;
> insufficient lines deleted.
we're not getting to the fun part yet, but this unfold some complex operations
to assist human readers.
-min_child -= min_child == s->n ||
min_heap_elem_greater(s->p[min_ch
Ted Unangst wrote:
> (and then reformat to be knf, but after changes that require review.)
mostly mechanical..
we'll get to real changes eventually :)
Index: min_heap.h
===
RCS file: /cvs/src/lib/libevent/min_heap.h,v
re
Tobias Stoeckmann wrote:
> I would like to protect min_heap_push against integer overflows,
> which could either be triggered on a 64 bit system with massive
> amounts of RAM (to overflow s->n) or on a 32 bit system with tight
> memory layout (overflowing a * sizeof *p).
>
> Both cases are basical
Tobias Stoeckmann wrote:
> Changing n means that at least timeout_correct in event.c must be
> adjusted as well, because it is used as an unsigned:
ah, good catch. I don't think it's wrong (until it overflows) but needs to be
fixed. Needs some more review then. Thanks.
Tobias Stoeckmann wrote:
> On Mon, Apr 22, 2019 at 01:24:13PM -0400, Ted Unangst wrote:
> > ah, good catch. I don't think it's wrong (until it overflows) but needs to
> > be
> > fixed. Needs some more review then. Thanks.
>
> I have added following chang
Bryan Steele wrote:
> > I just got through building a new desktop machine and thought I'd
> > install OpenBSD -current on it. The install kernel booted quite fast,
> > but now that I have the real kernel there, it takes approximately 5
> > minutes to boot. The vast majority of the time is spent a
Martijn van Duren wrote:
> Is there a sound reason to keep this code here that I'm overlooking
> or can we please remove it?
I'll add that the umask calls make this function unsafe in a threaded program,
which I think is unexpected.
Simplify examples section. The magic recipe is contained in sysupgrade, so we
can omit it, and instead add a .xr to sysupgrade.8.
Index: signify.1
===
RCS file: /home/cvs/src/usr.bin/signify/signify.1,v
retrieving revision 1.46
diff
Jeremie Courreges-Anglas wrote:
> So the diff below removes the fallback path and all associated code and
> variables. I have left out some minor cleanups for now to ease reviews.
makes sense to me.
Tobias Stöckmann wrote:
> Generally this is a rather theoretical case. Normal users are not
> allowed to allocate so much memory. But better be safe than sorry,
> especially if login.conf values were adjusted (or the process runs
> as root).
>
> This patch completely removes "unsigned int" from bu
Tobias Stoeckmann wrote:
> This patch avoids a possible integer overflow on excessively large
> amount of events added to an event base in kqueue mode (default).
>
> Just as with previous changes, this is very unlikely to trigger and
> is a just a defensive measure.
>
> Changes in this diff:
>
>
Matthew Martin wrote:
> ping
>
> On Thu, Apr 25, 2019 at 11:21:00PM -0500, Matthew Martin wrote:
> > On Thu, Apr 25, 2019 at 08:59:56PM -0600, Theo de Raadt wrote:
> > > > + argv = alloca((n + 1) * sizeof(*argv));
> > >
> > > Our source tree is exceedingly sparing in the use of alloca().
>
Theo de Raadt wrote:
> Isn't something like better -- to avoid marshalling code to convert
> arguments -> array?
this requires mixing declarations and code, but all our compilers are c99
compliant now, and this does make ca_system simpler.
>
> char *pkcs_args[] =
> PATH_OPENSSL,
>
Matthew Martin wrote:
> I did that originally [1], but Reyk preferred the varargs approach [2],
> so I changed the patch to match.
Sorry, only wading into the thread at this point. Seems not everybody has the
same taste in code... Well, we have the original. Let me bring that back.
Ted Unangst wrote:
> Matthew Martin wrote:
> > I did that originally [1], but Reyk preferred the varargs approach [2],
> > so I changed the patch to match.
>
> Sorry, only wading into the thread at this point. Seems not everybody has the
> same taste in code... Well, we h
101 - 200 of 1831 matches
Mail list logo
