lp:mksh

Branch merges

Related source package recipes

1 recipe using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

20100709 maxb Approved
20100709 maxb It looks like we'll need the LOSAs to manually accept the ssh host key, suspending for now - pending https://answers.launchpad.net/launchpad-code/+question/117193
20110610 mirabilos Imported fine, thanks!
20120216 mirabilos Fixed server-side error w.r.t. the modules file, import may be unfailed again

3285. By tg on 2021-10-16

add debug-buffer editing command ifdef DF

(not because I need it but because otherwise x_emacs_DF is defined/unused)

3284. By tg on 2021-10-12

for locale tracking without setlocale(), define a way to set the
implementation-defined default locale ("C" normally but can be "UTF-8")

also, comments with more things yet to fix…

3283. By tg on 2021-10-16

unroll that loop to fix a bad off-by-one error

could have fixed it by changing the while (n--) after the goto utflead; to
a while (--n) but not only feels that wrong (others even worse), it’s also
more performant this way (unrolled via Duff’s), knowing that n can only be
2/3 (or 4 with 21-bit UCS later) here (we should do more multibyte-induced
loops this way!)

3282. By tg on 2021-10-11

more _POSIX_VDISABLE fuckery (fuck GNU glibc, a̲g̲a̲i̲n̲!):

Act 1: glibc on GNU/kFreeBSD, in contrast to proper MidnightBSD (for
 example), defines _POSIX_VDISABLE to something not a valid C
 præprocessor token:

 ../../sh.h:399:7: error: missing binary operator before token "char"
   399 | #elif _POSIX_VDISABLE == -1
       | ^~~~~~~~~~~~~~~

 Verified on lemon.debian.net (kfreebsd-amd64 porter box).
 This actively breaks the *intended* way of using this macro
 but (I suppose…) that’s GNU for you…

Act 2: A gem shared by https://stackoverflow.com/a/50186064/2171120

 “I looked at some old systems in the Unix tree. All of
  Minix 1.5 (1989), Linux 0.96c (1992), and 4.4BSD (1993)
  have _POSIX_VDISABLE defined and not -1.”

 So rip out the ifdef and assume it’s defined-and-not-disabled
 until someone porting encounters an OS which doesn’t?

Act 3: Of course, Linux klibc (nor the Linux uapi headers) define
 _POSIX_VDISABLE at all. I mean it’s not like this is part
 of the kernel tty API or something (ha ha only serious)…

Therefore we’re currently ending up with:
• if _POSIX_VDISABLE is defined assume it’s not -1
• if _POSIX_VDISABLE is not defined use “the old BSD value” (0377,
  but as unsigned int because cc_t is unsigned, and as hex number
  because the days octal (outside of chmod/umask…) made sense have
  died with PDP endianness), which also fits with EO not being in
  use in UTF-8 o̲r̲ EBCDIC…

If this ever reaches an operating environment where these don’t hold
true and where the fallback to 0xFFU (which -1 would map to as well)
causes trouble, we’ll need to do as pdksh did and store _POSIX_VDISABLE
in a variable (though, of what type…) possibly using fpathconf(2) also.
Intermediate chance may be a mirtoconf test for whether _POSIX_VDISABLE
is defined and not -1 and restoring the pre-1.954 macros except checking
the mirtoconf output first… (still no fpathconf(2) but meh)

tl;dr: portability was fucking hard before the modern fuckers who are
probably younger than many systems mksh runs on invented sarding more
catdamned breakage…

3281. By tg on 2021-10-11

let CFLAGS autodetection choke on stack protector when the libc lacks it
(Linux klibc) by introducing an array on the stack of main()

3280. By tg on 2021-10-10

small wording change in error path, no binary change

3279. By tg on 2021-10-10

fix whitespace (no binary change)

3278. By tg on 2021-10-10

also refuse files starting with two NULs, might be UCS-4 or generic binary

3277. By tg on 2021-10-10

advance towards locale tracking: drop BOM handling entirely

(also for when it’s not yet enabled; it was an abomination anyway)

3276. By tg on 2021-10-10

fix whitespace (no binary change)