[Bug 1855167] Re: Comparatively poor += performance

2020-03-27 Thread Thorsten Glaser
** Changed in: mksh
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1855167

Title:
  Comparatively poor += performance

Status in mksh:
  Fix Released

Bug description:
  Heavy use of += notably impacts script performance.  Consider the
  following micro-benchmark (pattered after real script content):

  i=0 s=
  while ((i < 3)); do
((++i))
s+=$i
  done

  which creates 138,894 character long string.  On my system (macOS
  10.14.6, 3.5 GHz i7), this takes ~8 seconds in mksh, compared with
  ksh's ~0.1s and bash 5's ~0.3s.  Here're `real' timing figures from
  my most recent run (these figures are quite stable):

  - mksh r57: 0m8.17s
  - ksh 93u+ 2012-08-01: 0m0.10s
  - bash 5.0.11(1)-release: 0m0.30s

  It's no surprise that ksh93 is much faster, given its heavy
  optimisation.  Striking, though, is the poor performance of mksh
  relative to the latest bash.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1855167/+subscriptions


[Bug 1855325] Re: test -nt and -ot ignore the subsecond part of file timestamps

2020-03-27 Thread Thorsten Glaser
** Changed in: mksh
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1855325

Title:
  test -nt and -ot ignore the subsecond part of file timestamps

Status in mksh:
  Fix Released

Bug description:
  Example on Linux (RHEL 8):

  $ touch a; sleep 0.1; touch b
  $ ls --full-time a b
  -rw-r--r-- 1 kendall staff 0 2019-12-05 13:41:43.483652556 -0500 a
  -rw-r--r-- 1 kendall staff 0 2019-12-05 13:41:43.585652744 -0500 b
  $ if [ a -ot b ]; then print older; fi
  $ if [[ a -ot b ]]; then print older; fi  

   
  $ 

  The last two commands should have printed "older".

  $ print $KSH_VERSION
  @(#)MIRBSD KSH R56 2018/01/14
  $ uname -sr
  Linux 4.18.0-80.el8.x86_64

  R49 on Cygwin and R46 on RHEL 7 have the same behavior.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1855325/+subscriptions


[Bug 1857826] Re: mksh isglobal ASAN heap-buffer-overflow

2020-03-27 Thread Thorsten Glaser
** Changed in: mksh
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857826

Title:
  mksh isglobal ASAN heap-buffer-overflow

Status in mksh:
  Fix Released

Bug description:
  When compiling mksh with ASAN and running [[ -v $XX ]] ($XX being an
  undefined environment variable) mksh will crash.

  $ echo $KSH_VERSION
  @(#)MIRBSD KSH R57 2019/03/01
  $ set | grep XX=  
  
  $ [[ -v $XX ]]
  =
  ==362==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf4d024d5 at 
pc 0x56763b99 bp 0xff8cc988 sp 0xff8cc978
  READ of size 1 at 0xf4d024d5 thread T0
  #0 0x56763b98  (/usr/bin/mksh+0x193b98)

  0xf4d024d5 is located 0 bytes to the right of 5-byte region 
[0xf4d024d0,0xf4d024d5)
  allocated by thread T0 here:
  #0 0xf7a285bd in __interceptor_realloc 
(/lib/i386-linux-gnu/libasan.so.5+0x1125bd)
  #1 0x565e115d  (/usr/bin/mksh+0x1115d)

  SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/bin/mksh+0x193b98) 
  Shadow bytes around the buggy address:
0x3e9a0440: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x3e9a0450: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x3e9a0460: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x3e9a0470: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x3e9a0480: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  =>0x3e9a0490: fa fa fa fa fa fa fa fa fa fa[05]fa fa fa fd fa
0x3e9a04a0: fa fa fd fa fa fa 00 fa fa fa 00 00 fa fa 00 01
0x3e9a04b0: fa fa 00 04 fa fa 00 01 fa fa fd fd fa fa fd fa
0x3e9a04c0: fa fa 07 fa fa fa fd fa fa fa fd fa fa fa fd fd
0x3e9a04d0: fa fa 00 fa fa fa fd fa fa fa fa fa fa fa fa fa
0x3e9a04e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable:   00
Partially addressable: 01 02 03 04 05 06 07 
Heap left redzone:   fa
Freed heap region:   fd
Stack left redzone:  f1
Stack mid redzone:   f2
Stack right redzone: f3
Stack after return:  f5
Stack use after scope:   f8
Global redzone:  f9
Global init order:   f6
Poisoned by user:f7
Container overflow:  fc
Array cookie:ac
Intra object redzone:bb
ASan internal:   fe
Left alloca redzone: ca
Right alloca redzone:cb
Shadow gap:  cc
  ==362==ABORTING

To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857826/+subscriptions


[Bug 1857195] Re: here string behaviour different in mksh and ksh93

2020-03-27 Thread Thorsten Glaser
** Changed in: mksh
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857195

Title:
  here string behaviour different in mksh and ksh93

Status in mksh:
  Fix Released

Bug description:
  consider

  IFS=$'\n'
  x=(a "b c")
  cat <<< ${x[*]}
  cat <<< "${x[*]}"
  cat <<< ${x[@]}
  cat <<< "${x[@]}"

  executing this in mksh (or zsh, incidentally) yields the output

  a
  b c
  a
  b c
  a
  b c
  a
  b c

  (i.e. identical output, always inserting first IFS char between
  elements, for all variants of accessing all elements of the array)
  while ksh93 (or bash, for that matter) yields

  a
  b c
  a
  b c
  a b c
  a b c

  (i.e. `*' behaves different from `@' but double quoting is
  ineffectual).

  I am not sure whether this is a bug (either in ksh93 or mksh) but wanted to 
report this inconsistency and to ask for clarification. what I _would_ have 
expected to start with is, that
  the above "here string" commands would yield the same output as

  print ${x[*]}
  print "${x[*]}"
  print ${x[@]}
  print "${x[@]}"

  which is neither true for ksh93 nor for mksh. is this all good and
  well and I am only overlooking something obvious?

To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857195/+subscriptions


[Bug 1857828] Re: mksh expand ASAN heap-buffer-overflow

2020-03-27 Thread Thorsten Glaser
** Changed in: mksh
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857828

Title:
  mksh expand ASAN heap-buffer-overflow

Status in mksh:
  Fix Released

Bug description:
  ubuntu@bashfz:~/newmksh/mksh$ mksh -c 'echo ${0@#$0}'
  =
  ==4807==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf4d01559 
at pc 0x56649efd bp 0xffe0e668 sp 0xffe0e658
  READ of size 1 at 0xf4d01559 thread T0
  #0 0x56649efc  (/usr/bin/mksh+0x7befc)

  0xf4d01559 is located 0 bytes to the right of 9-byte region 
[0xf4d01550,0xf4d01559)
  allocated by thread T0 here:
  #0 0xf7aae5bd in __interceptor_realloc 
(/lib/i386-linux-gnu/libasan.so.5+0x1125bd)
  #1 0x565df15d  (/usr/bin/mksh+0x1115d)

  SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/bin/mksh+0x7befc) 
  Shadow bytes around the buggy address:
0x3e9a0250: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x3e9a0260: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x3e9a0270: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x3e9a0280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x3e9a0290: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  =>0x3e9a02a0: fa fa fa fa fa fa fa fa fa fa 00[01]fa fa 00 01
0x3e9a02b0: fa fa 00 01 fa fa 00 01 fa fa 00 fa fa fa 00 00
0x3e9a02c0: fa fa 00 05 fa fa 00 04 fa fa fd fd fa fa fd fd
0x3e9a02d0: fa fa fd fd fa fa fd fd fa fa fd fd fa fa fd fd
0x3e9a02e0: fa fa fd fd fa fa fd fd fa fa fa fa fa fa fa fa
0x3e9a02f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable:   00
Partially addressable: 01 02 03 04 05 06 07 
Heap left redzone:   fa
Freed heap region:   fd
Stack left redzone:  f1
Stack mid redzone:   f2
Stack right redzone: f3
Stack after return:  f5
Stack use after scope:   f8
Global redzone:  f9
Global init order:   f6
Poisoned by user:f7
Container overflow:  fc
Array cookie:ac
Intra object redzone:bb
ASan internal:   fe
Left alloca redzone: ca
Right alloca redzone:cb
Shadow gap:  cc
  ==4807==ABORTING

  ubuntu@bashfz:~/newmksh/mksh$ valgrind ./mksh -c 'echo ${0@#$0}'
  ==4808== Memcheck, a memory error detector
  ==4808== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
  ==4808== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
  ==4808== Command: ./mksh -c echo\ ${0@#$0}
  ==4808== 
  ==4808== Invalid read of size 1
  ==4808==at 0x118527: expand (eval.c:821)
  ==4808==by 0x11AABD: eval (eval.c:154)
  ==4808==by 0x11C630: execute (exec.c:124)
  ==4808==by 0x1335E1: shell (main.c:908)
  ==4808==by 0x10B118: main (main.c:704)
  ==4808==  Address 0x4a36873 is 0 bytes after a block of size 11 alloc'd
  ==4808==at 0x483453B: malloc (in 
/usr/lib/i386-linux-gnu/valgrind/vgpreload_memcheck-x86-linux.so)
  ==4808==by 0x4836C88: realloc (in 
/usr/lib/i386-linux-gnu/valgrind/vgpreload_memcheck-x86-linux.so)
  ==4808==by 0x10B68C: aresize (lalloc.c:154)
  ==4808==by 0x1420F0: setstr (var.c:491)
  ==4808==by 0x14300F: isglobal (var.c:272)
  ==4808==by 0x14305D: global (var.c:238)
  ==4808==by 0x11A9E5: varsub (eval.c:1378)
  ==4808==by 0x11A9E5: expand (eval.c:390)
  ==4808==by 0x11AABD: eval (eval.c:154)
  ==4808==by 0x11C630: execute (exec.c:124)
  ==4808==by 0x1335E1: shell (main.c:908)
  ==4808==by 0x10B118: main (main.c:704)
  ==4808== 
  ==4808== Invalid read of size 1
  ==4808==at 0x1173CF: expand (eval.c:869)
  ==4808==by 0x11AABD: eval (eval.c:154)
  ==4808==by 0x11C630: execute (exec.c:124)
  ==4808==by 0x1335E1: shell (main.c:908)
  ==4808==by 0x10B118: main (main.c:704)
  ==4808==  Address 0x4a36873 is 0 bytes after a block of size 11 alloc'd
  ==4808==at 0x483453B: malloc (in 
/usr/lib/i386-linux-gnu/valgrind/vgpreload_memcheck-x86-linux.so)
  ==4808==by 0x4836C88: realloc (in 
/usr/lib/i386-linux-gnu/valgrind/vgpreload_memcheck-x86-linux.so)
  ==4808==by 0x10B68C: aresize (lalloc.c:154)
  ==4808==by 0x1420F0: setstr (var.c:491)
  ==4808==by 0x14300F: isglobal (var.c:272)
  ==4808==by 0x14305D: global (var.c:238)
  ==4808==by 0x11A9E5: varsub (eval.c:1378)
  ==4808==by 0x11A9E5: expand (eval.c:390)
  ==4808==by 0x11AABD: eval (eval.c:154)
  ==4808==by 0x11C630: execute (exec.c:124)
  ==4808==by 0x1335E1: shell (main.c:908)
  ==4808==by 0x10B118: main (main.c:704)
  ==4808== 

  ==4808== 
  ==4808== HEAP SUMMARY:
  ==4808== in use at exit: 0 bytes in 0 blocks
  ==4808==   total heap usage: 

[Bug 1857702] Re: " +=" operator does string concatenation for integer variables

2020-03-27 Thread Thorsten Glaser
** Changed in: mksh
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1857702

Title:
  " +=" operator does string concatenation for integer variables

Status in mksh:
  Fix Released

Bug description:
  consider

  typeset -i x=0; x+=1; echo $x # → 1 (as in ksh/bash/zsh)

  but

  typeset -i x=1; x+=1; echo $x # → 11 (rather than 2 as in the other
  shells)

  I believe mksh should honour the integer declaration and interpret
  `+=' accordingly. currently, it does not even consistently use string
  concatentation (since the first example does not yield `01' ...).

To manage notifications about this bug go to:
https://bugs.launchpad.net/mksh/+bug/1857702/+subscriptions


[Bug 1779179] Re: nōn-ASCII heredoc separators

2020-03-27 Thread Thorsten Glaser
** Changed in: mksh
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of mksh
Mailing List, which is subscribed to mksh.
Matching subscriptions: mkshlist-to-mksh-bugmail
https://bugs.launchpad.net/bugs/1779179

Title:
  nōn-ASCII heredoc separators

Status in mksh:
  Fix Released

Bug description:
  tglase@tglase-nb:~ $ mksh -c $':