Re: Add readonly flag to tftpd

On 2016/01/26 02:06, Matthew Martin wrote: > I'd bet the most common use case for tftpd is to serve PXE files or > similar where the files being served should not be modified. I'm failing > to find a use case where files need to be overwritten, but new files > must not be created. It's used to

Re: udf uiomove() conversion

Martin Natano wrote: > Below the conversion to uiomove() for isofs/udf/. Note that converting > size to size_t is not possible in udf_read(), as udf_readatoffset() > requires a pointer to an integer variable. Changing that would cause a > lot of code churn, so i chose to truncate uio_resid to

Re: Add readonly flag to tftpd

On Mon, Jan 25, 2016 at 07:32:52AM +, Stuart Henderson wrote: > On 2016/01/25 04:32, Jérémie Courrèges-Anglas wrote: > > > > Hi Matthew, > > > > Matthew Martin writes: > > > > > On Sun, Jan 24, 2016 at 03:05:28AM -0600, Matthew Martin wrote: > > >> Add a -R flag to tftpd

Re: Loops depending on undefined behavior

On Mon, 25 Jan 2016 22:20:53 -0500, Michael McConville wrote: > The third case seems questionable. However, (IIUC) integer conversion > rules dictate that the int is implicitly cast to an unsigned int[1] and > that two's complement arithmetic is preserved in this cast.[2] > > C integer type

Little patch

Hi all, I just had a short chat with otto and would like to know if this little patch would be considered. The reasoning is while debugging a program I got a segmentation fault inside the loop as pool was NULL probably due to the fact that malloc_init was not called first. Thanks in advance.

Don't wrap the cursor in tmux in copy mode

If the cursor is in position 0, 0 in copy mode, and the left arrow is pressed, the cursor position is wrapped to the end of line. A similar situation occurs at the last position and the right arrow. The following patch prevents that, and makes the behaviour more consistent with other software,

Re: Mention lang/go and lang/rust in faq8.html

On 14:58:03, 26.12.15, Michael McConville wrote: > Michal Mazurek wrote: > > Go and Rust are now widely used. It might be worth mentioning them in > > the FAQ. > > ok mmcc@ This was ok'd but never commited. > > Index: faq8.html > >

Re: Little patch

Nevermind otto yook care of it already :) On 26 January 2016 at 15:39, David CARLIER wrote: > Hi all, > > I just had a short chat with otto and would like to know if this little > patch would be considered. The reasoning is while debugging a program I got > a segmentation

Re: Don't declare main() in fsck, fsck_msdos, fsdb, ncheck_ffs

On 17:30:27, 2.01.16, Michal Mazurek wrote: > main() does not need to be declared. > > Also mark usage() as __dead in fsck_msdos and fsdb. This was never commited. Below are just the diffs to remove the declaration of main(): Index: fsck.c

Re: Firefox, malloc(3) and threads

FYI: This diff is in the snapshots since Sunday. On Mon, Jan 25, 2016 at 4:34 PM, Matthew Via wrote: > I've had the patch applied for two days now and have not seen any ill > efects. This is a Thinkpad T410 running snapshots. > > Before, youtube was unwatchable. Sound

Re: Mention lang/go and lang/rust in faq8.html

On Tue, Jan 26, 2016 at 04:34:44PM +0100, Michal Mazurek wrote: > On 14:58:03, 26.12.15, Michael McConville wrote: > > Michal Mazurek wrote: > > > Go and Rust are now widely used. It might be worth mentioning them in > > > the FAQ. > > > > ok mmcc@ > > This was ok'd but never commited.

Re: GIF interface and Routing Serious Unexpected behavior

On Fri, Jan 15, 2016 at 9:23 AM, sven falempin wrote: > > Ok this morning the routing of gif was not done , after deleting the > default route and readding it, > tada, it s routed again. > > I will test with 5.8 , is it enough or do you absolutely require current ? > i

Re: /usr/src/usr.sbin/lpr/common_source/rmjob.c diff

On Tue, Jan 26, 2016 at 07:24:05PM +0100, Theo Buehler wrote: > On Tue, Jan 26, 2016 at 11:40:44AM -0600, Chris Bennett wrote: > > I found this in several other files in lpr src directories. > > Doesn't seem to get used in any lp* files or connect with anything > > higher up. > > > > Am I looking

less.h small cleanup

- sorts includes + remove unneeded comment - less.h 1.24[1] removes the only use of CHAR_BIT, so remove it - remove SHELL_META_QUEST, doesn't seem to be used either [1]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/less/less.h.diff?r1=1.23=1.24=date=h Index: less.h

Re: GIF interface and Routing Serious Unexpected behavior

On Fri, Jan 15, 2016 at 9:23 AM, sven falempin wrote: > > I will test with 5.8 , is it enough or do you absolutely require current ? > i think for this case only the kernel could be updated. There have been big changes to the network/routing stack since 5.8 - at least

Re: GIF interface and Routing Serious Unexpected behavior

On 2016/01/26 20:11, Stuart Henderson wrote: > On Fri, Jan 15, 2016 at 9:23 AM, sven falempin > wrote: > > > > I will test with 5.8 , is it enough or do you absolutely require current ? > > i think for this case only the kernel could be updated. > > There have been big

Re: Firefox, malloc(3) and threads

On Mon, Jan 25, 2016 at 09:57:37AM +0100, Landry Breuil wrote: > On Mon, Jan 25, 2016 at 08:48:21AM +0100, Mark Kettenis wrote: > > > From: "Peter N. M. Hansteen" > > > Date: Sun, 24 Jan 2016 23:10:41 +0100 > > > > > > On 01/22/16 22:46, Mark Kettenis wrote: > > > > Firefox

Re: /usr/src/usr.sbin/lpr/common_source/rmjob.c diff

On Tue, 26 Jan 2016 12:52:54 -0600, Chris Bennett wrote: > I actually started to think I was wrong after I posted diff. Was reading > man pages about signals just now. I didn't know there was an alarm man > page, thanks. It looks like I need to rewrite code to use setitimer > since alarm is now

Re: /usr/src/usr.sbin/lpr/common_source/rmjob.c diff

> Please don't, alarm(3) is perfectly fine to be using. We should > probably remove that line from the manual. The comment of alarm being made obsolete by setitimer has been there for 30 years: https://www.freebsd.org/cgi/man.cgi?query=alarm=0=0=2.10+BSD=default=html NetBSD and FreeBSD also

Re: /usr/src/usr.sbin/lpr/common_source/rmjob.c diff

Hi Theo, Theo Buehler wrote on Wed, Jan 27, 2016 at 12:04:43AM +0100: > Todd Millert wrote: >> Please don't, alarm(3) is perfectly fine to be using. We should >> probably remove that line from the manual. > The comment of alarm being made obsolete by setitimer has been there > for 30 years: >

Re: /usr/src/usr.sbin/lpr/common_source/rmjob.c diff

On Wed, 27 Jan 2016 00:39:04 +0100, Ingo Schwarze wrote: > I would prefer the following patch. > > * Use the same wording up front as for ualarm(3). >It is relevant because alarm(3) and setitimer(ITIMER_REAL, ...) >cancel each other. Without that sentence, people might be misled >

Re: /usr/src/usr.sbin/lpr/common_source/rmjob.c diff

On Wed, Jan 27, 2016 at 12:39:04AM +0100, Ingo Schwarze wrote: > Theo Buehler wrote on Wed, Jan 27, 2016 at 12:04:43AM +0100: > > Todd Millert wrote: > > >> Please don't, alarm(3) is perfectly fine to be using. We should > >> probably remove that line from the manual. > > > The comment of

Re: Simplify tcpdump

Stuart Henderson wrote: > On 2016/01/25 22:52, Michael McConville wrote: > > fddi_bitswap is only used once, and it just adds a layer of > > indirection to its preprocessor condition. > > Oh yuk. This is bogus anyway, and there's no good way to handle it. We > dropped support for FDDI interfaces

Re: Simplify tcpdump

On 2016/01/26 20:16, Michael McConville wrote: > Stuart Henderson wrote: > > On 2016/01/25 22:52, Michael McConville wrote: > > > fddi_bitswap is only used once, and it just adds a layer of > > > indirection to its preprocessor condition. > > > > Oh yuk. This is bogus anyway, and there's no good

Re: Simplify tcpdump

Stuart Henderson wrote: > On 2016/01/26 20:16, Michael McConville wrote: > > Stuart Henderson wrote: > > > On 2016/01/25 22:52, Michael McConville wrote: > > > > fddi_bitswap is only used once, and it just adds a layer of > > > > indirection to its preprocessor condition. > > > > > > Oh yuk. This

Re: Simplify tcpdump

On 2016/01/26 20:52, Michael McConville wrote: > Something like this? Wait to see what others say, but that looks good to me (not yet tested). > There's a lot to be removed from libpcap too. We could kind-of do with updating libpcap. It's not a huge problem yet but we are starting to run into

Re: [diff] lpbl(4): driver for TI LP8550 backlight controller (found in e.g. MacBook Air 6,2)

On Sun, 10 Jan 2016 21:28:31 +0100 Joerg Jung wrote: > On Sun, Jan 10, 2016 at 04:59:22AM +0200, Sviatoslav Chagaev wrote: > > So below is a driver for TI LP8550. ... > > If there's any chance for it to be commited, please tell me what I need to > > fix/improve to get it commited (so I don't have

Re: Simplify tcpdump

On 2016/01/25 22:52, Michael McConville wrote: > fddi_bitswap is only used once, and it just adds a layer of indirection > to its preprocessor condition. Oh yuk. This is bogus anyway, and there's no good way to handle it. We dropped support for FDDI interfaces so it only affect decodes of pcap

Re: Add readonly flag to tftpd

Stuart Henderson writes: > On 2016/01/26 02:06, Matthew Martin wrote: >> I'd bet the most common use case for tftpd is to serve PXE files or >> similar where the files being served should not be modified. I'm failing >> to find a use case where files need to be overwritten,