exclude-list in mtree (2)

Hi, In the previous patch, I forgot to check for excluded files at verification time (duh). I also add the name of the excluded files list into the mtree output so it can be retrieved later (e.g. in /usr/libexec/security). Index: Makefile

Re: exclude-list in mtree (2)

Same with patch inline: Index: Makefile === RCS file: /cvs/src/usr.sbin/mtree/Makefile,v retrieving revision 1.9 diff -u -p -r1.9 Makefile --- Makefile15 Apr 2013 06:25:18 - 1.9 +++ Makefile20 Jun 2014 12:45:35 -

Re: compare memcmp with 0

Hi Theo, Theo de Raadt wrote on Thu, Jun 19, 2014 at 09:58:01PM -0600: It could be argued that the bcmp manual page does a poor job documenting this. It should use the mandoc blink tag. OK? It's not perfect yet because when you nest blink tags, it already switches back to non-blinking mode

Re: exclude-list in mtree (2)

On Fri, Jun 20, 2014 at 04:34:19PM +0200, Manuel Giraud wrote: + lbuf = NULL; + while ((buf = fgetln(fp, len))) { + if (buf[len - 1] == '\n') { + if (len == 1) + continue; + buf[len - 1] = '\0'; +

Re: compare memcmp with 0

OMFG.. Ingo you just made my morning. I'm laughing so hard. And I needed the laugh -Bob On Fri, Jun 20, 2014 at 04:54:15PM +0200, Ingo Schwarze wrote: Hi Theo, Theo de Raadt wrote on Thu, Jun 19, 2014 at 09:58:01PM -0600: It could be argued that the bcmp manual page does a poor job

Re: exclude-list in mtree (2)

Tobias Stoeckmann tob...@stoeckmann.org writes: On Fri, Jun 20, 2014 at 04:34:19PM +0200, Manuel Giraud wrote: +lbuf = NULL; +while ((buf = fgetln(fp, len))) { +if (buf[len - 1] == '\n') { +if (len == 1) +continue; +

Re: 8 port serial card connections

On 2014-06-20 Fri 16:14 PM |, Maurice Janssen wrote: # FIXME No. 9 Moxa card port: moxa09:dv=/dev/tty10:common: # FIXME No. 10 Moxa card port: moxa10:dv=/dev/tty11:common: Try /dev/tty0a and /dev/tty0b Perfect! Here's a man page diff to sync with lines 1383-1397 of

gcc: warn about overly aligned stack variables

GCC supports an aligned attribute to specify a minimum alignment for types/objects. However, if an object is allocated on the stack and its alignment exceeds the preferred stack boundary, then GCC 4.2 silently ignores the alignment. This bit us 4 years ago when the SCSI stack started allocating

boringssl and such

Few things to note... I suspect everyone working on LibReSSL is happy to hear the news about BoringSSL. Choice is good!! Their priority is on safety, not on ABI compatibility. Just like us. Over time, I suspect google's version will also become 'reduced API', since they require less legacy