From tijl at ulyssis.org Fri Apr 3 05:50:02 2009 From: tijl at ulyssis.org (Tijl Coosemans) Date: Fri Apr 3 05:50:09 2009 Subject: standards/133339: dlfunc(3) does not respect RTLD_SELF, RTLD_NEXT, ... Message-ID: <200904031247.n33Cl4Dn006871@kalimero.kotnet.org> >Number: 133339 >Category: standards >Synopsis: dlfunc(3) does not respect RTLD_SELF, RTLD_NEXT,... >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Apr 03 12:50:01 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Tijl Coosemans >Release: FreeBSD 7.1-STABLE i386 >Organization: >Environment: FreeBSD 7.1-STABLE #4: Tue Mar 10 16:04:51 CET 2009 >Description: The dlfunc(3) function doesn't respect special handles like NULL, RTLD_SELF, RTLD_NEXT as explained in the manpage. In those cases dlsym(3) determines the list of objects to search through by looking at the return address on the stack to figure out which object the call originated from. Because dlfunc has been implemented in libc as a simple wrapper around dlsym, the return address on the stack points to libc and not the object the call originated from like the main program or another library. >How-To-Repeat: I've attached a small test program that should print the same address twice, but it currently prints NULL in the dlfunc case. >Fix: I'm guessing dlfunc has to be moved to rtld (strong alias to dlsym perhaps) and the current implementation in libc replaced with a dummy implementation like the other dl* functions in lib/libc/gen/dlfcn.c. --- test.c begins here --- #include #include int main( void ) { void *addr; addr = dlsym( RTLD_NEXT, "getpid" ); printf( "%p\n", addr ); /* this works */ addr = dlfunc( RTLD_NEXT, "getpid" ); printf( "%p\n", addr ); /* this prints NULL */ return( 0 ); } --- test.c ends here --- >Release-Note: >Audit-Trail: >Unformatted: From kib at FreeBSD.org Fri Apr 3 12:32:52 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Fri Apr 3 12:32:58 2009 Subject: standards/133339: dlfunc(3) does not respect RTLD_SELF, RTLD_NEXT, ... Message-ID: <200904031932.n33JWpF8098264@freefall.freebsd.org> Synopsis: dlfunc(3) does not respect RTLD_SELF, RTLD_NEXT,... State-Changed-From-To: open->patched State-Changed-By: kib State-Changed-When: Fri Apr 3 19:32:02 UTC 2009 State-Changed-Why: I committed the fix to HEAD. Responsible-Changed-From-To: freebsd-standards->kib Responsible-Changed-By: kib Responsible-Changed-When: Fri Apr 3 19:32:02 UTC 2009 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=133339 From jilles at stack.nl Sat Apr 4 04:06:50 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sat Apr 4 04:06:58 2009 Subject: standards/79067: /bin/sh should be more intelligent about IFS Message-ID: <20090404110633.GA25666@stack.nl> A patch similar to the 'read' part of this one was committed to -CURRENT. The other part of the patch in the PR is a bit different from NetBSD, and is wrong: it drops a final empty argument in "$@". For example, set -- a ''; set -- "$@"; echo $# should give 2, but gives 1. So I put in the NetBSD code, which does not have this issue (sh-ifs-expand-netbsd.patch). Additionally, it cleans up the code a bit. However, the NetBSD code has a related issue: it drops a final empty argument in "$@"$s where $s contains one or more characters of IFS whitespace. For example, s=' '; set -- a ''; set -- "$@"; echo $# should give 2, but gives 1. A fix for this is in sh-ifs-expand.patch. With the read change and both patches, the tests from http://www.research.att.com/~gsf/public/ifs.sh all pass. Some more tests with "$@" and IFS are in moreifs.sh. -- Jilles Tjoelker -------------- next part -------------- --- src/bin/sh/expand.c.orig 2008-09-04 19:34:53.000000000 +0200 +++ src/bin/sh/expand.c 2009-04-04 01:32:07.000000000 +0200 @@ -82,7 +82,7 @@ struct ifsregion *next; /* next region in list */ int begoff; /* offset of start of region */ int endoff; /* offset of end of region */ - int nulonly; /* search for nul bytes only */ + int inquotes; /* search for nul bytes only */ }; @@ -936,13 +936,19 @@ */ STATIC void -recordregion(int start, int end, int nulonly) +recordregion(int start, int end, int inquotes) { struct ifsregion *ifsp; if (ifslastp == NULL) { ifsp = &ifsfirst; } else { + if (ifslastp->endoff == start + && ifslastp->inquotes == inquotes) { + /* extend previous area */ + ifslastp->endoff = end; + return; + } ifsp = (struct ifsregion *)ckmalloc(sizeof (struct ifsregion)); ifslastp->next = ifsp; } @@ -950,7 +956,7 @@ ifslastp->next = NULL; ifslastp->begoff = start; ifslastp->endoff = end; - ifslastp->nulonly = nulonly; + ifslastp->inquotes = inquotes; } @@ -969,75 +975,88 @@ char *p; char *q; char *ifs; - int ifsspc; - int nulonly; - + const char *ifsspc; + int had_param_ch = 0; start = string; - ifsspc = 0; - nulonly = 0; - if (ifslastp != NULL) { - ifsp = &ifsfirst; - do { - p = string + ifsp->begoff; - nulonly = ifsp->nulonly; - ifs = nulonly ? nullstr : - ( ifsset() ? ifsval() : " \t\n" ); - ifsspc = 0; - while (p < string + ifsp->endoff) { - q = p; - if (*p == CTLESC) + + if (ifslastp == NULL) { + /* Return entire argument, IFS doesn't apply to any of it */ + sp = (struct strlist *)stalloc(sizeof *sp); + sp->text = start; + *arglist->lastp = sp; + arglist->lastp = &sp->next; + return; + } + + ifs = ifsset() ? ifsval() : " \t\n"; + + for (ifsp = &ifsfirst; ifsp != NULL; ifsp = ifsp->next) { + p = string + ifsp->begoff; + while (p < string + ifsp->endoff) { + had_param_ch = 1; + q = p; + if (*p == CTLESC) + p++; + if (ifsp->inquotes) { + /* Only NULs (should be from "$@") end args */ + if (*p != 0) { p++; - if (strchr(ifs, *p)) { - if (!nulonly) - ifsspc = (strchr(" \t\n", *p) != NULL); - /* Ignore IFS whitespace at start */ - if (q == start && ifsspc) { - p++; - start = p; - continue; - } - *q = '\0'; - sp = (struct strlist *)stalloc(sizeof *sp); - sp->text = start; - *arglist->lastp = sp; - arglist->lastp = &sp->next; + continue; + } + ifsspc = NULL; + } else { + if (!strchr(ifs, *p)) { p++; - if (!nulonly) { - for (;;) { - if (p >= string + ifsp->endoff) { - break; - } - q = p; - if (*p == CTLESC) - p++; - if (strchr(ifs, *p) == NULL ) { - p = q; - break; - } else if (strchr(" \t\n",*p) == NULL) { - if (ifsspc) { - p++; - ifsspc = 0; - } else { - p = q; - break; - } - } else - p++; - } - } - start = p; - } else + continue; + } + had_param_ch = 0; + ifsspc = strchr(" \t\n", *p); + + /* Ignore IFS whitespace at start */ + if (q == start && ifsspc != NULL) { p++; + start = p; + continue; + } } - } while ((ifsp = ifsp->next) != NULL); - if (*start || (!ifsspc && start > string)) { + + /* Save this argument... */ + *q = '\0'; sp = (struct strlist *)stalloc(sizeof *sp); sp->text = start; *arglist->lastp = sp; arglist->lastp = &sp->next; + p++; + + if (ifsspc != NULL) { + /* Ignore further trailing IFS whitespace */ + for (; p < string + ifsp->endoff; p++) { + q = p; + if (*p == CTLESC) + p++; + if (strchr(ifs, *p) == NULL) { + p = q; + break; + } + if (strchr(" \t\n", *p) == NULL) { + p++; + break; + } + } + } + start = p; } - } else { + } + + /* + * Save anything left as an argument. + * Traditionally we have treated 'IFS=':'; set -- x$IFS' as + * generating 2 arguments, the second of which is empty. + * Some recent clarification of the Posix spec say that it + * should only generate one.... + */ + if (had_param_ch || *start != 0) { sp = (struct strlist *)stalloc(sizeof *sp); sp->text = start; *arglist->lastp = sp; -------------- next part -------------- --- src/bin/sh/expand.c.netbsd 2009-04-04 01:32:07.000000000 +0200 +++ src/bin/sh/expand.c 2009-04-04 02:01:54.000000000 +0200 @@ -994,12 +994,12 @@ for (ifsp = &ifsfirst; ifsp != NULL; ifsp = ifsp->next) { p = string + ifsp->begoff; while (p < string + ifsp->endoff) { - had_param_ch = 1; q = p; if (*p == CTLESC) p++; if (ifsp->inquotes) { /* Only NULs (should be from "$@") end args */ + had_param_ch = 1; if (*p != 0) { p++; continue; @@ -1007,10 +1007,10 @@ ifsspc = NULL; } else { if (!strchr(ifs, *p)) { + had_param_ch = 1; p++; continue; } - had_param_ch = 0; ifsspc = strchr(" \t\n", *p); /* Ignore IFS whitespace at start */ @@ -1019,6 +1019,7 @@ start = p; continue; } + had_param_ch = 0; } /* Save this argument... */ -------------- next part -------------- #!/bin/sh # Copyright (c) 2009 Jilles Tjoelker # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # c=: e= s=' ' failures='' ok='' check_result() { if [ "x$2" = "x$3" ]; then ok=x$ok else failures=x$failures echo "For $1, expected $3 actual $2" fi } IFS=' ' set -- a '' set -- "$@" check_result 'set -- "$@"' "($#)($1)($2)" "(2)(a)()" set -- a '' set -- "$@"$e check_result 'set -- "$@"$e' "($#)($1)($2)" "(2)(a)()" set -- a '' set -- "$@"$s check_result 'set -- "$@"$s' "($#)($1)($2)" "(2)(a)()" IFS="$c" set -- a '' set -- "$@"$c check_result 'set -- "$@"$c' "($#)($1)($2)" "(2)(a)()" test "x$failures" = x From jilles at stack.nl Sat Apr 4 05:50:04 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sat Apr 4 05:50:19 2009 Subject: bin/25542: sh(1) null char in quoted string Message-ID: <200904041250.n34Co4Ej028406@freefall.freebsd.org> The following reply was made to PR bin/25542; it has been noted by GNATS. From: Jilles Tjoelker To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/25542: sh(1) null char in quoted string Date: Sat, 4 Apr 2009 14:41:43 +0200 Considering that fixing this would be a lot of work and cannot be done completely (for example, argument strings and environment variables cannot contain '\0'), I think it is best to close this. sh(1) is meant to process text, not binary data. Trying to process binary data may or will also cause problems if the locale character set is set to UTF-8. As a clarification, this PR is about '\0' bytes in shell scripts, not about making the echo builtin produce '\0' characters. The latter feature works fine and is good. -- Jilles Tjoelker From jilles at stack.nl Sat Apr 4 07:00:04 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sat Apr 4 07:00:10 2009 Subject: standards/133369: test(1) with 3 or 4 arguments Message-ID: <20090404135023.3C6E5228A2@snail.stack.nl> >Number: 133369 >Category: standards >Synopsis: test(1) with 3 or 4 arguments >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Apr 04 14:00:03 UTC 2009 >Closed-Date: >Last-Modified: >Originator: Jilles Tjoelker >Release: FreeBSD 7.2-PRERELEASE i386 >Organization: MCGV Stack >Environment: >Description: test(1) does not follow the rules in POSIX exactly if there are 3 or 4 arguments, different from what the man page says. In particular, different from what POSIX prescribes, test "$a" = "$b" does not work properly for all values of $a and $b. /bin/test and the test builtin in /bin/sh use the same code. >How-To-Repeat: An example, more tests are included in the patch. Input: /bin/test \( = \); echo $? Expected result: 1 Actual result: 0 According to POSIX, the rule about the second argument being a binary operator has priority above the rule about the first argument being '(' and the third argument being ')'. >Fix: Apply this patch. It includes additional test cases in TEST.sh. --- test-posixfixes.patch begins here --- --- src/bin/test/test.c.orig 2005-01-10 09:39:26.000000000 +0100 +++ src/bin/test/test.c 2009-04-02 02:28:28.000000000 +0200 @@ -163,6 +163,7 @@ struct t_op const *t_wp_op; int nargc; char **t_wp; +int parenlevel; static int aexpr(enum token); static int binop(void); @@ -171,7 +172,9 @@ static int getn(const char *); static intmax_t getq(const char *); static int intcmp(const char *, const char *); -static int isoperand(void); +static int isunopoperand(void); +static int islparenoperand(void); +static int isrparenoperand(void); static int newerf(const char *, const char *); static int nexpr(enum token); static int oexpr(enum token); @@ -205,7 +208,14 @@ #endif nargc = argc; t_wp = &argv[1]; - res = !oexpr(t_lex(*t_wp)); + parenlevel = 0; + if (nargc == 4 && strcmp(*t_wp, "!") == 0) { + /* Things like ! "" -o x do not fit in the normal grammar. */ + --nargc; + ++t_wp; + res = oexpr(t_lex(*t_wp)); + } else + res = !oexpr(t_lex(*t_wp)); if (--nargc > 0) syntax(*t_wp, "unexpected operator"); @@ -268,12 +278,16 @@ if (n == EOI) return 0; /* missing expression */ if (n == LPAREN) { + parenlevel++; if ((nn = t_lex(nargc > 0 ? (--nargc, *++t_wp) : NULL)) == - RPAREN) + RPAREN) { + parenlevel--; return 0; /* missing expression */ + } res = oexpr(nn); if (t_lex(nargc > 0 ? (--nargc, *++t_wp) : NULL) != RPAREN) syntax(NULL, "closing paren expected"); + parenlevel--; return res; } if (t_wp_op && t_wp_op->op_type == UNOP) { @@ -410,8 +424,10 @@ } while (op->op_text) { if (strcmp(s, op->op_text) == 0) { - if ((op->op_type == UNOP && isoperand()) || - (op->op_num == LPAREN && nargc == 1)) + if (((op->op_type == UNOP || op->op_type == BUNOP) + && isunopoperand()) || + (op->op_num == LPAREN && islparenoperand()) || + (op->op_num == RPAREN && isrparenoperand())) break; t_wp_op = op; return op->op_num; @@ -423,7 +439,7 @@ } static int -isoperand(void) +isunopoperand(void) { struct t_op const *op = ops; char *s; @@ -431,19 +447,53 @@ if (nargc == 1) return 1; - if (nargc == 2) - return 0; s = *(t_wp + 1); + if (nargc == 2) + return parenlevel == 1 && strcmp(s, ")") == 0; t = *(t_wp + 2); while (op->op_text) { if (strcmp(s, op->op_text) == 0) return op->op_type == BINOP && - (t[0] != ')' || t[1] != '\0'); + (parenlevel == 0 || t[0] != ')' || t[1] != '\0'); + op++; + } + return 0; +} + +static int +islparenoperand(void) +{ + struct t_op const *op = ops; + char *s; + + if (nargc == 1) + return 1; + s = *(t_wp + 1); + if (nargc == 2) + return parenlevel == 1 && strcmp(s, ")") == 0; + if (nargc != 3) + return 0; + while (op->op_text) { + if (strcmp(s, op->op_text) == 0) + return op->op_type == BINOP; op++; } return 0; } +static int +isrparenoperand(void) +{ + char *s; + + if (nargc == 1) + return 0; + s = *(t_wp + 1); + if (nargc == 2) + return parenlevel == 1 && strcmp(s, ")") == 0; + return 0; +} + /* atoi with error detection */ static int getn(const char *s) --- src/bin/test/TEST.sh.orig 2005-01-10 09:39:26.000000000 +0100 +++ src/bin/test/TEST.sh 2009-04-03 22:53:28.000000000 +0200 @@ -133,5 +133,35 @@ t 1 '""' t 0 '! ""' +t 0 '!' +t 0 '\(' +t 0 '\)' + +t 1 '\( = \)' +t 0 '\( != \)' +t 0 '\( ! \)' +t 0 '\( \( \)' +t 0 '\( \) \)' +t 0 '! = !' +t 1 '! != !' +t 1 '-n = \)' +t 0 '! != \)' +t 1 '! = a' +t 0 '! != -n' +t 0 '! -c /etc/passwd' + +t 0 '! \( = \)' +t 1 '! \( != \)' +t 1 '! = = =' +t 0 '! = = \)' +t 0 '! "" -o ""' +t 1 '! "x" -o ""' +t 1 '! "" -o "x"' +t 1 '! "x" -o "x"' +t 0 '\( -f /etc/passwd \)' +t 1 '\( ! = \)' +t 0 '\( ! "" \)' +t 1 '\( ! -e \)' + echo "" echo "Syntax errors: $ERROR Failed: $FAILED" --- test-posixfixes.patch ends here --- >Release-Note: >Audit-Trail: >Unformatted: From jilles at stack.nl Sat Apr 4 07:56:45 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Sat Apr 4 07:56:52 2009 Subject: bin/108118: [libc] files should not cache their EOF status Message-ID: <20090404145629.GA31339@stack.nl> The way I read POSIX, FreeBSD's current behaviour seems correct. Calling fread(3) is equivalent to calling fgetc(3) an appropriate number of times, and fgetc(3) shall fail if the end-of-file indicator is set for the stream, even if data is available on the underlying file. Apparently, POSIX aligns with the C standard here; System V tradition is not to check the end-of-file indicator here. Both src/lib/libc/stdio/refill.c (__srefill()) and Solaris fgetc(3) manpage agree about this. -- Jilles Tjoelker From stefanf at FreeBSD.org Sat Apr 4 12:26:20 2009 From: stefanf at FreeBSD.org (Stefan Farfeleder) Date: Sat Apr 4 12:26:28 2009 Subject: FW: shell choice freebsd git port In-Reply-To: <20090322214741.GA50879@stack.nl> References: <20090322144753.GA48259@atarininja.org> <20090322214741.GA50879@stack.nl> Message-ID: <20090404190838.GA1352@lizard.fafoe.narf.at> On Sun, Mar 22, 2009 at 10:47:41PM +0100, Jilles Tjoelker wrote: > On Sun, Mar 22, 2009 at 10:47:53AM -0400, Wesley Shields wrote: > > As the maintainer of devel/git I'd like this port to do the right thing, > > but I'm not sure if this is a legitimate bug in our /bin/sh or not. > > Anyone care to comment on this? > > > ----- Forwarded message from Jeff King ----- > > > Date: Sun, 22 Mar 2009 05:37:10 -0400 > > From: Jeff King > > To: wxs@freebsd.org > > Subject: shell choice freebsd git port > > > Hi, > > > I'm one of the upstream developers of git, and it looks like you are the > > git ports maintainer for FreeBSD. I wanted to discuss an issue which you > > may run into while packaging git 1.6.2.1. > > > It seems that FreeBSD's /bin/sh treats blank lines in an eval as a > > successful command. E.g., (the output is from FreeBSD 6.1, but I built > > the current HEAD from anoncvs and it seems to have the same problem): > > > $ /bin/sh > > $ eval 'false > > > > ' > > $ echo $? > > 0 > > > (whereas bash and dash would print '1'). > > > This is problematic for our test suite, which consists of a lot of > > eval'ing. Failing tests may be missed if their status is ignored, one > > test in 1.6.2.1 which expects a non-zero exit status actually does > > report failure when it actually succeeded. On top of that, some of the > > scripts (like bisect and filter-branch) care about the exit status of > > evals at run-time to determine whether an error occurred. > > > There is some discussion on the git list here: > > > http://thread.gmane.org/gmane.comp.version-control.git/112519/focus=112621 > > > I don't know if you want to do anything to the port to work around this. > > The obvious solution is requiring bash, and setting SHELL_PATH > > appropriately in the Makefile. You may also want to see if anyone is > > interested in treating this like a bug in /bin/sh and fixing it (I > > consider it a bug, but others may consider it historical behavior, I > > suppose). > > As discussed on IRC, I think this is a bug in /bin/sh. > > Just from reading the code, NetBSD does not seem to have fixed this. > > The following patch seems to fix the problem: > http://www.stack.nl/~jilles/unix/sh-eval-emptyline.patch > > Apart from 'eval', also 'trap', 'fc' and strings passed with '-c' are > affected. > > Empty lines inside {}, if or similar constructs are treated differently > and work fine even without the patch. Committed, thanks! From bugmaster at FreeBSD.org Mon Apr 6 04:07:05 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 6 04:09:17 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200904061107.n36B72Tj062020@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/133369 standards test(1) with 3 or 4 arguments o stand/130067 standards Wrong numeric limits in system headers? o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [locale] [patch] Invalid (long)date format in pl_PL.IS o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 52 problems total. From MondoBancoPosta at bancopostaonline.net Mon Apr 6 12:44:47 2009 From: MondoBancoPosta at bancopostaonline.net (MondoBancoPosta) Date: Mon Apr 6 12:44:55 2009 Subject: Premio vi aspetta! Message-ID: <1239045563.43873.qmail@Poste-italiane.it> Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltą. Per ricevere il bonus č necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltą » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From mailing at gaturkey.com Thu Apr 9 00:43:07 2009 From: mailing at gaturkey.com (Global Access Travel) Date: Thu Apr 9 00:43:35 2009 Subject: Private Shore Excursions-Turkey Message-ID: <7c02a59f40140f41df49629f083df54a@localhost.localdomain> [http://www.turkeycalling.us] PRIVATE SHORE EXCURSIONS- TURKEY Your cruise clients will make the best of their time in Turkey on a private shore excursion! Istanbul Kusadasi & Ephesus [mailto:incoming@gaturkey.com?subject=Private Shore Excursions- Turkey] **************************************************************************** Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Turizm Hizmetleri Anonim Sirketi bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez. **************************************************************************** Disclaimer; This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Turizm Hizmetleri Anonim Sirketi does not accept legal responsibility for the contents of this message. *********************************************************************************************** Yasal Uyar?; Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir, yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve sisteminizden siliniz. Global Turizm Hizmetleri Anonim Sirketi bu mesajin icerigi ile ilgili olarak hicbir hukuksal sorumlulugu kabul etmez. ********************************************************************************************** Disclaimer; This e-mail communication is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and that may not be made public by law or agreement. If the recipient of this message is not the intended recipient or entity, you are hereby notified that any further dissemination, distribution or copying of this information is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete it from your system. The Global Turizm Hizmetleri Anonim Sirketi does not accept legal responsibility for the contents of this message. This message was sent by: Global Access Incoming, Nuzhetiye cad, istanbul, besiktas 34357, Turkey Powered by iContact: http://freetrial.icontact.com To be removed click here: http://app.icontact.com/icp/mmail-mprofile.pl?r=46043491&l=82228&s=LDRR&m=562566&c=305227 Forward to a friend: http://app.icontact.com/icp/sub/forward?m=562566&s=46043491&c=LDRR&cid=305227 From jilles at stack.nl Fri Apr 10 03:59:09 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Fri Apr 10 03:59:16 2009 Subject: bin/125855: sh(1) allows for multiline, non-escaped control structures (and thus isn't POSIX compliant) Message-ID: <20090410105853.GA96273@stack.nl> > [ sh allows ! ] I would consider this an extension to the standard, which sh(1) is free to implement. Removing the extension, possibly gratuitously breaking scripts, seems a bad idea. The script is what should be fixed. -- Jilles Tjoelker From jilles at stack.nl Fri Apr 10 04:00:14 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Fri Apr 10 04:00:21 2009 Subject: bin/125855: sh(1) allows for multiline, non-escaped control structures (and thus isn't POSIX compliant) Message-ID: <200904101100.n3AB0DHO096545@freefall.freebsd.org> The following reply was made to PR bin/125855; it has been noted by GNATS. From: Jilles Tjoelker To: bug-followup@FreeBSD.org, gcooper@FreeBSD.org, freebsd-standards@FreeBSD.org Cc: Subject: Re: bin/125855: sh(1) allows for multiline, non-escaped control structures (and thus isn't POSIX compliant) Date: Fri, 10 Apr 2009 12:58:53 +0200 > [ sh allows ! ] I would consider this an extension to the standard, which sh(1) is free to implement. Removing the extension, possibly gratuitously breaking scripts, seems a bad idea. The script is what should be fixed. -- Jilles Tjoelker From bugmaster at FreeBSD.org Mon Apr 13 04:07:02 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 13 04:35:05 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200904131107.n3DB71b3085099@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/133369 standards [patch] test(1) with 3 or 4 arguments o stand/130067 standards Wrong numeric limits in system headers? o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [locale] [patch] Invalid (long)date format in pl_PL.IS o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 52 problems total. From gavin at FreeBSD.org Thu Apr 16 05:42:21 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Apr 16 06:36:19 2009 Subject: bin/108390: [libc] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] Message-ID: <200904161242.n3GCgG4u063936@freefall.freebsd.org> Synopsis: [libc] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] State-Changed-From-To: closed->open State-Changed-By: gavin State-Changed-When: Thu Apr 16 12:37:19 UTC 2009 State-Changed-Why: Reopen, there's some question about whether the bug reported here is indeed a bug: FreeBSD behaves differently to both Solaris 10 and Linux (Ubuntu 8.04) in how wait4() functions. Responsible-Changed-From-To: freebsd-bugs->freebsd-standards Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 16 12:37:19 UTC 2009 Responsible-Changed-Why: Over to -standards. There is some debate as to what the correct behaviour is here, hopefully -standards will be able to provide an opinion. http://www.freebsd.org/cgi/query-pr.cgi?pr=108390 From gavin at FreeBSD.org Thu Apr 16 05:50:04 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Thu Apr 16 06:39:36 2009 Subject: standards/108390: [libc] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] Message-ID: <200904161250.n3GCo3YX064225@freefall.freebsd.org> The following reply was made to PR standards/108390; it has been noted by GNATS. From: Gavin Atkinson To: bug-followup@FreeBSD.org Cc: Subject: Re: standards/108390: [libc] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] Date: Thu, 16 Apr 2009 13:45:44 +0100 Results from supplied test script on Solaris 10: default SIGCHLD 1239885904 2692 P spawned running child 1239885904 2693 C1 Long child sleeping 1239885904 2692 P spawned short running child; waitpid 1239885904 2694 C2 short child: exiting immediately 1239885904 2692 P short child finished 1239885904 2692 P waiting for long running child 1239885914 2693 C1 Long exiting 1239885914 2692 P long child finished. End of test. IGNORE SIGCHLD 1239885914 2692 P spawned running child 1239885914 2695 C1 Long child sleeping 1239885914 2692 P spawned short running child; waitpid 1239885914 2696 C2 short child: exiting immediately 1239885914 2692 P short child finished 1239885914 2692 P waiting for long running child 1239885924 2695 C1 Long exiting 1239885924 2692 P long child finished. End of test. Results from Linux (Ubuntu 8.10): default SIGCHLD 1239885858 2057 P spawned running child 1239885858 2058 C1 Long child sleeping 1239885858 2059 C2 short child: exiting immediately 1239885858 2057 P spawned short running child; waitpid 1239885858 2057 P short child finished 1239885858 2057 P waiting for long running child 1239885868 2058 C1 Long exiting 1239885868 2057 P long child finished. End of test. IGNORE SIGCHLD 1239885868 2057 P spawned running child 1239885868 2060 C1 Long child sleeping 1239885868 2061 C2 short child: exiting immediately 1239885868 2057 P spawned short running child; waitpid 1239885868 2057 P short child finished 1239885868 2057 P waiting for long running child 1239885878 2060 C1 Long exiting 1239885878 2057 P long child finished. End of test. From jilles at stack.nl Thu Apr 16 15:30:03 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Thu Apr 16 15:52:45 2009 Subject: kern/27835: [libc] execve() doesn't conform to execve(2) spec in syscall manual Message-ID: <200904162230.n3GMU2lL042689@freefall.freebsd.org> The following reply was made to PR kern/27835; it has been noted by GNATS. From: Jilles Tjoelker To: bug-followup@FreeBSD.org, jyliu@163.net Cc: Subject: Re: kern/27835: [libc] execve() doesn't conform to execve(2) spec in syscall manual Date: Fri, 17 Apr 2009 00:26:57 +0200 POSIX says that passing 0 arguments in execve() is allowed, but an application doing it is not strictly POSIX compliant, and that applications must handle being started with 0 arguments. The Solaris 10 man page says something similar. The test program fails with EFAULT on 7.x, but passing 0 arguments is still possible by changing the execve call to execve("/bin/sh", (char*[]){ NULL }, NULL) That change is good because a null pointer for argv yields undefined behaviour (like any function parameter outside the permitted domain). Another reason not to apply the patch to the kernel is that it uses EINVAL which POSIX already defines for a different purpose that seems useful to me: to indicate binaries with correct permissions and a valid file format that are not supported (e.g. wrong architecture). This situation currently results in ENOEXEC. Implementing the POSIX EINVAL could improve the 'Syntax error: "(" unexpected' message you get when trying to execute an ELF binary for the wrong architecture in sh; some other shells and the execlp(3) and execvp(3) libc functions also assume an executable is a shell script when they get ENOEXEC. -- Jilles Tjoelker From kib at FreeBSD.org Sun Apr 19 19:55:26 2009 From: kib at FreeBSD.org (kib@FreeBSD.org) Date: Sun Apr 19 19:55:32 2009 Subject: standards/108390: [kern] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] Message-ID: <200904191955.n3JJtQ6f072245@freefall.freebsd.org> Old Synopsis: [libc] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] New Synopsis: [kern] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] Responsible-Changed-From-To: freebsd-standards->kib Responsible-Changed-By: kib Responsible-Changed-When: Sun Apr 19 19:54:31 UTC 2009 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=108390 From kostikbel at gmail.com Sun Apr 19 20:15:50 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Apr 19 20:15:56 2009 Subject: bin/108390: [libc] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] In-Reply-To: <200904161242.n3GCgG4u063936@freefall.freebsd.org> References: <200904161242.n3GCgG4u063936@freefall.freebsd.org> Message-ID: <20090419195409.GY3014@deviant.kiev.zoral.com.ua> Further check on Solaris revealed that for the case where SIGCHLD is ignored, wait4() returned -1/ECHLD, conforming to the FreeBSD behaviour of reparenting to init. Unless further comments are given, I will commit this in several days: diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index 4255734..c35c6f2 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -504,13 +504,13 @@ exit1(struct thread *td, int rv) proc_reparent(p, initproc); p->p_sigparent = SIGCHLD; PROC_LOCK(p->p_pptr); + /* - * If this was the last child of our parent, notify - * parent, so in case he was wait(2)ing, he will + * Notify parent, so in case he was wait(2)ing or + * executiing waitpid(2) with our pid, he will * continue. */ - if (LIST_EMPTY(&pp->p_children)) - wakeup(pp); + wakeup(pp); } else mtx_unlock(&p->p_pptr->p_sigacts->ps_mtx); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-standards/attachments/20090419/4a230892/attachment.pgp From bugmaster at FreeBSD.org Mon Apr 20 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 20 11:09:14 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200904201106.n3KB6xsc033168@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/133369 standards [patch] test(1) with 3 or 4 arguments o stand/130067 standards Wrong numeric limits in system headers? o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [locale] [patch] Invalid (long)date format in pl_PL.IS o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 52 problems total. From kostikbel at gmail.com Mon Apr 20 15:47:01 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Apr 20 15:47:07 2009 Subject: bin/108390: [libc] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] In-Reply-To: <20090420112723.S1321@smx2.pair.com> References: <200904161242.n3GCgG4u063936@freefall.freebsd.org> <20090419195409.GY3014@deviant.kiev.zoral.com.ua> <20090420112723.S1321@smx2.pair.com> Message-ID: <20090420154654.GC3014@deviant.kiev.zoral.com.ua> On Mon, Apr 20, 2009 at 11:40:08AM -0400, Alan Ferrency wrote: > >Further check on Solaris revealed that for the case where SIGCHLD is > >ignored, wait4() returned -1/ECHLD, conforming to the FreeBSD behaviour > >of reparenting to init. > > If I'm interpreting Jilles' notes about this proposed patch, it seems > like this would solve our primary problem. > > That is: we already receive a -1/ECHLD when we call wait4pid() as > expected, but we don't receive it in a timely manner if there are > other child processes still running. If this patch causes wait4pid() > to return immediately when a nonexistent (exited) child PID is > specified, that would meet our expectations and preferences. Yes, this is what happens after the patch. I committed the change today. > > Regarding SA_NOCLDWAIT: it was previously my understanding that > SA_NOCLDWAIT and igoring SIGCHLD affect two different aspects of child > process management. On a previous occasion when I looked into the > behavior of SA_NOCLDWAIT, it wasn't even implemented on Linux yet; but > obviously, ignoring SIGCHLD was supported. > > Thanks for the patch, > Alan Ferrency > pair Networks, Inc. > > >Unless further comments are given, I will commit this in several days: > > > >diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c > >index 4255734..c35c6f2 100644 > >--- a/sys/kern/kern_exit.c > >+++ b/sys/kern/kern_exit.c > >@@ -504,13 +504,13 @@ exit1(struct thread *td, int rv) > > proc_reparent(p, initproc); > > p->p_sigparent = SIGCHLD; > > PROC_LOCK(p->p_pptr); > >+ > > /* > >- * If this was the last child of our parent, notify > >- * parent, so in case he was wait(2)ing, he will > >+ * Notify parent, so in case he was wait(2)ing or > >+ * executiing waitpid(2) with our pid, he will > > * continue. > > */ > >- if (LIST_EMPTY(&pp->p_children)) > >- wakeup(pp); > >+ wakeup(pp); > > } else > > mtx_unlock(&p->p_pptr->p_sigacts->ps_mtx); > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-standards/attachments/20090420/018b42fc/attachment.pgp From alan at pair.com Mon Apr 20 16:06:51 2009 From: alan at pair.com (Alan Ferrency) Date: Mon Apr 20 16:07:27 2009 Subject: bin/108390: [libc] [patch] wait4() erroneously waits for all children when SIGCHLD is SIG_IGN [regression] In-Reply-To: <20090419195409.GY3014@deviant.kiev.zoral.com.ua> References: <200904161242.n3GCgG4u063936@freefall.freebsd.org> <20090419195409.GY3014@deviant.kiev.zoral.com.ua> Message-ID: <20090420112723.S1321@smx2.pair.com> > Further check on Solaris revealed that for the case where SIGCHLD is > ignored, wait4() returned -1/ECHLD, conforming to the FreeBSD behaviour > of reparenting to init. If I'm interpreting Jilles' notes about this proposed patch, it seems like this would solve our primary problem. That is: we already receive a -1/ECHLD when we call wait4pid() as expected, but we don't receive it in a timely manner if there are other child processes still running. If this patch causes wait4pid() to return immediately when a nonexistent (exited) child PID is specified, that would meet our expectations and preferences. Regarding SA_NOCLDWAIT: it was previously my understanding that SA_NOCLDWAIT and igoring SIGCHLD affect two different aspects of child process management. On a previous occasion when I looked into the behavior of SA_NOCLDWAIT, it wasn't even implemented on Linux yet; but obviously, ignoring SIGCHLD was supported. Thanks for the patch, Alan Ferrency pair Networks, Inc. > Unless further comments are given, I will commit this in several days: > > diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c > index 4255734..c35c6f2 100644 > --- a/sys/kern/kern_exit.c > +++ b/sys/kern/kern_exit.c > @@ -504,13 +504,13 @@ exit1(struct thread *td, int rv) > proc_reparent(p, initproc); > p->p_sigparent = SIGCHLD; > PROC_LOCK(p->p_pptr); > + > /* > - * If this was the last child of our parent, notify > - * parent, so in case he was wait(2)ing, he will > + * Notify parent, so in case he was wait(2)ing or > + * executiing waitpid(2) with our pid, he will > * continue. > */ > - if (LIST_EMPTY(&pp->p_children)) > - wakeup(pp); > + wakeup(pp); > } else > mtx_unlock(&p->p_pptr->p_sigacts->ps_mtx); > > From jilles at stack.nl Thu Apr 23 23:00:15 2009 From: jilles at stack.nl (Jilles Tjoelker) Date: Thu Apr 23 23:00:22 2009 Subject: standards/116826: [patch] sh support for POSIX character classes Message-ID: <200904232300.n3NN02jb057957@freefall.freebsd.org> The following reply was made to PR standards/116826; it has been noted by GNATS. From: Jilles Tjoelker To: bug-followup@FreeBSD.org, uberlord@gentoo.org Cc: Subject: Re: standards/116826: [patch] sh support for POSIX character classes Date: Fri, 24 Apr 2009 00:52:12 +0200 The patch seems to work in brief testing. The code seems to be taken from dash, and an attribution/copyright notice seems missing. I put an improved patch (also including a bug fix from dash) on http://www.stack.nl/~jilles/unix/sh-match-charclass.patch Recent versions of dash can use fnmatch(3) (and also glob(3)) instead of the internal implementations; this is however not used by default (I suppose it was added to make it possible to build smaller binaries; dash is also obfuscated in some places to decrease binary size). It requires converting the CTLESC etc quoting to backslash quoting. This could be nice in that our fnmatch supports multibyte characters; however it does not support the [:alpha:] classes either. -- Jilles Tjoelker From bugmaster at FreeBSD.org Mon Apr 27 11:07:04 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 27 11:09:19 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200904271107.n3RB72Xx002442@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o stand/133369 standards [patch] test(1) with 3 or 4 arguments o stand/130067 standards Wrong numeric limits in system headers? o stand/129554 standards lp(1) [patch] Implement -m and -t options o stand/129524 standards FreeBSD 7.0 isnt detecting my hardrives with raid5 o stand/128546 standards ls -p does not follow symlinks o bin/125855 standards sh(1) allows for multiline, non-escaped control struct o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/119804 standards [patch] [locale] Invalid (long)date format in pl_PL.IS o stand/116826 standards [patch] sh support for POSIX character classes o stand/116477 standards rm(1): rm behaves unexpectedly when using -r and relat o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116081 standards make does not work with the directive sinclude p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/96236 standards [patch] [posix] sed(1) incorrectly describes a functio o stand/96016 standards [headers] clock_getres et al should be in o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers a stand/86484 standards [patch] mkfifo(1) uses wrong permissions o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm o stand/82654 standards C99 long double math functions are missing o stand/81287 standards [patch] fingerd(8) might send a line not ending in CRL a stand/80293 standards sysconf() does not support well-defined unistd values o stand/79056 standards [feature request] [atch] regex(3) regression tests o stand/70813 standards [patch] ls(1) not Posix compliant o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( s stand/62858 standards malloc(0) not C99 compliant o stand/56476 standards cd9660 unicode support simple hack p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/54839 standards [pcvt] pcvt deficits o stand/54833 standards [pcvt] more pcvt deficits o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/44425 standards getcwd() succeeds even if current dir has perm 000. p stand/41576 standards POSIX compliance of ln(1) o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings s stand/36076 standards Implementation of POSIX fuser command o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o stand/25777 standards [kernel] [patch] atime not updated on exec o bin/25542 standards sh(1) null char in quoted string s stand/24590 standards timezone function not compatible witn Single Unix Spec o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 52 problems total. From juli at clockworksquid.com Thu Apr 30 19:22:23 2009 From: juli at clockworksquid.com (Juli Mallett) Date: Thu Apr 30 19:22:55 2009 Subject: Shouldn't cat(1) use the C locale? Message-ID: Hey folks, The cat manpage suggests that the infamous, non-standard -v extension is ASCII-oriented but cat(1) these days uses isprint and pals and calls setlocale(LC_CTYPE, ""), which for those of us with dodgy environments (mine includes LC_ALL=en_US.UTF-8), means that "cat -v" behaves radically-differently to the manual page describes. Does anyone see any reason for our extensions, etc., to work with LC_CTYPE != C? It doesn't make a lot of sense to me. I'd like to change it if there's not a good reason to keep it broken this way, like: - setlocale(LC_CTYPE, ""); + setlocale(LC_CTYPE, "C"); Thoughts, etc.? Juli.