+ while (n-- 0)
+ x |= a[n] ^ b[n];
Won't compare the bytes at [0].
Uh? It will, n gets decremented after the test but before the x |=
statement.
I think switching this to be
timingsafe_bcmp would be better, then we only have copy.
Agreed.
Same as the others, this time with src/usr.bin/mg/undo.c
You are now losing a memset() in the `rec doesn't come from malloc' code
path.
Index: undo.c
===
RCS file: /cvs/src/usr.bin/mg/undo.c,v
retrieving revision 1.55
diff -u
There's one test that fails, I haven't investigated it.
==
FAIL: test_digest (__main__.X509Tests)
--
Traceback (most recent call last):
File
* remove unnecessary temp variable d
* move loop counter j in for() header
* fix prototype for memcpy
* make calculation of actual length in BN_to_ASN1_ENUMERATED
more transparent
This code still looks rather odd, it uses a temporary buffer to first
convert the number into a minimal
I got a bit bored, so I decided to help in the springcleaning of
libssl. I removed some seemingly harmless WIN32 defines.
Applied (well, the parts which still applied), except for the
crypto/conf/ part for which I have a larger cleanup diff pending.
ps. How many ways to define an int64 are
Speaking for myself here, but as far as LibreSSL is concerned, I'd say
my opinion has a certain weight.
- The accelerated assembly code for the crypto, is that gonna stay?
Yes. Including existing code for platforms OpenBSD itself does not run
on (e.g. s390).
- Why not use uint32_t and
I'm not comfortable with introducing more sys/queue.h APIs. So
perhaps we should just punt on the optimization and remove/insert all
list items. Removing the trap comments that pedro set up...
Since the removal macros poison pointers which should no longer be
dereferenced after the
Hi,
Some more cleanup on top of my previous patch with e-mail subject
libssl pqueue minor cleanup - no functional change intended.
Applied, thanks!
Miod
Hi,
I notice a typo since revision 1.3 by miod@, correction below::
Oops. Fixed. Thanks!
Miod
... or, in other words, try to fix most memory leak upon failure.
This kind of change is difficult to test, the more eyes reviewing it,
the better.
Miod
Index: a_gentm.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_gentm.c,v
I have not found a complete list with this information. Can someone tell
me what OpenBSD platforms grow the stack upwards?
grep MACHINE_STACK_GROWS_UP /usr/src/sys/arch/*/include/param.h
... or, in other words, try to fix most memory leak upon failure.
This kind of change is difficult to test, the more eyes reviewing it,
the better.
Well, I'll try to take a stab at it then.
You might be able to use ASN1_STRING_set(ret, NULL, len) to handle
resizing / allocating the
As promised, here is a new diff. Bob Beck suggested introducing wrappers
to the time-related functions, so that the error path becomes easier to
understand; this makes the diff to these functions much simpler indeed.
Index: a_gentm.c
Index: a_time.c
+ASN1_GENERALIZEDTIME *
+ASN1_TIME_to_generalizedtime(ASN1_TIME *t, ASN1_GENERALIZEDTIME **out)
+{
+ ASN1_GENERALIZEDTIME *tmp = NULL, *ret;
+
+ if (!out || !*out) {
+ if (!(tmp = ASN1_GENERALIZEDTIME_new()))
+ return NULL;
+
Hi all,
* No need to check for NULL before free.
* No need to cast the return value of the allocation functions.
* Do not use malloc() + memset(), simply use calloc()
Tested against the regression tests for pqueue.
ok?
Applied. Thanks!
Hello,
After reading
http://www.openbsd.org/papers/bsdcan14-libressl/mgp00015.html , I
thought I'd help a bit with cleaning libssl by running this
Coccinelle[1] script on src/lib/libssl:
smpl
@@
identifier x;
@@
-if (x) { free(x); }
+free(x);
/smpl
It removes unnecessary NULL
Is this the correct way to go about adding a sub-keymap to place
the VT switch commands on dedicated keys?
Yes, this ought to work. You'll need to run `make includes' and
recompile sbin/kbd and/or sbin/wsconsctl for them to grok `.term122' as
a keymap suffix.
Miod
ok. Note this codepath is not compiled under OpenBSD.
Index: src/lib/libssl/src/crypto/bio/bss_dgram.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/bio/bss_dgram.c,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 bss_dgram.c
Hi All,
From OpenSSL RT:
http://rt.openssl.org/Ticket/Display.html?id=3278user=guestpass=guest
len can be 0 as well, and in which case, memory isn't freed.
Correct. If successful, data is actually a malloc(len + 1), thus if
len == 0, we leak a \0 byte...
Patch from Frantisek Boranek:
Matthew, you obviously did not spot the evil 9p/util.h yet. This file
ought to be named ozymandias.h.
Also, I am vetoing the addition of -fms-extensions to the kernel build
options. Whatever files require this option to build needs to be fixed
to be proper, unambiguous, C99, instead.
Now you have and example of how they are unwilling to work with you next
time someone asks why not work with OpenSSL on fixing it. Pretty direct
proof.
The culture gap between OpenSSL and OpenBSD/LibreSSL is UNFIXABLE.
We believe in peer review; they don't give a sh*t about it (as shown
less
From Quanah Gibson-Mount:
UNKOWN-UNKNOWN
Index: crypto/asn1/asn1_err.c
Please refrain from sending diffs you obviously didn't test.
Miod
Hello,
I just noticed r1.44 to t1_lib.c. I'm not sure that auditing
opaque_prf_input is a good use of anyone's time -- I think it might be
better to just run unifdef -U TLSEXT_TYPE_opaque_prf_input and be done
with it.
Here's the history of opaque_prf_input as I understand it:
- In
Miod Vallat m...@online.fr writes:
You're right. What about the following diff? (major bump for libssl)
Looks OK to me. There's also a few tendrils in regress:
Indeed. Applied, thanks!
Followings are our kernel variables' default:
- sb_max: 256K
- tcbhash_size: 128
- udbhash_size: 128
These variables are sometime too small for busy server or gateway.
I'd like to modify config(8) to customize these variables without
recompiling the kernel.
If we go this
While you're there, all alloc error paths need to free sktmp and
whatever else is done at `end:'. But I am not sure the
X509_get_pubkey_parameters() needs to be performed upon error as well,
despite the code disagreeing with me.
I mean, I would investigate, but my glasses just turned dark on me.
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.
[...]
Since newer GCC properly support overly aligned
Both diffs applied, thanks!
Even though we are seriously considering removing the srp code
altogether, it does not hurt to make things better, one bug at a time.
Miod
On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote:
CVSROOT:/cvs
Module name:src
Changes by: guent...@cvs.openbsd.org2014/07/10 08:29:03
Modified files:
usr.bin/rdist : common.c config-data.h
Log message:
Assume POSIX: write() takes
it. As expected, OPENSSL does the opposite and makes life harder for
everyone.
Hasn't this been the OpenSSL roadmap since the very beginning?
I didn't know what egd was up until today, but reading what it is I
completely understand that consideration. However, this breaks a number
of packages (wget, python, ruby).
There's probably a simple solution: Just add dummy functions that
always return -1 (which according to the docs means
I recently used cppcheck on mg and I got this message:
[macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice.
Looking at the code:
/* free lines allocated for string arguments */
if (maclhead != NULL) {
for (lp1 = maclhead-l_fp; lp1 != maclhead; lp1 = lp2) {
The newly-added /tests/asn1test fails to complete successfully under
Linux when built as 32-bit object, in either a 32-bit userspace
or on a multiarch.
Indeed; the test was not 32-bit friendly. A length of 340 is correct in
that case; I have fixed the test so that it behaves the same way on
I have been pointed that I did not formulate the question clearly.
Would you prefer to have a static ENGINE thing built into the LibreSSL,
providing 100% API compatibility with original ccgost implementation,
or it would be better to have a cleaner well-integrated cryptosuite?
As already
Hi,
I think is a bug in sys/dev/ic/mfi.c noticed during
PATCH: further kernel malloc - mallocarray review[1]
I see the mallocarray() patch seems to have been applied.
Want to make sure if this is in fact a bug, that it is
not overlooked.
Ignore if this is noise.
That diff looks
The regression tests under randomdata do not work. They must build
libaa before running. libaa doesn't have a target for regress so
even though it's a SUBDIR in ../Makefile, it doesn't do anything.
They do; the magic to build libaa comes from
regress/libexec/ld.so/randomdata/Makefile.inc .
Applied, thanks!
Index: regress/sys/kern/rcvtimeo/rcvtimeo.c
===
RCS file: /cvs/src/regress/sys/kern/rcvtimeo/rcvtimeo.c,v
retrieving revision 1.4
diff -u -p -r1.4 rcvtimeo.c
--- regress/sys/kern/rcvtimeo/rcvtimeo.c 2 Sep
REGRESS_SKIP_SLOW didn't work as intended. Default is no yet it checks
for !empty.
Good catch! Applied, thanks.
Added t-exhaust as slow because it takes 90 minutes on my recent CPU.
That's odd. This test only takes a few seconds on an amd64 system. Do
you have any local changes to libc, or
I have a log from a partial run of 'make regression-tests' (I hit a bug
in kqueue which hangs indefinitely) and it showed up as failing. I went
into libexec/ld.so/randomdata and ran 'make depend regress' and it doesn't
work without that patch.
It would get built if something called 'make'
That's odd. This test only takes a few seconds on an amd64 system. Do
you have any local changes to libc, or any particular /etc/malloc.conf
settings, which could explain the slowdown?
Ahh you caught me. Yes, I had /etc/malloc.conf settings. I'll try it
again without those settings. I
Ah, I see; you're running `make regress' ; simply running `make' should
work correctly (it implies building, and the running the regress target,
when Makefile includes bsd.regress.mk).
Ah, I see; you're running `make regress' ; simply running `make' should
work correctly (it implies building, and the running the regress target,
when Makefile includes bsd.regress.mk).
That would fix it for the local case inside of /usr/src/regress. Wouldn't
it still be an issue at the
For GOST cipher code I'd like to add several error locations and
definitions. Original OpenSSL did so by running mkerr.pl utility.
However I could not find hooks to run mkerr.pl either in LibreSSL
itself or in -portable version of it.
What would be the best way for me to add error
First, I have a question regarding implementation of GOST public key
cryptography.
Is it OK to add dependency GOST = EC? It will allow me to reuse EC
infrastructure
for GOST public key cryptography (GOST R 34.10-2001 and -2012 use ECC)?
Yes. We aren't fond of unnecessary ifdefs, and EC
Hiding a lot of sys/pool.h from userland breaks the build of the
extent test in regress/sys/kern/extent on amd64. Additionally, tedu's
added size variable in free(9) breaks the userland macros in
sys/kern/subr_extent.c. The following patch addresses these two issues.
Actually, the extent
If the queue is to be used as a linear list, invoking insque(element,
NULL), where element is the initial element of the queue, shall
initialize the forward and backward pointers of element to null
pointers.
Hmm. Do the vax ASM versions of these functions need changes to support
Why not keep the softdep flag when updating rw-ro?
E.g. via mount -ur /usr/obj
fstab(5) already allows ro+softdep.
Because if we were to apply this diff, there would be no way to switch
from rw+softdep to rw.
Because if we were to apply this diff, there would be no way to switch
from rw+softdep to rw.
That was already broken; rw-rw is not affected as per the enclosing
if-block.
Which is why the current way to remove softdep from a filesystem is a
rw+softdep - ro - rw transition, which would no
Which is why the current way to remove softdep from a filesystem is a
rw+softdep - ro - rw transition, which would no longer work with your
diff.
It would work, but you'd have to explicitly disable softdep, as one might
expect to be required when removing softdep:
Oh, indeed.
Then it's a
+++ b/sys/dev/pci/vioblk.c
@@ -63,6 +63,7 @@
#include scsi/scsi_disk.h
#include scsi/scsiconf.h
+#define MINPHYS (20*1024)
This makes no sense. If you want to override MINPHYS, you need to
override for the whole kernel, not only here.
@@ -157,6 +158,8 @@
+#define MINPHYS (20*1024)
This makes no sense. If you want to override MINPHYS, you need to
override for the whole kernel, not only here.
MINPHYS is just a name I have chosen. It is not used anywhere else in the
kernel. You are confusing this with MAXPHYS.
Oops, you're
I was looking at the recently imported uuid interface in libc and
noticed the encode functions are broken. In particular, this pattern:
uint8_t *p = buf;
p[0] = htobe32(uuid-time_low);
p[4] = htobe16(uuid-time_mid);
p[6] = htobe16(uuid-time_hi_and_version);
The
My question is more about the driver itself, it did not change a lot
since 1994 , while netbsd apparently move to a complete different
driver :
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ppbus/?only_with_tag=HEAD
Are those driving the same chipset family ?
any info on that ?
ppbus
The RealTek 8129 should be supported by the rl(4) driver, and is
AFAICT included in the RAMDISK kernel. Not sure why it doesn't
attach. If it is easy to hook up QEMU's e1000 hardware emulation to
the emulated sparc64 hardware, that should be supported as well on the
OpenBSD side.
Nothing a
Interesting. Longer term the aim of the QEMU project is to move the
hardwired machine types into pluggable devices, e.g. you can build a whole
machine on the command line from multiple -device parameters or preload the
default machine types such as sun4u using instructions from a file. So
Currently there are three instances of ASN methods
and pmethods structures, because there three
different OIDs related to GOST public keys
(-2001, -2012, 256 bit, -2012 512 bit).
I think I can merge all of them. However I need
to store an additional NID (digest NID, which
is a part of
shmctl(2)/shmget(2)/shmat(2) all document
#include sys/types.h
#include sys/ipc.h
#include sys/shm.h
as a requirement for calling these functions.
That was my first thought, but according to
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_ipc.h.html
``The sys/ipc.h header
That main function is good, standard style.
Unnecessary goto,
There is only one goto in chmod.c. If you consider it unnecessary, I'd
advise you to read the code again, and pay attention to the comment
explaining that particular chunk. (Hint: you can't break from more than
one control
groupdel(8) will complain (and delete) lines which do not have exactly
three colon characters in them. This is annoying in yp environments
where the last line of /etc/group is usually a single `+' character,
which is equivalent to `+:*::'
Invoking groupdel when /etc/group contains a final `+'
[snip rant]
Do people run this crap as root? I wonder. I certainly don't.
Then you might want to suggest an alternative to pkg_delete's
``You should also run /usr/sbin/groupdel _foo'' messages.
Two weeks has passed. Is there anything that I can do to
push GOST ciphers towards LibreSSL?
Sorry about that. Joel and/or I need to review the diff again and push
it. I'll try to find time for this next week-end (famous last words).
Miod
This is suspicious person for me (group of people?). There are lots of
commits since about 2011 in many low-level and/or critical components
from this person: linux kernel, android, gnupg, tcpdump, alsa, tor,
openssl etc, etc..
I'm almost certainly wrong, but not too much there competencies
The libcrypto parts of the GOST ciphers have been commited, and barring
any objection from the usual LibreSSL suspects, will be enabled in the
not-so-far-away future.
The libssl parts are still under consideration. I have one concern and
one question about them:
- I understand from the ``FIXME
... and while I'm mopping this code, I believe the following change is
correct:
Index: gostr341001_pmeth.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/gost/gostr341001_pmeth.c,v
retrieving revision 1.4
diff -u -p -r1.4
- I understand from the ``FIXME IANA'' comments that the various cipher
and extension IDs used by GOST are not official yet. Are these values
generally agreed upon by the websites which serve content using GOST
algorithms?
These values are provided as 'temporal private values till
The following diff attempts to polish the GOST code in libcrypto and add
many missing error checks (probably not exhaustive, but a good start).
A few KNF changes are included because I'm a tad too lazy to manually
split the diff at this point...
Important changes are mostly:
- VKO_compute_key()
The following diff attempts to polish the GOST code in libcrypto and add
many missing error checks (probably not exhaustive, but a good start).
I knew that I'm not perfect, but I didn't know the depth of my
imperfectness...
Well, most of these shortcomings are also present in the
Thanks.
Looking again I saw no obvious issues.
\o/
+ if (EC_GROUP_get_order(group, order, ctx) == 0) {
+ /*
+* XXX EC_GROUP_get_order() will return 0 if successful
but
+* XXX order == 0. But then BN_mod below would fail
- p-p_sigmask = mask ~ sigcantmask;
+ p-p_sigmask = mask;
On the right architecture where a word store isn't atomic enough and
with the right compiler that decides to put p_sigmask on an address
ending with 0xFFF with 4k-sized pages, we have two problems already.
Holy
So here's the same diff without the negative 0.0 change.
Update which:
- marks some functions as __dead (instead of upstream
__attribute__((__noreturn__)))
- fixes split(a[1], a).
ok?
FIXES still lists the setfval change, which you did not include. It
would make sense to omit this chunk
Not really. Cloneable devices are used to create per-open context.
well, it seems to me that having a limit on the number of devices like usb
stuff or something is somewhat wasteful. It would probably be nicer if it
could adjust automatically (note that I have no idea how much more work
I was porting over some freebsd kernel code and came across a struct
rman and some rman_* utility functions, defined in fbsd's sys/rman.h .
Does obsd have an equivalent interface?
The ``get some ranges from a global resource'' functionality is achieved
under OpenBSD by using extent(9).
The
Since the switch to 64-bit time_t, our tar(1) can not archive files
which timestamp are before 1970.
Assuming these files:
$ ls -l *gz
-rw-r--r-- 1 miod dmg 34827 Jul 1 1904 comandr.mod.gz
-rw-r--r-- 1 miod dmg 119280 Dec 3 1969 gbusa.mod.gz
tar will fail to archive them:
$ tar cf -
The only caller of kcopy is uiomove. There is no way a function like
this can ever work. If you need to rely on your copy function to save
you from pointers outside the address space, it means you don't know
what garbage you're passing it. Meaning you may well be passing it
pointers inside
Yes, we remove about 10 of the architectures. We'd slowly lose the
developers who like to work on those areas. They also work in other
areas, but ... I suspect they would another BSD that supports them.
Darn' tootin'!
Anyone want to suggest we hold a bake sale?
Make that a lo-carb bake
And it's not full emulator if it doesn't emulate the
bugs.
It's almost bedtime in Europe. Do you mind if I tell you a bedtime
story?
Years ago, a (back then) successful company selling high-end Unix-based
workstations, having been designing its own systems and core components
In order to make the sparc64 iommu code mpsafe, I need to make sure
the extent manager can be used in an mpsafe manner. The current code
isn't really safe since the extent manager needs to allocate region
descriptors whenever we do a bus_dmamap_load(). The diff below adds a
function to
[cc: tech@, reply-to set to tech@]
After suspend or hibernate, I lose my designated console keyboard layout
(sv) and it reverts to the default (us?) wsconsctl shows that the
encoding to still be sv,
keyboard.encoding=sv
What setting(s) am I missing to preserve the designated
Couple of questions:
1. What if starting from this state:
$ wsconsctl 2/dev/null |grep encoding
keyboard.encoding=us
keyboard1.encoding=is
keyboard2.encoding=uk
you unplug the Icelandic and Sun UK keyboards. Next attach
first the Sun UK keyboard and next the
A fix has been committed, but there's still a problem on loongson with
libm updated:
$ ls -l /usr/lib/libm.so.*
-r--r--r-- 1 root bin 926033 Feb 12 12:17 /usr/lib/libm.so.9.0
$ cc -o expl expl.c -O2 -pipe -lm
$ for in in 1 2 3 4 5 6 ; do ./expl ; done
theta == 1, pr == -9.15569e-2474,
...for controlling the display backlight the appropriate utility is
wsconsctl:
$ wsconsctl display.brightness
display.brightness=100.00%
$ wsconsctl display.brightness=50
display.brightness - 50.00%
To make this work, your driver has to provide the ws_get_param and
ws_set_param hooks.
A fix has been committed, but there's still a problem on loongson with
libm updated:
[...]
This is definitely a problem in gdtoa. The values are always computed
the same, but do not get printed correctly, as shown by this modified
test program. Both lines should print 0.606531 for the
Our vm system has some optimization logic which, when servicing a page
fault, attempts to fault the neighbouring pages, if this is expected to
speed things up on the long term.
That logic is controlled by the madvise() state of the memory area being
faulted in, with the defaults being that device
These calculations strike me as weird. Also, I think there's a bug.
nback should always be the -1 value, right? Oh, wait, it was like
that. Even stranger.
I think the nback = 8 nforw = 7 was a bug, to begin with, but this diff
attempts to first reach a status quo, for 4KB page size platforms.
On Sun, Mar 23, 2014 at 20:10, Miod Vallat wrote:
Except that 1. this is ugly unless you express the values in hex, as
noone can spot these are multiples of 4096 in decimal, and 2. I think it
is more important to make clear that nback == nforw - 1 (or + 1 in the
SEQ case), regardless
Applied, thanks for spotting the issue, and sorry for the delay.
Miod
Index: uvm/uvm_pmemrange.c
===
RCS file: /cvs/src/sys/uvm/uvm_pmemrange.c,v
retrieving revision 1.37
diff -p -u -r1.37 uvm_pmemrange.c
---
Fixed. Thanks for reporting.
Miod
rshd has des_old API references, but it's in the kerberosIV code which
we don't build anymore since years.
The following diff removes the KerberosIV code from rshd (cpp symbols
KERBEROS and CRYPT); and as a bonus, fixing the indentation of code
afterwards apparently exposed a minor bug where
Whoops, I sent this before seeing Okan's mail. Sorry for the dup.
The other day I was doing an install in qemu-kvm and newfs was taking
forever, to the tune of hours. This is similar to formatting on arm
boards. In my quest to track down why, I discovered that ffs2 takes far
less time to format than ffs1 (about 30 seconds for the entire disk).
I've put
we do some scsi ops where we give a device a large buffer and expect
it to only fill part of it because we dont know how big that part
will be.
the underrun handling in mpii always caused this to fail, so devices
relying on this didnt work as expected (eg, ses).
according to the solaris
Index: src/sys/dev/usb/if_axe.c
===
RCS file: /cvs/src/sys/dev/usb/if_axe.c,v
retrieving revision 1.105
diff -u -p -r1.105 if_axe.c
--- src/sys/dev/usb/if_axe.c 25 Jan 2011 20:03:35 - 1.105
+++
the uvm_km_pgremove_intrsafe function requires pages to be mapped to free them
however it is then expected to call pmap_kremove(). This is
scary as in the page is freed, but is still mapped.
Have uvm_km_pgremove_intrsafe() unmap as well as free.
Well then it makes sense to move the
Tentative fix, mostly by beck@. Would need some IPv6 tests of course.
Index: sys/ufs/ufs/ufs_vnops.c
===
RCS file: /cvs/src/sys/ufs/ufs/ufs_vnops.c,v
retrieving revision 1.97
diff -u -r1.97 ufs_vnops.c
--- sys/ufs/ufs/ufs_vnops.c
The -Wsentinel warning is supposed to complain when the last argument in
a call to a function which has __attribute__((sentinel)) is not a NULL
pointer.
However, the current implementation of the check in gcc 3 and gcc 4 will
warn if the last argument is not explicitely declared as a pointer
Not really ok. Given the way the ISO C standard is formulated, not
casting NULL in this case is a genuine bug.
One can argue though, that defining NULL in such a way that it is not
usable as a sentinel value would be really really silly, and that it
is not our job to catch missing casts
Would it be better maybe to do the check in the Width() macro itself?
Yes indeed. New diff below.
-#define Width(c) wcwidth(c)
+#define Width(c) (wcwidth(c) == -1 ? 0 : wcwidth(c))
But this calls wcwidth() to be invoked twice, which is ugly. As a
minimum, make this an inline
A few more conversions to km_alloc: exec arguments, kernel stacks and
pipe buffers.
Tested on amd64, i386 and sparc. Please give it a spin on other architectures,
I would be especially interested in mips64 since it's the only one that needs
kernel stack alignment.
Works on mips64 with 4KB
Revision 1.58 of ccd.c (a mere six years ago...) introduced an
unintialized variable usage, in the case of an interleaved and mirrored
ccd; read access could favor the mirror instead of the main ccd by
incorrectly considering the main ccd is in the failure state.
The following diff ought to fix
Now, consider this: the fs code is very heavily tested. People use it 24 hours
a day, 365 days a year.
Except on leap years, of course. Those years see even more real-life
testing happening!
1 - 100 of 449 matches
Mail list logo
