[hackers] [sbase][PATCH] tar: sanitize: leading zeros should be recognized

2024-02-10 Thread Elie Le Vaillant
Most tar implementations (GNU, BusyBox, toybox, libarchive) recognize leading spaces as equivalent to leading zeroes in numeric fields. This leads to some archives begin recognized as malformed. This fixes it by replacing leading spaces by leading zeroes in sanitize(). Considering numeric fields ar

[hackers] [sbase][PATCH v2] tar: sanitize: leading zeros should be recognized

2024-02-10 Thread Elie Le Vaillant
Most tar implementations (GNU, BusyBox, toybox, libarchive) recognize leading spaces as equivalent to leading zeroes in numeric fields. This leads to some archives begin recognized as malformed. This fixes it by replacing leading spaces by leading zeroes in sanitize(), and in chktar(), too. --- ta

[hackers] [sbase][PATCH v3] tar: sanitize, chktar: leading spaces should be skipped over

2024-02-11 Thread Elie Le Vaillant
Some tar archives (eg. ftp://ftp.gnu.org/gnu/shtool/shtool-2.0.8.tar.gz) use leading spaces instead of leading zeroes for numeric fields. Although it is not allowed by the ustar specification, most tar implementations recognize it as correct. But since 3ef6d4e4, we replace all spaces by NULs here,

[hackers] [sbase][PATCH] TODO: update and add items

2024-02-21 Thread Elie Le Vaillant
Upon closer inspection of the toybox roadmap, it appears some not-out-of-scope items are missing from the TODO, most importantly dc and file. Moreover, install is listed in sbase-box since 3c36fb41773, so the corresponding TODO item was removed. --- TODO | 13 + 1 file changed, 9 inse

[hackers] [sbase][PATCH] Add implementation of tac(1)

2024-02-26 Thread Elie Le Vaillant
--- .gitignore | 1 + Makefile | 1 + README | 1 + libutil/getlines.c | 3 +- tac.1 | 22 +++ tac.c | 68 ++ text.h | 3 +- 7 files changed, 97 insertions(+), 2 deletio

[hackers] [sbase][PATCH] Add strptime, which replaces date-parsing in date(1)

2024-02-26 Thread Elie Le Vaillant
usage: strptime fmt timestamp Most other userspace implementations allow in date(1) the parsing of dates. That way, one can use a date string, and manipulate it in scripts. However, the current date(1) implementation only accepts Unix epochs to describe date and time. Rather than patching date(

[hackers] [sbase][PATCH] Add implementation of ts(1)

2024-02-26 Thread Elie Le Vaillant
The -m flag is not compliant to either the OpenBSD or the moreutils implementation of ts(1), but closer to the toybox one. It allows the user to add in nanoseconds, like toybox, but allows to specify how many digits are printed. --- .gitignore | 1 + Makefile | 1 + README | 1 + ts.1

[hackers] [sbase][PATCH] Add implementation of shuf(1)

2024-02-26 Thread Elie Le Vaillant
--- .gitignore | 1 + Makefile | 1 + README | 1 + shuf.1 | 43 + shuf.c | 110 + 5 files changed, 156 insertions(+) create mode 100644 shuf.1 create mode 100644 shuf.c diff --git a/.gitignore b/.gitig

[hackers] [sbase][PATCH] sort: remove useless allocation

2024-02-26 Thread Elie Le Vaillant
I'm not sure why we're doing malloc() then memcpy() here, when we could just make col->line.data point to start.data. This is costy for huge sorts (3 time slower than other implementations with no real reason). Since we are now working with the original line.data we need to revert the s/\n/\0/ that

[hackers] [sbase][PATCH] libutil: add random.c

2024-02-27 Thread Elie Le Vaillant
Some programs need a good PRNG, such as shuf(1), or cron(1). This adds to libutil a random_uniform function which simply solves the problem of creating integers uniformly in a range. random_seed seeds the generator. arc4random would probably be a better PRNG than random, but it is less portable

[hackers] [sbase][PATCH] shuf: use libutil/random functions instead of custom ones

2024-02-27 Thread Elie Le Vaillant
--- shuf.c | 37 + 1 file changed, 1 insertion(+), 36 deletions(-) diff --git a/shuf.c b/shuf.c index 2655d08..3d8ec51 100644 --- a/shuf.c +++ b/shuf.c @@ -7,41 +7,6 @@ #include "text.h" #include "util.h" -/* - * Uniformity is achieved by generating new ran

[hackers] [sbase][PATCH] cron: heavy refactor of parsefield() and matchentry()

2024-02-27 Thread Elie Le Vaillant
This patch heavily simplifies the parsing logic of parsefield(), and makes the grammar more standards-compliant. Before, this cron implementation would only recognize repeats ("/n" at the end of a range, or of a wildcar) for wildcars, and list elements could only be numbers. Now, the basic type i

Re: [hackers] Penfing patches for sbase and ubase

2024-02-27 Thread Elie Le Vaillant
"Roberto E. Vargas Caballero" wrote: > I know that there are some pending patches for sbase and ubase, > but I am a bit busy these days and I will not be able to look > a bit deeper on them until next week. Be patient until then :) > > Thank you Sure, no problem! I've sent most of the patches I'

[hackers] [sbase][PATCH] cron: fix parsing and '~' behavior

2024-02-28 Thread Elie Le Vaillant
In parserange(), we tested wether range was null, to test wether or not the repeat number was the end of the string (to test if we had something like "*/3/34"). But it is str that we should be testing, not range, as its value as a pointer doesn't mean anything in the current context. This makes t

[hackers] [sbase][PATCH] cron: fix parsing and '~' behavior

2024-02-28 Thread Elie Le Vaillant
In parserange(), we tested wether range was null, to test wether or not the repeat number was the end of the string (to test if we had something like "*/3/34"). But it is str that we should be testing, not range, as its value as a pointer doesn't mean anything in the current context. This makes t

[hackers] [sbase][PATCH] strptime: tm should be initialized as the current time

2024-02-29 Thread Elie Le Vaillant
localtime() provides the necessary informations to make mktime() work even in the absence of most informations. That way, strptime "%d/%m" 26/08 outputs a timestamp corresponding to the 26th of August of the current year, rather than the 1st January of 1900. --- strptime.c | 15 --- 1

[hackers] [sbase][PATCH] Add strptime, which replaces date-parsing in date(1)

2024-03-02 Thread Elie Le Vaillant
usage: strptime timestamp fmt Most other userspace implementations allow in date(1) the parsing of dates. That way, one can use a date string, and manipulate it in scripts. However, the current date(1) implementation only accepts Unix epochs to describe date and time. Rather than patching date(1

[hackers] [sbase][PATCH] Add implementation of tac(1)

2024-03-02 Thread Elie Le Vaillant
--- .gitignore | 1 + Makefile | 1 + README | 1 + libutil/getlines.c | 3 +- tac.1 | 22 +++ tac.c | 68 ++ text.h | 3 +- 7 files changed, 97 insertions(+), 2 deletio

[hackers] [sbase][PATCH] Add implementation of shuf(1)

2024-03-02 Thread Elie Le Vaillant
--- .gitignore | 1 + Makefile | 2 ++ README | 1 + libutil/random.c | 46 + shuf.1 | 43 +++ shuf.c | 77 util.h | 3 ++ 7 files changed,

[hackers] [sbase] Orphan patches and unsent patches

2024-03-02 Thread Elie Le Vaillant
Hello, Some patches I've sent are orphaned in the mailing list. These are: > strptime: tm should be initialized as the current time and > shuf: use libutil/random functions instead of custom ones Moreover, some patches I believed to have sent, weren't actually sent, due to bugs of my mail client.

[hackers] Re: [sbase] Orphan patches and unsent patches

2024-03-02 Thread Elie Le Vaillant
Elie Le Vaillant wrote: > cron(1) depends on the shuf(1) patch for libutil/random. This was > not made a standalone patch, which was a mistake on my part. Actually, libutil/random _was_ made a standalone patch, but it appears not to have been sent either. Also I'm not sure whether

[hackers] [sbase][PATCH] libutil/random: rewrite whole algorithm

2024-03-03 Thread Elie Le Vaillant
libutil/random.c now includes a custom PRNG, which is the PCG family. It also overhauls random_uniform(), making it way faster. Names were changed (s/random/rng32/g), and reentrant versions added. The PRNG is faster than libc's random(). It is way faster than the previous version, which used --- l

[hackers] [sbase][PATCH] shuf: use new libutil/random

2024-03-03 Thread Elie Le Vaillant
--- shuf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/shuf.c b/shuf.c index 36b3898..21210de 100644 --- a/shuf.c +++ b/shuf.c @@ -47,11 +47,11 @@ main(int argc, char *argv[]) } } - random_seed(); + rng32_seed(); if (!rf

[hackers] [sbase][PATCH] cron: use new libutil/random

2024-03-03 Thread Elie Le Vaillant
--- cron.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cron.c b/cron.c index 126ebf1..e95c661 100644 --- a/cron.c +++ b/cron.c @@ -294,7 +294,7 @@ parserange(char *str, long low, long high, struct range *r) if (random) { /* random replaces low in

[hackers] [sbase][PATCH] tar: force decompression

2024-03-03 Thread Elie Le Vaillant
decomp() needs the force flag -f too. --- tar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tar.c b/tar.c index 5f73c26..0361b63 100644 --- a/tar.c +++ b/tar.c @@ -593,7 +593,7 @@ main(int argc, char *argv[]) if (filtertool) { fd =

[hackers] [sbase][PATCH] Add implementation of realpath(1)

2024-03-04 Thread Elie Le Vaillant
--- .gitignore | 1 + Makefile | 1 + realpath.c | 34 ++ 3 files changed, 36 insertions(+) create mode 100644 realpath.c diff --git a/.gitignore b/.gitignore index e789e24..f1ce1c2 100644 --- a/.gitignore +++ b/.gitignore @@ -57,6 +57,7 @@ /printf /pwd /re

[hackers] [sbase][PATCH] realpath: add man pages

2024-03-04 Thread Elie Le Vaillant
--- readlink.1 | 1 + realpath.1 | 20 2 files changed, 21 insertions(+) create mode 100644 realpath.1 diff --git a/readlink.1 b/readlink.1 index 46b4cad..d5993ce 100644 --- a/readlink.1 +++ b/readlink.1 @@ -28,5 +28,6 @@ by recursively following every symlink in its path c

[hackers] [sbase][PATCH] libutil/random: better random seed

2024-03-04 Thread Elie Le Vaillant
Thanks NRK --- libutil/random.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libutil/random.c b/libutil/random.c index 780ba29..6b795a9 100644 --- a/libutil/random.c +++ b/libutil/random.c @@ -1,4 +1,5 @@ #include +#include #include static uint64_t globalstate; @@

[hackers] [sbase][PATCH] cron: fix repeat for random, and format code

2024-03-04 Thread Elie Le Vaillant
--- cron.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/cron.c b/cron.c index e95c661..9da0c8a 100644 --- a/cron.c +++ b/cron.c @@ -287,19 +287,17 @@ parserange(char *str, long low, long high, struct range *r) r->repeat = strtol(repeat, &e, 10);

[hackers] [sbase][PATCH] libutil/random: no need to call time() when we have timespec

2024-03-05 Thread Elie Le Vaillant
Thanks Steve Ward --- libutil/random.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libutil/random.c b/libutil/random.c index 6b795a9..d5214ae 100644 --- a/libutil/random.c +++ b/libutil/random.c @@ -67,7 +67,7 @@ rng32_seed_r(uint64_t *state) { struct timespec ts;

[hackers] [sbase][PATCH] head: remove useless buffering

2024-03-05 Thread Elie Le Vaillant
getline isn't useful here, because we just need to read then output lines. We do not need anything more complex than counting '\n's, so we shouldn't use a buffer like we currently do. --- head.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/head.c b/head.c ind

[hackers] [sbase][PATCH] tar: chktar: fix conditional typo

2024-03-05 Thread Elie Le Vaillant
--- tar.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tar.c b/tar.c index 0361b63..405b8d9 100644 --- a/tar.c +++ b/tar.c @@ -423,7 +423,7 @@ chktar(struct header *h) goto bad; } memcpy(tmp, h->chksum, sizeof(tmp)); - for (i = 0; i < si

[hackers] [sbase][PATCH] TODO: libutil/unescape: add NUL escapes

2024-03-06 Thread Elie Le Vaillant
--- TODO | 8 1 file changed, 8 insertions(+) diff --git a/TODO b/TODO index 6a0968e..a924aee 100644 --- a/TODO +++ b/TODO @@ -73,6 +73,14 @@ tr * When a character class is present, all other characters in the string are ignored. +libutil +--- +* unescape: NUL ('\0') escapes sh

[hackers] [sbase][PATCH] libutil/random: cast to long to avoid overflow

2024-03-07 Thread Elie Le Vaillant
Thanks NRK --- libutil/random.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libutil/random.c b/libutil/random.c index d5214ae..aa98d61 100644 --- a/libutil/random.c +++ b/libutil/random.c @@ -67,7 +67,7 @@ rng32_seed_r(uint64_t *state) { struct timespec ts;

[hackers] [sbase][PATCH] cron: fix '~' range parsing

2024-03-07 Thread Elie Le Vaillant
'~' after number was recognized as abnormal. --- cron.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cron.c b/cron.c index 9da0c8a..18ee8b1 100644 --- a/cron.c +++ b/cron.c @@ -252,7 +252,7 @@ parserange(char *str, long low, long high, struct range *r) errn

[hackers] [PATCH 1/2] Add libutil/random.c for fast PCG-based PRNG

2024-12-19 Thread Elie Le Vaillant
--- Makefile | 1 + libutil/random.c | 87 util.h | 5 +++ 3 files changed, 93 insertions(+) create mode 100644 libutil/random.c diff --git a/Makefile b/Makefile index 4e20cb3..35c4c25 100644 --- a/Makefile +++ b/Makefile @@ -8

[hackers] [PATCH 2/2] cron: heavy refactor of parsefield() and matchentry()

2024-12-19 Thread Elie Le Vaillant
This patch heavily simplifies the parsing logic of parsefield(), and makes the grammar more standards-compliant. Before, this cron implementation would only recognize repeats ("/n" at the end of a range, or of a wildcar) for wildcars, and list elements could only be numbers. Now, the basic type i

Re: [hackers] [sbase][PATCH] cron: fix repeat for random, and format code

2024-12-19 Thread Elie Le Vaillant
patches should I send? With the sbase-ubase branch/unification, the project has somewhat shifted in scope (a bit broader). Would it be adapted for this branch? I'm willing to work on a dc(1) implementation. Should I use libzahl? Cheers, Elie Le Vaillant

[hackers] [PATCH] rev, tail: replace hardcoded code by UTF8_POINT macro

2024-12-19 Thread Elie Le Vaillant
--- rev.c | 2 +- tail.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/rev.c b/rev.c index 2d89df1..9ac1da6 100644 --- a/rev.c +++ b/rev.c @@ -25,7 +25,7 @@ rev(FILE *fp) lf = n && line[n - 1] == '\n'; i = n -= lf; for (n =

Re: [hackers] [PATCH] libutil/random: fix conflict between versions

2024-12-20 Thread Elie Le Vaillant
e Twister and its 19968 bits of state, but again, I do not believe this to be a very good argument. - It's more code (9 SLOC to be precise). In the end, I believe consistent behavior is somewhat referrable over avoiding 9 SLOC in libutil/random. I have a slight preference for a custom PRNG. I'm open to using random() too. Cheers, Elie Le Vaillant

[hackers] [PATCH] libutil/random: fix conflict between versions

2024-12-20 Thread Elie Le Vaillant
--- libutil/random.c | 23 +++ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/libutil/random.c b/libutil/random.c index 72385fb..15082e5 100644 --- a/libutil/random.c +++ b/libutil/random.c @@ -21,7 +21,7 @@ rng32(void) } void -rng32_randomseed() +rng32_see

Re: [hackers] [sbase][PATCH 0/1] Add missing header file

2024-12-21 Thread Elie Le Vaillant
vert, or to apply the latest version of my patch. Cheers, Elie Le Vaillant

Re: [hackers] [PATCH 1/2] Add libutil/random.c for fast PCG-based PRNG

2024-12-21 Thread Elie Le Vaillant
). > > So this is just more code to get nothing in return. Not very suckless. > And not sensible in general either IMO. I agree. Elie Le Vaillant