Fix an unlikely possible var sorting problem
Now that CHECKSTRSPACE() is usable, use it when sorting var
names (for "set" (no args or options) and similar uses (export -p etc))
which sort the vars. The previous use of STPUTC() was unsafe, as
the buffer the name was being moved into could move that way, but nothing
was allowing for that, possibly instead using the (only part completed and
unterminated) old pre-move version of the name for use when comparing.
The only likely effect would be incorrectly sorted vars in the output,
and that would have been quite rare (and probably never happened), but
now we can safely use CHECKSTRSPACE() for an arbitrary size, use that
to ensure that the entire var name will fit without moving the string
(and use USTPUTC() to guarantee that doesn't happen - and it is faster).
While here, add lots of comments to explain what is going on, and why,
in the var name comparison function (sort_var()), as at first glance,
what it is doing looks absurd ... it just isn't.
[3 lines not shown]
Remove CHECKSTACKSTR() defect workaround
When reading the output from a command substitution, the code defers
adding embedded \n's to the result (just counting them instead) until
some other character appears - this effectively achieves the "trailing
\n's are removed" semantic without needing to actually remove anything,
as without a following char, the \n's aren't ever added.
That's fine, but the number of \n's counted, that will need to be added when
another char appears, is unbounded - and could be (and at least once, was)
more than the old CHECKSTACKSTR() could handle. To fix that, if the newline
count was "too big" (arbitrarily set at 20) the code used a slow path, which
avoided CHECKSTACKSTR() and was correct.
Now CHECKSTACKSTR() has been fixed, that workaround is no longer required,
so remove it. Since long runs of embedded \n's don't often appear in
command substitution output, avoiding the slow path is unlikely to make
any noticeable speed difference, but not having that code at all makes the
shell smaller - enough smaller to compensate for the minor increase that
the CHECKSTACKSTR() correction added, and even a bit more.
Make CHECKSTRSPACE() do what it always should have done
The CHECKSTRSPACE() macro is given a number 'n' of bytes,
which it is intended to assure are to be available on the
stack - allocating more space if needed. The old macro
checked to see if 'n' were available, and if not, allocated
more space (which sounds right) - but with no specification
of how much more space would be allocated, just a general
hope that it would be enough.
This then required additional workarounds whenever 'n' might
be larger than "just a few", because it just wasn't safe (and
had caused problems in the past).
Now CHECKSTRSPACE() works as intended, though the actual change is
to the makestrspace() function (used only from CHECKSTRSPACE()), which
now gets told how much space is needed, so it can ensure that sufficient
is provided, rather than just the generic "more".
[15 lines not shown]
wlroots: update to 0.19.3
wlroots 0.19.3
Aleksei Bavshin (2):
backend/libinput: fix build with libinput 1.31
backend/libinput: add support for LIBINPUT_SWITCH_KEYPAD_SLIDE
Andri Yngvason (1):
image_capture_source/output: Update constraints on enable
Dale Turner (1):
Add "const" to eliminate "error: initialization discards ‘const’ qualifier from pointer target type"
David96 (1):
wlr_virtual_pointer: Set axis source on all axis
John Lindgren (1):
[24 lines not shown]
megacmd: update to 2.5.2
Wed Apr 08 12:00:00 CEST 2026 - linux at mega.co.nz
- Update to version 2.5.2:
* Fix: address potential loop in sync engine with mtime changes within 2 seconds
- Use builtin megasdk-10.8.2
Finally retire the ancient LINENO hack
The original implementation of the POSIX required LINENO variable
was a hideous hack, which didn't really work. That was replaced
in 2017, but the code for the hack was left present in case it was
needed - with the enabling code #if'd out, but all the rest of the
code unchanged - just impossible to be executed any more.
This removes all of that ancient code (including that which
was #if'd away), /bin/sh will get slightly smaller, and perhaps
unmeasurably faster, there should be no other differences.
