Hi tech@,
Sending this patch for comment...
CRYPTO_memcmp() is different to memcmp() because it can only check
for equality, not greater-than/less-than.
If we check the string in reverse order we can remove a variable
from the comparison loop.
Does this look ok?
- Michael
Index: cryptlib.c
=
Hi,
I'm re-posting this in hope. :)
http://marc.info/?l=openbsd-tech&m=135698142814632&w=2
Please let me know if I can provide any further info.
- Michael
Hi tech,
I have a minor KNF patch for if_pppoe.c...
Submitting this in case anyone is interested.
- Michael
Index: if_pppoe.c
===
RCS file: /cvs/src/sys/net/if_pppoe.c,v
retrieving revision 1.35
diff -u -r1.35 if_pppoe.c
--- if_ppp
On Thu, Jan 03, 2013 at 09:23:50PM -0800, Philip Guenther wrote:
> On Thu, Jan 3, 2013 at 8:48 PM, Michael W. Bombardieri wrote:
> > I am submitting a patch for awk. "struct Cell" has 7 fields;
> > the final field is an optional "next" pointer.
> ...
> &
Hi,
I am submitting a patch for awk. "struct Cell" has 7 fields;
the final field is an optional "next" pointer.
79 typedef struct Cell {
80 uschar ctype; /* OCELL, OBOOL, OJUMP, etc. */
81 uschar csub; /* CCON, CTEMP, CFLD, etc. */
82 char*nval; /* name, for
Hi,
I am submitting a small patch for pppoe...
The iovec array in send_padi() can contain either 7 or 8 elements.
The following patch declares the array as having size of 8 rather
than 10.
Does this look OK?
- Michael
Index: client.c
===
Hi,
I am submitting a minor patch for sys/net/bpf.c.
* Wrap ROTATE_BUFFERS() macro in do-while according to knf,
so it could be used in an "if" statement
No binary change on i386.
I'm not sure if this is important enough...
- Michael
Index: bpf.c
Hi,
I am submitting a small patch for opencvs...
* Static variable cvs_client_logon is only used in cvs_client_initlog()
so make it local to this function
This is a similar change to annotate.c r1.63.
- Michael
Index: client.c
Hi,
OpenCVS does not agree with the annotation output of
GNU cvs and blame (blame.sourceforge.net).
I discovered this today when trying to use opencvs with cvsweb.
--
Replicating the problem
--
Hi,
I am submitting a patch to convert ppp-deflate.c to ANSI.
No binary change on amd64.
Does this look OK to go in?
- Michael
Index: ppp-deflate.c
===
RCS file: /cvs/src/sys/net/ppp-deflate.c,v
retrieving revision 1.9
diff -u -r1.
Hi,
I have a small patch for if_gre.c...
NULL is already defined as ((void *)0), so we don't
need to cast it to void*.
No binary change on amd64.
Does this look OK?
- Michael
Index: if_gre.c
===
RCS file: /cvs/src/sys/net/if_gre.
Hi,
I am submitting a patch for sys/crypto/sha2.c...
I guess we want to include variables s0 and s1
in the clean-up statement at the end of SHA256Transform()
and SHA512Transform(). These variables are used by the
macros ROUND256() and ROUND512(), as well as the message
block expansion section of
Hi Tech,
I have a small msdosfs patch...
Error cases are handled inconsistently in msdosfs_mount().
Some cases use the construct "if (error) goto error;",
others just return error immediately.
The following patch removes the goto label and makes the
function return error consistently.
Does this
Hi Tech,
In ntfs_access(), 'mask' is being built up in
three different places. From what I can see
'mode' doesn't change within this function,
so can't we simply set 'mask' once before
checking owner, groups and everyone?
Comments?
- Michael
Index: ntfs_vnops.c
=
Hi Tech,
I have a small ppp diff...
At the top of function ppp_ccp() we check
m->m_len against PPP_HDRLEN. After accessing
m_next we return if the new mp value is NULL.
Immediately after that, we check mp for NULL
again.
The following patch removes the duplicate check.
Does this look OK?
- Mich
On Mon, Jul 02, 2012 at 11:18:21PM -0400, David Higgs wrote:
> On Mon, Jul 2, 2012 at 10:49 PM, Michael W. Bombardieri wrote:
> > On Tue, Jul 03, 2012 at 02:03:39AM +, Dave Hart wrote:
> >> On Tue, Jul 3, 2012 at 01:49 UTC, Michael W. Bombardieri
> >> wrote:
On Tue, Jul 03, 2012 at 02:03:39AM +, Dave Hart wrote:
> On Tue, Jul 3, 2012 at 01:49 UTC, Michael W. Bombardieri wrote:
> > Sorry, my fault. The intent was bitwise-and not bitwise-or.
> > Third version of the diff follows.
> > In regards to hand optimisations, we could
On Tue, Jul 03, 2012 at 12:42:45AM +, Dave Hart wrote:
> On Mon, Jul 2, 2012 at 01:41 UTC, Michael W. Bombardieri wrote:
> > On Sun, Jul 01, 2012 at 11:04:31AM -0400, Ted Unangst wrote:
> >> I had trouble finding a decent file where there was a difference,
> >>
On Sun, Jul 01, 2012 at 11:04:31AM -0400, Ted Unangst wrote:
> On Sun, Jul 01, 2012 at 11:17, Tobias Stoeckmann wrote:
> > Your patch breaks this compatibility for every branch except the initial
> > one. GNU CVS is not consistent about its behavior in many ways.
> >
> >> Ha! This is the same bug
Hi tech,
I noticed this OpenCVS bug a couple of months ago but I've
only just written this report.
Comparing "cvs log" output between GNU CVS 1.11.1p1 and OpenCVS...
$ diff -U 6 log_c.h_cvs log_c.h_ocvs
--- log_c.h_cvs Sun Jul 1 07:08:57 2012
+++ log_c.h_ocvsSun Jul 1 07:09:10 2012
@@
Hi tech,
Is anyone interested in this diff? I was reading
hexdump(1) code and I noticed a couple of simplifications.
* In emalloc(), replace malloc/memset with calloc
* In parse.c and hexdump.c, replace malloc with emalloc
* Side effect: in parse.c we don't need to NUL-terminate
the strings cop
Hi tech,
I noticed that parts of src/sys/crypto use
explicit_bzero() for cleaning up key data, e.g.
line 119 of cmac.c.
I am not very familiar with this code, but it
appears one loop in cast_setkey() could be replaced
with explicit_bzero(). Would there be any
value in doing this?
- Michael
Inde
Hi tech,
I previously raised a bug in PCC because make(1)
would not build correctly under pcc-i386:
http://pcc.ludd.ltu.se/jira/browse/PCC-381
The JIRA ticket was recently closed.
This morning I re-tested the build and make(1)
no longer segfaults when used to build itself.
Side note:
PCC choke
Hi tech,
I have a simple diff for ksh(1) which takes
care to not read past the end of the static
buffer 'holdbuf' where the length of 'pat'
is greater than the buffer.
Does anyone think this is worthwhile? If not,
should we remove the XXX comment altogether?
- Michael
Index: vi.c
=
On Fri, Nov 11, 2011 at 12:02:14PM -0500, Ted Unangst wrote:
> I don't see any reason to even open the file if the size is 0.
>
> On Fri, Nov 11, 2011, Michael W. Bombardieri wrote:
> > Sorry, let me try that again... Forgot to clean up file descriptor ifd.
> &
Sorry, let me try that again... Forgot to clean up file descriptor ifd.
Index: inp.c
===
RCS file: /usr/src/cvs/src/usr.bin/patch/inp.c,v
retrieving revision 1.35
diff -u -r1.35 inp.c
--- inp.c 27 Oct 2009 23:59:41 - 1
On Thu, Nov 10, 2011 at 11:10:34PM -0600, Abel Abraham Camarillo Ojeda wrote:
> On Thu, Nov 10, 2011 at 9:26 PM, Michael W. Bombardieri wrote:
> > Hi tech,
> >
> > I have a diff for the patch(1) tool which copies
> > one included in NetBSD two years ago...
> >
>
Hi tech,
I have a diff for the patch(1) tool which copies
one included in NetBSD two years ago...
Source: NetBSD src/usr.bin/patch/inp.c revision 1.23
Purpose: Don't bother mmap'ing an empty file
Comments/OK?
- Michael
Index: inp.c
=
Hi tech,
Is anyone interested in this diff?
The function declarations of lex(1) are ansified,
as done in yacc(1) years ago.
I've tested it on OpenBSD/i386 4.9 on a number of lex source files
in src/usr.bin. Comments?
- Michael
Index: ccl.c
==
On Wed, Sep 21, 2011 at 04:35:21PM +0200, Pascal Stumpf wrote:
> On Wed, Sep 21, 2011 at 08:23:11PM +0800, Michael W. Bombardieri wrote:
> > Hi Pascal,
> >
> > Thanks for your email.
> > Your diff works for clang, but my pcc produces a make binary that doesn'
:38:31AM +0200, Pascal Stumpf wrote:
> On Wed, Sep 21, 2011 at 10:43:20AM +0800, Michael W. Bombardieri wrote:
> > Hi all,
> >
> > I noticed that the make(1) build is broken for non-gcc compilers.
> > The following diff stops the build from breaking for pcc and llvm/clang.
Hi all,
I noticed that the make(1) build is broken for non-gcc compilers.
The following diff stops the build from breaking for pcc and llvm/clang.
Comments?
- Michael
Index: targ.h
===
RCS file: /usr/src/cvs/src/usr.bin/make/targ.h
Hi all,
This is a code readability patch for openrcs (src/usr.bin/rcs/rlog.c). I
previously sent this to nicm@ but he didn't have time for it.
Any comments?
- Michael
--- rlog.c 2010/07/30 21:47:18 1.64
+++ rlog.c 2011/06/30 05:40:10
@@ -493,13 +493,16 @@
}
Hi all,
This is a code readability patch for openrcs (src/usr.bin/rcs/rlog.c). I
previously sent this to nicm@ but he didn't have time for it.
Any comments?
- Michael
--- rlog.c 2010/07/30 21:47:18 1.64
+++ rlog.c 2011/06/30 05:40:10
@@ -493,13 +493,16 @@
}
101 - 134 of 134 matches
Mail list logo