Why does bash use xmalloc?
Hi, The following example shows that bash uses xmalloc. But it seems
that using xmalloc is not a good practice. Is it better to use malloc
instead of xmalloc? In this test case, after `./main 100` failed I
still want to run the rest commands. So it sounds like malloc is
better.
http://stackoverflow.com/questions/7590254/what-is-the-difference-between-xmalloc-and-malloc
~$ cat main.sh
#!/usr/bin/env bash
# vim: set noexpandtab tabstop=2:
ulimit -Sv 1000
set -v
./main 10
./main 100
./main 1000
./main 1
~$ cat main.c
// vim: set noexpandtab tabstop=2:
#include
#include
int main(int argc, char *argv[]) {
//printf("%s\n", "Hello World!");
size_t size = atoi(argv[1]);
void *ptr;
if((ptr = malloc(size)) == NULL) {
perror("malloc");
exit(2);
} else {
printf("%p\n", ptr);
free(ptr);
}
return 0;
}
~$ ./main.sh
./main 10
./main.sh: xmalloc: .././variables.c:3997: cannot allocate 1313 bytes
(53248 bytes allocated)
--
Regards,
Peng
Re: [bug] [[ $'\Ux' = $'\Ux' ]] returns false for some values of x in some locales
On 11/4/16 8:29 AM, Stephane Chazelas wrote: > Most of the problematic characters are the ones ending in 0x5c > (which happens to be backslash in ASCII (or in BIG5-HKSCS when > standing alone). There are a couple of issues here. The first is that the glibc locales really do have a problem for ca/ea/cb/eb, since the locales on Mac OS X don't produce any error. The second is that all the rest of the failing tests are the ones where the pattern ends in a backslash. For many years, since at least 1997 when the full Posix.2 pattern matching code came in, patterns ending with a backslash fail to match unconditionally. I can't find anything specifically referring to this particular change -- it was pretty much a complete fnmatch rewrite -- and the rationale has faded in the intervening 20 years. I think it's safe at this point to allow a trailing backslash in a pattern to match a trailing backslash in the string. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/ signature.asc Description: OpenPGP digital signature
Re: 'kill -l' outputs SIG prefix if job control not compiled in
On 11/4/16 6:30 PM, Martijn Dekker wrote: > Normal bash: > > $ kill -l 141 > PIPE > > Bash compiled with --enable-minimal-config --enable-alias: > > $ kill -l 141 > SIGPIPE > > That SIG prefix shouldn't be there. (Enabling POSIX mode makes no > difference to the output.) Bash's minimal configuration chose to keep output the same as historical versions of sh. While the 7th edition sh omitted the SIG prefix, the System V versions, including SVR4.2 (the most recent I have access to) include it. > > A look at the source tells me that, for some reason, the POSIXly correct > output of 'kill -l' was made dependent on job control being compiled in. > I don't see any reason for that, so unless I'm missing something, the > attached patch should fix it. I assume that the Posix 1992 version made both kill -l and job control part of the XSI portion of the standard. I don't have access to that printed copy right now, so I can only speculate. In any case, there's no reason to not fix this now. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bug with && in piped functions in minimal-config bash
On 11/4/16 5:41 PM, Martijn Dekker wrote:
> My development with Modernish just exposed the following bug on bash
> 4.4.0(1)-maint, bash-20161028 snapshot, compiled with
> --enable-minimal-config --enable-alias:
>
> $ fn() { false && echo bug || echo ok; }
> $ fn
> ok
> $ fn
> ok
> $ fn | cat
> ok
> $ fn | cat
> bug
Thanks for the report. This is an easy fix; similar to that from 9/23
based on your bug report then.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: memory leak in execute_simple_command when dofork is true
On 11/4/16 2:02 AM, Eduardo A. Bustamante López wrote: > Actually, there are more leaks in execute_cmd.c, I'm just going to list them > here. Thanks for the pointers, no pun intended. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
"builtin printf '\uFF8E'" generates broken surrogate pairs in Cygwin
Hello, let me send a bashbug report as follows.
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: cygwin
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='i686-pc-cygwin'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I.
-I/usr/src/bash-4.3.46-7.i686/src/bash-4.3
-I/usr/src/bash-4.3.46-7.i686/src/bash-4.3/include
-I/usr/src/bash-4.3.46-7.i686/src/bash-4.3/lib -DWORDEXP_OPTION -ggdb
-O2 -pipe -Wimplicit-function-declaration
-fdebug-prefix-map=/usr/src/bash-4.3.46-7.i686/build=/usr/src/debug/bash-4.3.46-7
-fdebug-prefix-map=/usr/src/bash-4.3.46-7.i686/src/bash-4.3=/usr/src/debug/bash-4.3.46-7
uname output: CYGWIN_NT-10.0-WOW magnate2016 2.6.0(0.304/5/3)
2016-08-31 14:27 i686 Cygwin
Machine Type: i686-pc-cygwin
Bash Version: 4.3
Patch Level: 46
Release Status: release
Description:
I noticed that built-in commands "printf '\uFF8E'", etc. generate
broken surrogate pairs in Cygwin.
Repeat-By:
$ echo $MACHTYPE
i686-pc-cygwin
$ echo $LANG
ja_JP.UTF-8
$ printf '\uFF8E\n' # <-- U+FF8E is "halfwidth kana Ho", one of
Japanese characters.
?? # <-- Some unknown characters are output.
$ /bin/printf '\uFF8E\n'
ﾎ # <-- OK with /bin/printf
$ printf '\uFF8E' | od -t x1 -A n
ed 9f bf ed be 8e # <-- This is utf-8 representation of .
Here one notices that is a broken surrogate pair.
The first element of surrogate pairs should be in the range from
U+D800 to U+DBFF, and the second should be in the range from U+DC00 to
U+DFFF. Anyway, the character U+FF8E cannot be represented by a
surrogate pair.
Fix:
I think the function "u32toutf16 (c, s)" in lib/sh/unicode.c is
broken. Note that this function is only used in systems where "sizeof
(wchar_t) == 2". Cygwin is one of them. Also, I checked the latest
version of bash-4.4 (patch level 0) source codes, and the function is
not yet fixed there: The characters in the range from U+E000 to U+
should not be encoded in surrogate pairs; they don't have
surrogate-pair representations.
diff --git a/lib/sh/unicode.c b/lib/sh/unicode.c
index b58eaef..29acac6 100644
--- a/lib/sh/unicode.c
+++ b/lib/sh/unicode.c
@@ -219,12 +219,12 @@ u32toutf16 (c, s)
int l;
l = 0;
- if (c < 0x0d800)
+ if (c < 0x0d800 || (c >= 0x0e000 && c <= 0x0))
{
s[0] = (unsigned short) (c & 0x);
l = 1;
}
- else if (c >= 0x0e000 && c <= 0x010)
+ else if (c >= 0x1 && c <= 0x010)
{
c -= 0x01;
s[0] = (unsigned short)((c >> 10) + 0xd800);
Regards,
Koichi
