Re: [patch] file(1) determine file type of stdin

> On Fri, May 29, 2015 at 11:31:37PM +0100, Nicholas Marriott wrote: > > Hi > > > > We deliberately do not support FIFOs because they will block forever if > > nothing is writing and using file(1) on FIFOs seems unnecessary, the old > > file(1) had a hack to get around this with poll(2) but we're

Re: [patch] file(1) determine file type of stdin

Oops, this was wrong, sorry - try this instead: Index: file.1 === RCS file: /cvs/src/usr.bin/file/file.1,v retrieving revision 1.41 diff -u -p -r1.41 file.1 --- file.1 27 Apr 2015 11:12:49 - 1.41 +++ file.1 29 May 2

Re: [patch] file(1) determine file type of stdin

Hi We deliberately do not support FIFOs because they will block forever if nothing is writing and using file(1) on FIFOs seems unnecessary, the old file(1) had a hack to get around this with poll(2) but we're not going to do that. So I think we should only allow FIFOs for stdin where people presum

Re:

> Hey Darren, misc@ is for the trolls, so I moved this to tech@. But using a vr(4) device is a troll in itself.

Re:

> Date: Thu, 28 May 2015 21:05:34 +1000 > From: Darren Tucker > > Hi. Hey Darren, misc@ is for the trolls, so I moved this to tech@. > Overwriting valid tte entry (dva c00a2000 pa 32a1e000 &tte 0x40016f3e288 tte > 800032a20012) I think this means that the tx slot was reused without bus_dm

Re: [patch] file(1) determine file type of stdin

On Fri, May 29, 2015 at 12:27:16PM +0100, Nicholas Marriott wrote: > Here is a slightly tweaked version of your diff. > I am not completely ok (see below) > Index: file.c > === > RCS file: /cvs/src/usr.bin/file/file.c,v > retrieving

ALPN no_application_protocol

I have looked at libressl source code and it does not look like the no_application_protocol(120) is implemented. Openssl also does not yet support this portion of the ALPN spec ( https://tools.ietf.org/html/rfc7301#section-3.2) but it seems the issue is now being reprioritized (https://github.com/

Re: [PATCH] libcrypto: initialize pointer

On Friday 29 May 2015, Benjamin Baier wrote: > Hello tech@ > > buf.data is not initialized up front, which may lead to free(3)'ing a > garbage pointer. Found by llvm/scan-build. > Also free(3) handles NULL. No need to check. At first glance this is not actually a real problem - free_cont is initia

Re: [patch] file(1) determine file type of stdin

Whoops, you're right there. I think it is a leftover, I don't think it is the right thing to do. On Fri, May 29, 2015 at 01:32:12PM +0200, S??bastien Marie wrote: > On Fri, May 29, 2015 at 12:00:36PM +0100, Nicholas Marriott wrote: > > Hi > > > > Why do you want to set O_NONBLOCK at all? > > >

Re: [patch] file(1) determine file type of stdin

On Fri, May 29, 2015 at 12:00:36PM +0100, Nicholas Marriott wrote: > Hi > > Why do you want to set O_NONBLOCK at all? > > > } else { > > fd = open(argv[idx], O_RDONLY|O_NONBLOCK); > > if (fd == -1 && (errno == ENFILE || errno == EMFILE)) Becaus

Re: [patch] file(1) determine file type of stdin

Here is a slightly tweaked version of your diff. I don't think we need to set O_NONBLOCK, we don't set it for anything else. Index: file.1 === RCS file: /cvs/src/usr.bin/file/file.1,v retrieving revision 1.41 diff -u -p -r1.41 file.

Re: [patch] file(1) adjust size in fill_buffer

Good spot - fixed, thanks. On Fri, May 29, 2015 at 12:27:19PM +0200, S??bastien Marie wrote: > Hi, > > While working on file(1) for permit standard input type determination, I > investigate why when /dev/stdin is used, the output was 'data'. > > It seems that the fill_buffer function don't adju

Re: [patch] file(1) determine file type of stdin

Hi Why do you want to set O_NONBLOCK at all? On Fri, May 29, 2015 at 12:32:06PM +0200, S??bastien Marie wrote: > On Thu, May 28, 2015 at 11:52:22PM +0100, Nicholas Marriott wrote: > > Hi > > > > Can you make a patch against -current? Your source tree seems pretty out > > of date. > > arg, my b

Re: [patch] file(1) determine file type of stdin

On Thu, May 28, 2015 at 11:52:22PM +0100, Nicholas Marriott wrote: > Hi > > Can you make a patch against -current? Your source tree seems pretty out > of date. arg, my bads. > Yes please check the return values from fcntl and fstat. I added check for fstat, but not for fcntl. The problem with

[patch] file(1) adjust size in fill_buffer

Hi, While working on file(1) for permit standard input type determination, I investigate why when /dev/stdin is used, the output was 'data'. It seems that the fill_buffer function don't adjust inf->size to readed buffer. So the test_file function may operate on larger buffer than expected, consid

[PATCH 3/3] fsck(8): no need to assign variable twice

This got me looking at the code first. No need to assign argc and maxargc twice. Found by llvm/scan-build --- fsck.c.p1 Fri May 29 11:01:25 2015 +++ fsck.c Fri May 29 11:02:18 2015 @@ -449,9 +447,6 @@ mangle(char *opts, int *argcp, const cha char *p, *s; int argc = *argcp,

[PATCH 2/3] fsck(8): no need to check for NULL before free(3)

No need to check for NULL before free(3) Fri May 29 10:59:23 CEST 2015 /git/hellfish/src/sbin/fsck Index: fsck.c === RCS file: /cvs/src/sbin/fsck/fsck.c,v retrieving revision 1.35 diff -u -p -r1.35 fsck.c --- fsck.c 18 Apr 2015 1

[PATCH 1/3] fsck(8): adjust error logic for recent erealloc to ereallocarray switch

Hello tech@ adjust error logic for zero sized allocations and the error messages for the recent erealloc to ereallocarray switch. A follow up diff will clean up all "if (x) free(x);" statements. Index: fsutil.c === RCS file: /cvs/s

[PATCH] libcrypto: initialize pointer

Hello tech@ buf.data is not initialized up front, which may lead to free(3)'ing a garbage pointer. Found by llvm/scan-build. Also free(3) handles NULL. No need to check. Index: tasn_dec.c === RCS file: /cvs/src/lib/libssl/src/crypto/