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
> > +++ ufs/
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 @@ handle_writ
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. Raymond).
In my opi
> 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 NULL pointers,
> > >
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
> > --- a/gnu/
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
> 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
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 pla
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 i
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
retrievi
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
--- netinet
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.
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
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 Cheloh
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 behavio
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
'through
> 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
> 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 prog
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.
>
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 mod
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
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.
> We read by mapping things out on
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 922
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) wh
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 Skin
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 sou
26 matches
Mail list logo