Re: ufs free()

On Sat, Mar 31, 2018 at 11:15:35PM +0200, Christian Weisgerber wrote: > David Hill: > > > This diff adds sizes to free(), which completes ufs/ffs. > > It's broken at least for softdep+UFS2. This chunk blows up: > > > --- ufs/ffs/ffs_softdep.c 10 Feb 2018 05:24:23 - 1.138 > > +++

Re: ufs free()

David Hill: > This diff adds sizes to free(), which completes ufs/ffs. It's broken at least for softdep+UFS2. This chunk blows up: > --- ufs/ffs/ffs_softdep.c 10 Feb 2018 05:24:23 - 1.138 > +++ ufs/ffs/ffs_softdep.c 29 Mar 2018 02:55:37 - > @@ -4034,7 +4036,8 @@

Re: manpage text width

Hi Ingo, In article <20180329235743.ge59...@athene.usta.de> Ingo Schwarze wrote: > > Can I do anything to fix this? > > Yes. > I've always wondered why groff did that nonsense with man pages. I remember discussing this same issue in groff mailing lists years ago (with E.

Re: binutils: build with LLVM 6.0.0

> Date: Sat, 31 Mar 2018 21:58:06 +0200 > From: Patrick Wildt > > On Thu, Mar 15, 2018 at 03:55:25PM -0700, William Ahern wrote: > > On Thu, Mar 15, 2018 at 05:23:24PM +0100, Patrick Wildt wrote: > > > Hi, > > > > > > LLVM 6.0.0 does now complain of code does computation on

Re: binutils: build with LLVM 6.0.0

On Thu, Mar 15, 2018 at 09:31:13PM -0600, Todd C. Miller wrote: > On Thu, 15 Mar 2018 17:23:24 +0100, Patrick Wildt wrote: > > > diff --git a/gnu/usr.bin/binutils-2.17/include/obstack.h > > b/gnu/usr.bin/binuti > > ls-2.17/include/obstack.h > > index 88c2a264adc..8839c48e95f 100644 > > ---

Re: binutils: build with LLVM 6.0.0

On Thu, Mar 15, 2018 at 03:55:25PM -0700, William Ahern wrote: > On Thu, Mar 15, 2018 at 05:23:24PM +0100, Patrick Wildt wrote: > > Hi, > > > > LLVM 6.0.0 does now complain of code does computation on NULL pointers, > > which apparently binutils makes use of. I think we can teach binutils > > to

Re: dd(1): snprintf+writev -> dprintf

> On Sat, Mar 31, 2018 at 01:04:43PM -0600, Theo de Raadt wrote: > > The only worry about converting from iov to dprintf could be some > > atomicity requirement. I don't really see that in play here, I think > > the iov uses was simply for convenience. No other 'signalling interrupts' > > seem

Re: dd(1): snprintf+writev -> dprintf

On Sat, Mar 31, 2018 at 01:04:43PM -0600, Theo de Raadt wrote: > The only worry about converting from iov to dprintf could be some > atomicity requirement. I don't really see that in play here, I think > the iov uses was simply for convenience. No other 'signalling interrupts' > seem to be in

arch/amd64 free

Hello - This diff is more involved. In est_acpi_pss_changed, a new table is allocated but n isn't updated, which keep tracks of the number allocated. Set it. In est_init, fake_table was being allocated with 3. Change that to allocate exactly what is need by setting n earlier. Regarding the

mfs free

Add the free size. (allocated in mfs_vfsops.c) mfsp = malloc(sizeof *mfsp, M_MFSNODE, M_WAITOK | M_ZERO); devvp->v_data = mfsp; OK? Index: ufs/mfs/mfs_vnops.c === RCS file: /cvs/src/sys/ufs/mfs/mfs_vnops.c,v

netinet memcpy/free

Hello - memcpy can be used on freshly allocated memory. Fill in the free size for it. OK? Index: netinet/tcp_subr.c === RCS file: /cvs/src/sys/netinet/tcp_subr.c,v retrieving revision 1.169 diff -u -p -r1.169 tcp_subr.c ---

Re: dd(1): snprintf+writev -> dprintf

The only worry about converting from iov to dprintf could be some atomicity requirement. I don't really see that in play here, I think the iov uses was simply for convenience. No other 'signalling interrupts' seem to be in play.

dd(1): snprintf+writev -> dprintf

Simpler. ok? -- Scott Cheloha Index: bin/dd/misc.c === RCS file: /cvs/src/bin/dd/misc.c,v retrieving revision 1.22 diff -u -p -r1.22 misc.c --- bin/dd/misc.c 24 Oct 2017 14:21:10 - 1.22 +++ bin/dd/misc.c 31 Mar

Re: dd(1): overhaul operand parsing

Updated diff with changes from tobias@: This patch now removes (u_int) casts from input/output buffer allocation in dd.c, which was incorrect beforehand anyway, but with the other changes here was manifesting as a segfault for combinations of cbs and ibs/obs that overflowed u_int. -- Scott

Re: Should rm(1) -Pf change file permission?

Hi, Gregoire Jadi wrote on Fri, Mar 30, 2018 at 06:07:42PM +0200: > While working on a port of keyringer, I observed the following behavior > of rm(1) with the -P option: if the file does not have write permission, > the file is removed without being overwritten. > > This is not the same

[PATCH] Update default QoS markers for ssh

Dear all, There may be opportunity for improvement of ssh(1) and sshd(8)'s default QoS markers for better integration in environments that can offer either layer-2 or layer-3 prioritisation profiles. Currently ssh(1) and sshd(8) set obsoleted values 'lowdelay' for interactive sessions and

Re: libsa: udp read changes endianness

> I think we should not convert headers into a host-readable format, the > upper layers need to know the network layers if they do this kind of > layer overreach. I agree. It probably comes from a time when ntohs and family were true functions (during the inline asm conversion days); it was seen

Re: manpage text width

> Don't you already need this logic, getenv(3) + isatty(3), to decide if > you use a pager or not? Although I don't understand why getenv(3) is > needed, isn't a TIOCGWINSZ ioctl(2) enough?. Because there is a defacto standard that some SVR2 environment (before the ioctl) be honoured by many

Re: expr: Fix integer overflows

Hi Tobias, Tobias Stoeckmann wrote on Sat, Mar 31, 2018 at 01:28:19PM +0200: > I actually ended up in expr(1) after seeing that the test(1) and ksh(1) > debate could be continued here. While expr(1) is int64_t, expressions > in ksh(1) are of type long, i.e. 32/64 bit depending on architecture. >

Re: manpage text width

On 3/31/18, Andras Farkas wrote: > On Fri, Mar 30, 2018 at 11:23 AM, Chris Bennett wrote: >> This is very important. Our brains just are not good at working with >> long lines. This is hard-wired. If anyone doesn't believe me, try >> setting your browser window to a narrower width or use reader

Re: manpage text width

On Fri, Mar 30, 2018 at 01:57:43AM +0200, Ingo Schwarze wrote: > I do *NOT* want to add SIGWINCH signal handling to man(1) to abort > less(1), reformat, and respawn less(1) in that case. That kind of > magic would be over the top, and SIGWINCH is an abomination in the > first place. Why on earth

Re: manpage text width

On Fri, Mar 30, 2018 at 11:23 AM, Chris Bennett wrote: > This is very important. Our brains just are not good at working with > long lines. This is hard-wired. If anyone doesn't believe me, try > setting your browser window to a narrower width or use reader mode.

Re: expr: Fix integer overflows

Hi, On Sat, Mar 31, 2018 at 02:57:45AM +0200, Ingo Schwarze wrote: > Even though - as discussed previously for test(1) - behaviour is > undefined by POSIX outside the range 0 to 2147483647, we are allowed > to handle a larger range, and i agree that handling the range > -9223372036854775808 to

Re: manpage text width

On 31/03/18(Sat) 03:20, Ingo Schwarze wrote: > Paul Irofti wrote on Fri, Mar 30, 2018 at 11:23:54AM +0300: > [...] > > which is EXACTLY what I was looking for! Can it be the default? :) > > I'm neither particularly enthusiastiastic (because it requires > more code, in particular more getenv(3)

Re: Should rm(1) -Pf change file permission?

Hi Grégoire/all, On Fri, 30 Mar 2018 18:07:42 +0200 Grégoire Jadi wrote: > ... here is a small test to demonstrate ... Same behaviour noticed and previously bugged:- http://openbsd-archive.7691.n7.nabble.com/rm-P-doesn-t-overwrite-a-user-owned-read-only-file-td266276.html Regards, -- Craig

libsa: udp read changes endianness

Hi, I have been working on TFTP boot support for arm64 and armv7 on top of u-boot. One thing that set me back was an endianness issue. TFTP works the way that you send to port 69, but when the server answers he chooses a new source port. So when you reply again, you have to reply to the new