Hello!
Since this is bug-hurd and not just discuss-hurd, let me actually
report some bugs I just ran into.
Since recently, sudo has been broken:
$ sudo echo hi
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts
It never even asks for the password, just errors out all by
Thanks for looking into it!
On Mon, Aug 30, 2021 at 6:37 PM Florian Weimer wrote:
> You could kick the can down the road by switching to PTHREAD_IN_LIBC.
> In some cases, that might actually be correct replacement.
Ack; that should be easy to do. Nevertheless, please do look at patch
4/4 and
rpctrace(1) is a Hurd RPC tracer tool, which is used similar to how
strace(1) is used on GNU/Linux.
Signed-off-by: Sergey Bugaev
---
Makefile | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index f98d5a9e67..a49870d3d1 100644
--- a/Makefile
+++ b
The next commit is going to introduce a new implementation of
THREAD_GSCOPE_WAIT which needs to access the list of threads.
Since it must be usable from the dynamic laoder, we have to move
the symbols for the list of threads into the loader.
Signed-off-by: Sergey Bugaev
---
htl/Versions
to get rid of
this flag, or at least rename it to better reflect what it's used for.
This patch does neither, though.
Signed-off-by: Sergey Bugaev
---
elf/dl-support.c| 1 -
sysdeps/generic/ldsodefs.h | 4 ---
sysdeps/htl/dl-thread_gscope_wait.c | 55
acceptable approach.
Signed-off-by: Sergey Bugaev
---
elf/dl-reloc.c | 21 -
elf/dl-support.c | 14 --
elf/dl-tls.c | 39
sysdeps/htl/dl-support.c | 5 ++
sysdeps/htl
o better
reflect what it's used for. I haven't really been able to come up with a good
name, though.
Alternatively, it could just be left as is for now.
Sergey Bugaev (4):
htl: Move thread table to ld.so
htl: Reimplement GSCOPE
testrun.sh: Add support for --tool=rpctrace
XXX: Attempt to
On Wed, Aug 18, 2021 at 8:43 PM Joan Lledó wrote:
> El 18/8/21 a les 0:02, Sergey Bugaev ha escrit:
> > To me it sounds like libpciaccess should have a Hurd-specific API
> > addition that would let the user get the memory object
>
> That's a solution and can be done. But
On Wed, Aug 18, 2021 at 8:34 PM Joan Lledó wrote:
> El 18/8/21 a les 0:13, Sergey Bugaev ha escrit:
> > you can no longer get the underlying memory object with vm_region ()
>
> How so? reading the docs I understood it does:
>
> https://www.gnu.org/software/hurd/gnumach-doc/M
On Tue, Aug 17, 2021 at 9:14 PM Joan Lledó wrote:
> > The underlying question is getting the memory object of a given memory
> > range, like vm_region does.
>
> Yes, I see that could be useful. Is vm_region not workig for proxies?
>
> > We need to be careful since we don't want any process to be
On Tue, Aug 17, 2021 at 12:38 AM Samuel Thibault
wrote:
> The root pci-arbiter uses libpciaccess' x86 backend to access PCI
On Tue, Aug 17, 2021 at 9:47 PM Joan Lledó wrote:
> Yes, and the arbiter can play two roles: root arbiter, which uses x86
> module in libpciacces; and nested arbiter,
On Tue, Aug 17, 2021 at 7:44 PM Almudena Garcia
wrote:
> But, in fstab, the drives are registered as /dev/hd0s1 (root partition in
> harddisk), and /dev/hd2 (cdron drive).
> I can try to change them to sdX naming, but is a bit risky
fstab only comes into play later in the boot process
On Tue, Aug 17, 2021 at 12:10 AM Samuel Thibault
wrote:
> Yes, and we want to implement nesting: providing a sub-hurd with a
> partial view of the PCI space.
Interesting. But I still don't think I understand what the problem you
are running into.
boot(1) already emulates Mach devices; it would
On Mon, Aug 16, 2021 at 11:43 PM Samuel Thibault
wrote:
> Here, possibly proxies can indeed work properly. But please do look at
> what Joan's situation is to make sure it does.
I don't think I understand enough about the situation. It would help
if you or Joan were to kindly give me some more
On Mon, Aug 16, 2021 at 10:28 PM Samuel Thibault
wrote:
> Sergey Bugaev, le lun. 16 août 2021 21:59:47 +0300, a ecrit:
> > IMO the proper way to get mremap () is vm_remap ()
>
> But that doesn't answer Joan's need for getting a memory object, to be
> able to put a proxy me
On Mon, Aug 16, 2021 at 9:17 PM Samuel Thibault wrote:
> > > I'd rather see a
> > > hurd-specific libpciaccess function to get the pager.
> >
> > That's better, but we'd have to add that function in both hurd_pci.c and
> > x86_pci.c. I don't like the idea of adding Hurd specific code to
On Sat, Aug 14, 2021 at 8:43 AM Michael Banck wrote:
> The fact that this process potentially or apparently took (or rather,
> has been taking) months for Sergey (I don't know when it was initiated),
> is a pretty good indicator that it is more than a nuisance.
Well, this is partly my own fault:
On Fri, Aug 13, 2021, 10:05 Sergey Bugaev wrote:
> Perhaps "multiple security improvements" deserve a mention?
>
Oh, or is it not going to make it into the release because of the
unfinished copyright assignment? :(
Sergey
>
On Fri, Aug 13, 2021, 01:25 Samuel Thibault wrote:
> So as usual, along the Debian release, we will have a Debian Hurd
> release. I have drafted the following list of news since the 2019
> release: <...>
> Is there some other big line that I am forgetting?
>
Perhaps "multiple security
On Wed, Aug 11, 2021 at 12:04 AM Samuel Thibault
wrote:
> > What the hell? How'd that file get there? I certainly didn't write it.
>
> No idea, and
>
> https://codesearch.debian.net/search?q=auto-all.conf=en
>
> doesn't know about it either.
Well in any case, removing that file made input work
On Tue, Aug 10, 2021 at 11:41 PM Samuel Thibault
wrote:
> Are you at the console while running this? Normally vcs is a symlink to
> /dev/vcs/1 or such.
Good point, that works from the console. Is it supposed to be
dependent on who's asking, like /dev/console in Unix? (If so, why
doesn't it like
On Tue, Aug 10, 2021 at 4:42 PM Almudena Garcia
wrote:
>
> > Since then things have regressed. At one point Xorg was failing to
> > find any displays at all, lately it's been starting just fine and
> > displaying simple windows properly, but it's unable to take any input
> > from my mouse and
Hello!
On Tue, Aug 10, 2021 at 2:53 PM Richard Braun wrote:
> I have issues mounting /home (or rather, keeping it mounted) on
> darnassus.sceen.net since the reboot. Samuel already has root access
> so he can look at it when he has time.
That's... not good. I hope we'll figure it out.
By the
For what it's worth, a few years ago I was able to successfully run
Xfce, LXDE, GNUstep, parts of GNOME, and even Plan 9 from User Space.
Since then things have regressed. At one point Xorg was failing to
find any displays at all, lately it's been starting just fine and
displaying simple windows
On Tue, Aug 10, 2021 at 5:04 AM Samuel Thibault wrote:
> In the past months, Sergey Bugaev has been working on fixing some
> Hurd security vulnerabilities.
Well I certainly wasn't doing it alone :)
Samuel and me have been working together over the past few months to
design and implement
On Wed, Jul 28, 2021 at 11:25 PM Sergey Bugaev wrote:
> On Wed, Jul 28, 2021 at 10:39 PM wrote:
> > It would be cool to have a gemini translator. It would only take a few 100
> > lines of code.
>
> Oh yes, a Gemini translator actually sounds like a perfect exercise!
On Wed, Jul 28, 2021 at 10:39 PM wrote:
> Thanks for working on this!
I don't believe it: I finally got my own "OFF TOPIC PRAISE" letter!
Thank you for your kind words :)
> I'm wanting to learn more about trivfs for my caesar
> cipher eventually, but looking that how to write trivial
---
trans/Makefile | 10 +-
trans/symlink.c | 243 +++-
2 files changed, 137 insertions(+), 116 deletions(-)
diff --git a/trans/Makefile b/trans/Makefile
index 6cf50e7a..c04220a2 100644
--- a/trans/Makefile
+++ b/trans/Makefile
@@ -25,7 +25,7 @@
ile /tmp/demo
/tmp/demo: broken symbolic link to no-such-file
$ ls -l /tmp/demo
lrwxrwxrwx 1 sergey sergey 12 Jun 21 16:11 /tmp/demo -> no-such-file
Sergey Bugaev (1):
trans/symlink.c: Rewrite on top of trivfs
trans/Makefile | 10 +-
trans/symlink.c
Instead, delay the reply message until the corresponding
gsync_wake () call is made.
TODO: Handle the case of reply port dying.
---
include/mach/gnumach.defs | 4 ++
kern/gsync.c | 112 +++---
kern/gsync.h | 8 ++-
3 files changed, 89
Hello,
while hacking on rpctrace -p, I once again ran into gsync_wait () calls
permanently hanging rpctrace.
The reason for this is simple: once rpctrace logs the gsync_wait () call it
receives from a traced task, it forwards the same gsync_wait () call to the
actual task port of the traced
Fix several issues with reference counting in
rootdir_make_translated_node ():
* Grab an additional reference while still holding the lock.
* Give the node an additional reference for being pointed to
by the ops.
* Reference the existing node if we find it on the second try,
not only if we
This fixes the procfs crash that happens on shutdown, previously discussed
here: https://lists.debian.org/debian-hurd/2021/04/msg00035.html
Sergey Bugaev (1):
procfs: Fix use-after-free
procfs/rootdir.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
2.31.1
If no output width limit has been set explicitly, and we're not printing
to a tty, do not limit output width.
In particular, this fixes grepping ps output.
---
utils/ps.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/utils/ps.c b/utils/ps.c
index 2cf6e4bd..8e39c2c5 100644
---
On Fri, May 14, 2021 at 7:33 PM Sergey Bugaev wrote:
> Oh, and you would not believe this, but in the past couple of hours I
> have discovered *another* vulnerability, unrelated to the first one;
> it's even easier to exploit and also gives you root
And one more, unrelated to either of
On Sat, May 15, 2021 at 5:09 PM Samuel Thibault wrote:
> This can't go to the generic-purpose dl-support.c file.
> Create a sysdeps/mach/hurd/dl-thread_gscope_wait.c file, it's already
> getting included by elf/Makefile's routine variable.
I'm creating sysdeps/htl/dl-thread_gscope_wait.c in the
On Sat, May 15, 2021 at 4:56 PM Samuel Thibault wrote:
> > * rpctrace has to learn to parse defs, instead of (or in addition to) msgids
> > * GNU MIG needs to be taught to emit more info into msgids files
>
> Either of those. Probably the latter would be more interesting
> long-term. We could
On Fri, May 14, 2021 at 4:30 PM Samuel Thibault wrote:
> We don't have anything set up for disclosures, you can drop me an e-mail
> (ciphered if you can).
OK, I'll prepare a write-up and send it to you. And I will attempt to
use GPG for it.
I asked about this on the Fediverse; and got (among
As luck would have it, I have found a serious issue in a core
component of the Hurd. It is a denial of service, which can then be
turned into privilege escalation.
I have developed an exploit. Here is it in action:
sergey@sergey-hurd-box:~/hax$ id
uid=1000(sergey) gid=1000(sergey)
On Wed, May 12, 2021 at 11:48 PM Samuel Thibault
wrote:
> It'd probably mean introducing types
> here and there, but that'd be a really good thing to do.
>
> The port type is useful indeed and is most often available in the types
> already.
Oh, do you mean the types specified in .defs? If so,
On Wed, May 12, 2021 at 11:48 PM Samuel Thibault
wrote:
> > * Symbolicated flags and file paths (potentially, also proc and auth
> > handles)
>
> For file path it'll probably be much harder since there can be several
> path (or even no path!) for a given file port.
And as far as I can see,
Hello,
I use rpctrace a lot, but I'm not particularly fond of its output
format. Other tracing tools, like strace [0] on Linux and Darling's
xtrace [1] can symbolicate many flags and structures, producing
something that looks much closer to C code, and comprehensible at a
glance.
[0]:
The next commit is going to introduce a new implementation of
THREAD_GSCOPE_WAIT, which needs to access the list of threads. Since
it must be usable from the dynamic laoder, we have to move the
symbols for the list of threads into the loader.
This is my attempt at doing so.
---
elf/dl-support.c
ibc/build$ ./testrun.sh --tool=rpctrace /bin/uname |& grep gsync
~/glibc/build$
Sergey Bugaev (3):
XXX: Rename THREAD_GSCOPE_IN_TCB -> THREAD_GSCOPE_LINK_MAP
XXX: Move __pthread_threads to ld.so
XXX: Reimplement gscope
elf/dl-reloc.c | 4 +--
This patch is probably bogus; but I'm including it anyway.
I've noticed that THREAD_GSCOPE_IN_TCB is actually being used not to
check whether the thread global scope state is being stored in TCB,
but rather as a general flag to distinguish between NPTL and HTL.
When THREAD_GSCOPE_IN_TCB is
This moves the Hurd gsope implementation to be more like the Linux
one.
---
sysdeps/generic/ldsodefs.h | 2 --
sysdeps/htl/dl-thread_gscope_wait.c | 36 +
sysdeps/mach/hurd/i386/tls.h| 22 ++
sysdeps/mach/hurd/tls.h | 20
On Sat, May 8, 2021 at 10:54 PM Samuel Thibault wrote:
> Don't bother looking at the existing implementation, its roots dates
> before we really had gsync working.
Interesting!
As far as I can see, this implementation was committed (by you) in
2018; and gsync has not seen significant changes
I've noticed that even a simple hello world does a lot of gsync calls:
$ rpctrace echo hello world |& grep -c gsync
53
These are in fact all identical gsync_wake () calls on a single address:
$ rpctrace echo hello world |& grep gsync | uniq
task132(pid18549)->gsync_wake (202820 0 0);
This
This introduces the PM_PRECIOUS bit, which gets set when a precious
page is offered to the kernel using pager_offer_page () with the
precious argument set, and cleared when the page is returned back.
---
libpager/data-return.c | 3 ++-
libpager/offer-page.c | 2 ++
libpager/priv.h| 1 +
While this is less efficient than using a single bit per page,
there is no guarantee that the kernel will not send us more than
32 pages at a time. Indeed, one can easily craft a situation where
it will send more by unmapping a large mapping.
Also, this function already uses on-stack arrays for
call from
storeio.
Sergey Bugaev (4):
libpager: pager_write_page () should not unmap page
libpager: Store omit_data in an array
libpager: Track which pages are precious
libpager: Do not throw away precious pages
doc/hurd.texi | 6 ++--
libpager/data-return.c | 67
Clarify this in the documentation, and fix the storeio implementation.
---
doc/hurd.texi | 6 +++---
libpager/pager.h| 6 +++---
storeio/pager.c | 8 +++-
tmpfs/pager-stubs.c | 6 +++---
4 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/doc/hurd.texi
The kernel invokes memory_object_data_return () with dirty = 0 in two
cases: if notification on eviction was requested, or when returning
precious pages. Properly distinguish between the two cases, and only
throw the clean page away in the former case.
---
libpager/data-return.c | 54
On Sat, May 8, 2021 at 2:40 PM Samuel Thibault wrote:
> Ah, seeing zipstores.c I thought zipfiles were supported, so I was
> wondering how since, as you say, they combine both.
By the way, upstream libstore itself supports gzip & bzip2; I have
only briefly looked into why tarfs needs to ship its
On Sat, May 8, 2021 at 2:36 PM Samuel Thibault wrote:
>
> Hello,
>
> Just to be sure: this is not only because of your previous patch
> libpager: Do not flush in-core pages on offer
> ?
Yes; this issue is completely orthogonal to that fix (but there's an
interesting interaction I haven't thought
On Sat, May 8, 2021 at 2:39 PM Samuel Thibault wrote:
> I pushed the revert, thanks!
Thank you!
I'm attaching another patch that tries to make settrans handle this
case a tiny bit better: if we failed to set the translator (either
because of this issue, or for any other reason), let's shut the
Hello yet again,
I'm hitting the following issue when trying to re-set a translator on
a node whose translator has previously died:
$ settrans -acP /tmp/yes ~/dev-yes/hurd/yes
Translator pid: 1039
Pausing...
$ kill 1039
$ settrans -ag /tmp/yes ~/dev-yes/hurd/yes
settrans: /tmp/yes: (os/kern)
On Thu, May 6, 2021 at 3:56 PM Sergey Bugaev wrote:
> - newaddr = mmap (0, newsize * sizeof (*p->pagemap),
> - PROT_READ|PROT_WRITE, MAP_ANON, 0, 0);
> + void *newaddr = reallocarray (p->pagemap, off,
> +s
There's yet another bug: libpager just throws away clean precious
pages (those previously offered with pager_offer_page (precious = 1))
upon receiving them from the kernel, since it mistakes them for
evicted pages it's being notified about. This is obviously very
problematic.
I'm attaching a
libc already implements the functionality for allocating and managing
memory blocks like the pagemap. Using libc functions gives us some
additional niceties like overflow checking in reallocarray (). it also
means that we will not allocate a whole page of memory if we need to
store just a few
The code tried to round up the allocation size to a multiple of page size.
But we actually allocate newsize * sizeof (*p->pagemap) bytes, not newsize
bytes, which meant allocations were sizeof (*p->pagemap) times larger than
they needed to be.
---
libpager/pagemap.c | 9 +
1 file changed,
On a 64-bit system, there can be a lot more pages
than a 32-bit int can fit.
---
libpager/pagemap.c | 2 +-
libpager/priv.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libpager/pagemap.c b/libpager/pagemap.c
index 963f6567..63c5f44d 100644
--- a/libpager/pagemap.c
Instead of ignoring errors, we might as well return them to the caller.
This technically changes the function signatures, but should not break
any users since they can continue to ignore the return value.
---
doc/hurd.texi | 16 ++--
libpager/data-unlock.c | 13 +-
pager_offer_page () is documented to may ignore the offered page if
the kernel already has a copy in core (indeed, that's what Mach does).
However the current behavior is the inverse of that: it asks the kernel
to flush (i.e. drop) its in-core copy, and replace it with the offered
one. Fix this
returned void. This should
not break any callers though.
I have tested that the modified libpager builds without warnings, and
tmpfs seems to work as expected with libpager.so replaced.
Sergey Bugaev (6):
libpager: Fix mixing up success and error
libpager: Do not flush in-core pages on offer
_pager_pagemap_resize () returns an error or 0 on success,
not a boolean.
---
libpager/offer-page.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/libpager/offer-page.c b/libpager/offer-page.c
index 9f090bcb..ddea236a 100644
---
On Sat, May 1, 2021 at 8:48 PM Samuel Thibault wrote:
> Since this is not part of the main hurd repo there is no copyright
> assignment requirement, so you can put your name. You can also assign
> copyright and then put the FSF name.
OK, I'll put my own name for now then.
I'm fine with
On Sat, May 1, 2021 at 8:05 PM Samuel Thibault wrote:
> > And in case of tarfs, the compression is handled by the store
> > abstraction, which makes it transparent to the rest of the logic.
>
> Ah, ok.
> And in the zip case?
As I understand it, zip is a different model that basically combines
On Sat, May 1, 2021 at 7:38 PM Samuel Thibault wrote:
> > on the other hand, the tar format, with its 512-byte
> > blocks, sounds very much like a filesystem image to me. isofs uses
> > diskfs, why doesn't tarfs?
>
> It's not exactly the same since you have compression in the way. But
> yes, that
On Sat, May 1, 2021 at 6:23 PM Samuel Thibault wrote:
> This is missing the copyright head:ng.
Ah yes, sorry. Should I just put myself there, or "Hurd developers",
or "Free Software Foundation, Inc."?..
> > + err = create_pager (node, );
>
> Is the pager getting cleaned at some point?
The
On Sat, May 1, 2021 at 6:38 PM Samuel Thibault wrote:
> Actually I'd say the pager should replace the cache. The pager is
> already a cache by itself, we should not need to keep both the pager and
> the cache, particularly since it means having to keep both coherent.
Well, yes, I've considered
---
BUGS | 1 -
TODO | 2 --
2 files changed, 3 deletions(-)
diff --git a/BUGS b/BUGS
index 1c946b366..4b88e85d1 100644
--- a/BUGS
+++ b/BUGS
@@ -4,7 +4,6 @@ Known tarfs bugs
1. General
-* io_map () not implemented (gcc uses it unfortunately).
* netfs.c (netfs_get_dirents): too much memory
No mmap coherence is implemented yet.
---
pager.c | 30 +++---
tarfs.c | 2 +-
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/pager.c b/pager.c
index ecd564020..8756a2a4b 100644
--- a/pager.c
+++ b/pager.c
@@ -11,6 +11,9 @@
#include "pager.h"
#include
Each node can have a pager attached. The pager gets created
the first time io_map () is invoked on the node, and destroyed
once it has no clients. The pager gets its data the same way
tarfs_read_node () does: by ask the cache to copy out the data.
Note that this ommit only implement read-only
---
backend.h | 3 +++
netfs.c | 36 ++--
tarfs.c | 9 +
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/backend.h b/backend.h
index 82bbee77b..0b281f686 100644
--- a/backend.h
+++ b/backend.h
@@ -110,6 +110,9 @@ struct fs_backend
When reading from or writing to a node that has an attached pager,
use pager_memcpy () instead of accessing the cache directly. This
enables tarfs_read_node () and tarfs_write_node () too see and affect
the changes made to the file through the memory mapping.
---
tarfs.c | 89
---
Makefile | 2 +-
main.c | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e3936bfda..6e2eb422e 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ CFLAGS += -DDEBUG_ZIP # zip stores debugging
# Note: -lz has to be first
/anonymous/7de6f56e7a1c4babbab17bd6ccc2db46
Sergey Bugaev (6):
Plumb io_map () through the backend layer
Link to libpager and initialize it on startup
Implement basic read-only mmap support
Implement basic support for writable mappings
Attempt to implement mmap coherence
Update TODO and B
On Mon, Apr 26, 2021 at 11:10 PM Samuel Thibault
wrote:
> Err, but wouldn't the compiler be able to determine that the size was
> properly computed, and avoid emitting a false-positive warning?
It is my understanding, based on
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059, that GCC does
On Mon, Apr 26, 2021 at 9:02 PM Jessica Clarke wrote:
> > - strncpy (filepath, path, length);
> > - strncat (filepath, filename, strlen (filename));
> > + strcpy (filepath, path);
> > + strcat (filepath, filename);
>
> This is dubious. We should be using safe interfaces where possible.
To
This fixes a build error.
---
stow-mutations.h | 1 +
stow-priv.h | 4
stow.c | 9 +
3 files changed, 14 insertions(+)
diff --git a/stow-mutations.h b/stow-mutations.h
index d36280d..95c1e7f 100644
--- a/stow-mutations.h
+++ b/stow-mutations.h
@@ -21,6 +21,7 @@
/*
]: https://www.gnu.org/software/hurd/hurd/translator/unionfs.html
Sergey Bugaev (3):
Implement MiG intran payload support
Add some missing includes
Don't use strncat() with length derived from source string
lib.c| 5 +++--
lib.h| 1 +
lnode.c | 1
This fixes multiple build errors.
---
lib.c| 1 +
lib.h| 1 +
lnode.c | 1 +
lnode.h | 1 +
node.c | 1 +
stow.c | 2 ++
ulfs.c | 1 +
update.c | 1 +
8 files changed, 9 insertions(+)
diff --git a/lib.c b/lib.c
index e7f3aa9..01cdbd0 100644
--- a/lib.c
+++ b/lib.c
@@ -23,6 +23,7
This fixes Wstringop-overflow and Wstringop-truncation GCC warnings.
See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059
Also, fix a bug where a string was not properly null-terminated.
---
lib.c | 4 ++--
stow.c | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git
701 - 784 of 784 matches
Mail list logo
