Hi tech@,
Here's an indentation fix for libcrypto (the while in the context is actually
a do/while) and a spelling fix for a comment in pf.
Index: lib/libcrypto/bn/bn_sqrt.c
===================================================================
RCS file: /cvs/src/lib/libcrypto/bn/bn_sqrt.c,v
retrieving revision 1.7
diff -u -p -r1.7 bn_sqrt.c
--- lib/libcrypto/bn/bn_sqrt.c 8 Nov 2016 01:40:22 -0000 1.7
+++ lib/libcrypto/bn/bn_sqrt.c 22 Nov 2016 00:30:54 -0000
@@ -256,7 +256,7 @@ BN_mod_sqrt(BIGNUM *in, const BIGNUM *a,
}
while (r == 1 && ++i < 82);
- if (r != -1) {
+ if (r != -1) {
/* Many rounds and still no non-square -- this is more likely
* a bug than just bad luck.
* Even if p is not prime, we should have found some y
Index: sys/net/pf.c
===================================================================
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1000
diff -u -p -r1.1000 pf.c
--- sys/net/pf.c 21 Nov 2016 15:23:18 -0000 1.1000
+++ sys/net/pf.c 22 Nov 2016 00:31:09 -0000
@@ -4257,7 +4257,7 @@ pf_tcp_track_full(struct pf_pdesc *pd, s
* (Selective ACK). We could optionally validate the SACK values
* against the current ACK window, either forwards or backwards, but
* I'm not confident that SACK has been implemented properly
- * everywhere. It wouldn't surprise me if several stacks accidently
+ * everywhere. It wouldn't surprise me if several stacks accidentally
* SACK too far backwards of previously ACKed data. There really aren't
* any security implications of bad SACKing unless the target stack
* doesn't validate the option length correctly. Someone trying to
