a string buffer whose window size is currently 32 (initial), your data
is 96 bytes, this routine used to resize the buffer to 64, append your
first 64 bytes to it (no matter if there's already something in it)
and then writes the remaining bytes to stdio fd instead of the string…
if it doesn’t SIGABRT before
discovered by wbx@ – thanks – bug inherited from pdksh 5.2.14 (AD 1999)
• deactivate %a and %A since our libc doesn’t have it
• rewrite the mksh integration code to use shf instead of stdio, removing
floating point support always in the process, as shf doesn’t support it
⇒ saves 11114 (6706 text, 168 data, 4240 bss) with dietlibc on Debian
• fix -Wall -Wextra -Wformat -Wstrict-aliasing=2 for gcc (Debian 4.4.4-7)
• fix these and -Wc++-compat for gcc version 4.6.0 20100711 (experimental)
[trunk revision 162057] (Debian 20100711-1) except:
– a few enum warnings that relate to eglibc’s {g,s}etrlimit() functions
taking an enum instead of an int because they’re too stupid to adhere
to POSIX interfaces they design by themselves
– all “request for implicit conversion” involving a "void *" on one side
• tweak the manual page somewhat more
Revision 1.136: [7]download - view: [8]text, [9]markup, [10]annotated - [11]select for diffs
Thu Jul 15 20:04:35 2010 UTC (47 hours, 56 minutes ago) by schwarze
Branches: [12]MAIN
CVS tags: [13]HEAD
Diff to: previous 1.135: [14]preferred, [15]coloured
Changes since revision 1.135: +7 -7 lines
When the first argument or arguments of a macro are opening delimiters
(parentheses and/or square brackets), both modern groff and mandoc first
output those leading delimiters as plain text, then start the macro scope
after these opening delimiters. This is similar to printing trailing
punctuation and trailing closing delimiters on a macro line outside and
after the macro scope. For example, ".Sq ( text )" is "(`text')",
not "`(text)'". Thus, we now need to quote leading opening delimiters
when we want them inside the macro scope.
These are the cases in src/bin.
"makes sense" jmc@
until R40 is definitively out (so there MAY still be an R39d)
this commit can easily be reverted in its entirety later, when
Build.sh’s compatibility for “-combine” &c. is removed too
comment what/why added (to aid understanding this code)
I wonder, though, why their x_escape now almost¹ looks like ours… is
that a coïncidence, or do they steal again (without understanding why)?
① they’re missing the semicolon but falsely added the closing bracket
‣ -combine → -c combine
‣ -llvm → -c llvm -O
‣ -llvm=x → -c llvm -o x
‣ -valgrind → -g²
• new option -v (version)
• new options -c (compile mode³), -o (opt flags), -O (reset opt flags)
• opt flags default to -std-compile-opts (llvm) now
• support⁴ the LLVM dragonegg plugin for GCC
• sync list of removed files (*.bc, *.ll, add missing Rebuild.sh)
① old options still valid but emit a warning
② except this one
③ compile modes are:
• normal
• makefile (-M)
• combine (old -combine, new -c combine)
• dragonegg (new -c dragonegg)
• llvm (old -llvm, old -llvm=*, new -c llvm)
the first two are not settable via -c though…
④ sample use:
tg@seduxbox:~/x$ export PATH=$PATH:/opt/llvm/bin
tg@seduxbox:~/x$ CC='/opt/gcc-4.5.1/bin/gcc-4.5.1 -fplugin=/opt/llvm/lib/dragonegg.so' sh ../mksh/Build.sh -c dragonegg -r
Thanks to «dileX:#grml» for giving ssh access.
• avoid calling realloc twice in sequence, since the final
size is known at the first call already
• do not lstat(2) the same path twice in the Hurd codepath
tg