From dougb at FreeBSD.org Thu Jan 1 09:28:49 2009 From: dougb at FreeBSD.org (dougb@FreeBSD.org) Date: Thu Jan 1 09:29:00 2009 Subject: conf/118047: Move /etc/printcap to /usr/share/examples/ Message-ID: <200901010928.n019SngD051783@freefall.freebsd.org> Old Synopsis: SUGGESTION: /etc/printcap vs mergemaster New Synopsis: Move /etc/printcap to /usr/share/examples/ Class-Changed-From-To: sw-bug->change-request Class-Changed-By: dougb Class-Changed-When: Thu Jan 1 09:24:27 UTC 2009 Class-Changed-Why: This isn't really a standards issue, so throw it back into the pool. FWIW, I don't have this problem since I have a mergemaster pre-compare script that deletes /etc/printcap from the temproot. This will be even easier going forward with the new IGNORE_FILES option so I'm not convinced that this move is necessary. Responsible-Changed-From-To: freebsd-standards->freebsd-bugs Responsible-Changed-By: dougb Responsible-Changed-When: Thu Jan 1 09:24:27 UTC 2009 Responsible-Changed-Why: Throw it back into the pool. http://www.freebsd.org/cgi/query-pr.cgi?pr=118047 From bugmaster at FreeBSD.org Mon Jan 5 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 5 11:09:22 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200901051106.n05B6xBO002937@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/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 [timedef] [patch] Invalid (long)date format in pl_PL.I 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 o kern/114578 standards [libc] wide character printing using swprintf(dst, n, 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/72006 standards floating point formating in non-C locales 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 53 problems total. From das at FreeBSD.ORG Tue Jan 6 19:00:15 2009 From: das at FreeBSD.ORG (David Schultz) Date: Tue Jan 6 19:00:41 2009 Subject: standards/130067: Wrong numeric limits in system headers? Message-ID: <200901061900.n06J0Fcl073538@freefall.freebsd.org> The following reply was made to PR standards/130067; it has been noted by GNATS. From: David Schultz To: Bruce Evans Cc: Vaclav Haisman , imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Tue, 6 Jan 2009 14:03:13 -0500 On FreeBSD/i386, long doubles are represented with 64 bits of precision, but computations are performed with 53 bits of precision. In a sane world, this discrepancy wouldn't exist, but for reasons I won't get into, they do, and probably always will. C99 defines the LDBL constants based on what can be represented, not what can be computed as the result of arithmetic operations, so my interpretation is that the values in float.h are correct, though confusing. From das at FreeBSD.ORG Tue Jan 6 19:23:03 2009 From: das at FreeBSD.ORG (David Schultz) Date: Tue Jan 6 19:23:10 2009 Subject: standards/130067: Wrong numeric limits in system headers? In-Reply-To: <20081231215445.S3923@delplex.bde.org> References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> Message-ID: <20090106190313.GA15233@zim.MIT.EDU> On FreeBSD/i386, long doubles are represented with 64 bits of precision, but computations are performed with 53 bits of precision. In a sane world, this discrepancy wouldn't exist, but for reasons I won't get into, they do, and probably always will. C99 defines the LDBL constants based on what can be represented, not what can be computed as the result of arithmetic operations, so my interpretation is that the values in float.h are correct, though confusing. From v.haisman at sh.cvut.cz Thu Jan 8 21:57:12 2009 From: v.haisman at sh.cvut.cz (=?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?=) Date: Thu Jan 8 21:57:19 2009 Subject: standards/130067: Wrong numeric limits in system headers? In-Reply-To: <20090106190313.GA15233@zim.MIT.EDU> References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> <20090106190313.GA15233@zim.MIT.EDU> Message-ID: <496676AB.9040905@sh.cvut.cz> David Schultz wrote, On 6.1.2009 20:03: > On FreeBSD/i386, long doubles are represented with 64 bits of > precision, but computations are performed with 53 bits of > precision. In a sane world, this discrepancy wouldn't exist, but > for reasons I won't get into, they do, and probably always will. > > C99 defines the LDBL constants based on what can be represented, > not what can be computed as the result of arithmetic operations, > so my interpretation is that the values in float.h are correct, > though confusing. I am not language lawyer but even if it were true that the constants are right, there is still the problem that they (especially the LDBL_MAX value) are useless with the provided GCC. Either GCC or the headers should be changed. Otherwise the constants are rather useless and unusable. -- VH From v.haisman at sh.cvut.cz Thu Jan 8 22:00:11 2009 From: v.haisman at sh.cvut.cz (=?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?=) Date: Thu Jan 8 22:00:17 2009 Subject: standards/130067: Wrong numeric limits in system headers? Message-ID: <200901082200.n08M0Ams090350@freefall.freebsd.org> The following reply was made to PR standards/130067; it has been noted by GNATS. From: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= To: Bruce Evans , Vaclav Haisman , imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Cc: Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Thu, 08 Jan 2009 22:56:59 +0100 David Schultz wrote, On 6.1.2009 20:03: > On FreeBSD/i386, long doubles are represented with 64 bits of > precision, but computations are performed with 53 bits of > precision. In a sane world, this discrepancy wouldn't exist, but > for reasons I won't get into, they do, and probably always will. > > C99 defines the LDBL constants based on what can be represented, > not what can be computed as the result of arithmetic operations, > so my interpretation is that the values in float.h are correct, > though confusing. I am not language lawyer but even if it were true that the constants are right, there is still the problem that they (especially the LDBL_MAX value) are useless with the provided GCC. Either GCC or the headers should be changed. Otherwise the constants are rather useless and unusable. -- VH From jhein at timing.com Fri Jan 9 16:00:10 2009 From: jhein at timing.com (John Hein) Date: Fri Jan 9 16:00:19 2009 Subject: standards/130067: Wrong numeric limits in system headers? Message-ID: <200901091600.n09G091i028176@freefall.freebsd.org> The following reply was made to PR standards/130067; it has been noted by GNATS. From: John Hein To: =?UTF-8?B?VsOhY2xhdiBIYWlzbWFu?= Cc: Bruce Evans , das@FreeBSD.ORG, imp@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Fri, 9 Jan 2009 08:57:26 -0700 V=E1clav Haisman wrote at 22:56 +0100 on Jan 8, 2009: > David Schultz wrote, On 6.1.2009 20:03: > > On FreeBSD/i386, long doubles are represented with 64 bits of > > precision, but computations are performed with 53 bits of > > precision. In a sane world, this discrepancy wouldn't exist, but > > for reasons I won't get into, they do, and probably always will. > > = > > C99 defines the LDBL constants based on what can be represented, > > not what can be computed as the result of arithmetic operations, > > so my interpretation is that the values in float.h are correct, > > though confusing. > I am not language lawyer but even if it were true that the constants a= re > right, there is still the problem that they (especially the LDBL_MAX v= alue) > are useless with the provided GCC. Either GCC or the headers should be= > changed. Otherwise the constants are rather useless and unusable. FWIW, when you compile the OP's sample code on i386 with -pedantic (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: x.cc:11: error: floating constant exceeds range of 'long double' (the LDBL_MAX line) That seems to tip the scale more to the 'float.h is wrong' side. From jhein at timing.com Fri Jan 9 17:07:47 2009 From: jhein at timing.com (John Hein) Date: Fri Jan 9 17:07:53 2009 Subject: standards/130067: Wrong numeric limits in system headers? In-Reply-To: <496676AB.9040905@sh.cvut.cz> References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> <20090106190313.GA15233@zim.MIT.EDU> <496676AB.9040905@sh.cvut.cz> Message-ID: <18791.29670.321788.799095@gromit.timing.com> V?clav Haisman wrote at 22:56 +0100 on Jan 8, 2009: > David Schultz wrote, On 6.1.2009 20:03: > > On FreeBSD/i386, long doubles are represented with 64 bits of > > precision, but computations are performed with 53 bits of > > precision. In a sane world, this discrepancy wouldn't exist, but > > for reasons I won't get into, they do, and probably always will. > > > > C99 defines the LDBL constants based on what can be represented, > > not what can be computed as the result of arithmetic operations, > > so my interpretation is that the values in float.h are correct, > > though confusing. > I am not language lawyer but even if it were true that the constants are > right, there is still the problem that they (especially the LDBL_MAX value) > are useless with the provided GCC. Either GCC or the headers should be > changed. Otherwise the constants are rather useless and unusable. FWIW, when you compile the OP's sample code on i386 with -pedantic (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: x.cc:11: error: floating constant exceeds range of 'long double' (the LDBL_MAX line) That seems to tip the scale more to the 'float.h is wrong' side. From das at FreeBSD.ORG Fri Jan 9 18:41:17 2009 From: das at FreeBSD.ORG (David Schultz) Date: Fri Jan 9 18:41:24 2009 Subject: standards/130067: Wrong numeric limits in system headers? In-Reply-To: <18791.29670.321788.799095@gromit.timing.com> References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> <20090106190313.GA15233@zim.MIT.EDU> <496676AB.9040905@sh.cvut.cz> <18791.29670.321788.799095@gromit.timing.com> Message-ID: <20090109184136.GA61165@zim.MIT.EDU> On Fri, Jan 09, 2009, John Hein wrote: > FWIW, when you compile the OP's sample code on i386 with -pedantic > (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: > > x.cc:11: error: floating constant exceeds range of 'long double' > > (the LDBL_MAX line) > > That seems to tip the scale more to the 'float.h is wrong' side. gcc doesn't do quite the right thing with long double constants in FreeBSD, and it causes no end of trouble when writing long double routines that are intended to work when the FPU is switched to extended precision mode. Older versions of gcc would evaluate long double constant expressions at compile time using extended precision, which was wrong because it didn't reflect what the FPU would have done at runtime. More recent versions of gcc were "fixed" to evaluate all long double constants using double precision, which matches what the FPU does by default. However, now it's not even possible to write a program that uses long double constants, even if the program changes the FPU precision at runtime, because gcc truncates all the constants at compile time (and generates spurious complaints such as the one you mention). C99 defines some pragmas that would improve the situation, but gcc doesn't implement them. From das at FreeBSD.ORG Fri Jan 9 18:50:04 2009 From: das at FreeBSD.ORG (David Schultz) Date: Fri Jan 9 18:50:10 2009 Subject: standards/130067: Wrong numeric limits in system headers? Message-ID: <200901091850.n09Io349056249@freefall.freebsd.org> The following reply was made to PR standards/130067; it has been noted by GNATS. From: David Schultz To: John Hein Cc: =?iso-8859-1?Q?V=E1clav?= Haisman , freebsd-standards@FreeBSD.ORG, freebsd-gnats-submit@FreeBSD.ORG, imp@FreeBSD.ORG Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Fri, 9 Jan 2009 13:41:36 -0500 On Fri, Jan 09, 2009, John Hein wrote: > FWIW, when you compile the OP's sample code on i386 with -pedantic > (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: > > x.cc:11: error: floating constant exceeds range of 'long double' > > (the LDBL_MAX line) > > That seems to tip the scale more to the 'float.h is wrong' side. gcc doesn't do quite the right thing with long double constants in FreeBSD, and it causes no end of trouble when writing long double routines that are intended to work when the FPU is switched to extended precision mode. Older versions of gcc would evaluate long double constant expressions at compile time using extended precision, which was wrong because it didn't reflect what the FPU would have done at runtime. More recent versions of gcc were "fixed" to evaluate all long double constants using double precision, which matches what the FPU does by default. However, now it's not even possible to write a program that uses long double constants, even if the program changes the FPU precision at runtime, because gcc truncates all the constants at compile time (and generates spurious complaints such as the one you mention). C99 defines some pragmas that would improve the situation, but gcc doesn't implement them. From brde at optusnet.com.au Sat Jan 10 11:36:14 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sat Jan 10 11:36:20 2009 Subject: standards/130067: Wrong numeric limits in system headers? In-Reply-To: <20090109184136.GA61165@zim.MIT.EDU> References: <200812302231.mBUMVUtf092910@www.freebsd.org> <20081231215445.S3923@delplex.bde.org> <20090106190313.GA15233@zim.MIT.EDU> <496676AB.9040905@sh.cvut.cz> <18791.29670.321788.799095@gromit.timing.com> <20090109184136.GA61165@zim.MIT.EDU> Message-ID: <20090110215409.P28834@delplex.bde.org> On Fri, 9 Jan 2009, David Schultz wrote: > On Fri, Jan 09, 2009, John Hein wrote: >> FWIW, when you compile the OP's sample code on i386 with -pedantic >> (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: >> >> x.cc:11: error: floating constant exceeds range of 'long double' >> >> (the LDBL_MAX line) >> >> That seems to tip the scale more to the 'float.h is wrong' side. No, it is strictly a bug in gcc (gcc is supposed to support FreeBSD's idea of a long double, since the special support is only used by FreeBSD, but it doesn't). The FreeBSD value of LDBL_MAX doesn't exceed the range of a long double with FreeBSD's idea of a long double. However, almost any operation on FreeBSD's LDBL_MAX would overflow. E.g., (LDBL_MAX + 0) and (LDBL_MAX * 1) both overflow to give a result of Inf. There may be optimization bugs related to this -- IIRC, evaluating x+0 as x at compile time is an invalid optimization, because x+0 should differ from x iff x is -0, but evaluating x*1 as x at compile time is a valid optimization because there should be no special cases; however LDBL_MAX*1 gives a special case. > gcc doesn't do quite the right thing with long double constants in > FreeBSD, and it causes no end of trouble when writing long double > routines that are intended to work when the FPU is switched to > extended precision mode. I think it does do the right thing from its viewpoint. In its viewpoint, long doubles have only 53 bits of precision. Since it refuses to construct long doubles with the full 64 bits of precision that are possible and expected by FreeBSD, this is a valid viewpoint -- there is no way to construct a long double with more than 53 bits of precision in C without invoking undefined behaviour, so the extra bits might as well not be there. This viewpoint also avoids surprises like LDBL_MAX*1 = Inf. > Older versions of gcc would evaluate long double constant > expressions at compile time using extended precision, which was > wrong because it didn't reflect what the FPU would have done at > runtime. More recent versions of gcc were "fixed" to evaluate all > long double constants using double precision, which matches what > the FPU does by default. However, now it's not even possible to > write a program that uses long double constants, even if the > program changes the FPU precision at runtime, because gcc > truncates all the constants at compile time (and generates > spurious complaints such as the one you mention). C99 defines some > pragmas that would improve the situation, but gcc doesn't > implement them. This is true. Bruce From brde at optusnet.com.au Sat Jan 10 11:40:03 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Sat Jan 10 11:40:09 2009 Subject: standards/130067: Wrong numeric limits in system headers? Message-ID: <200901101140.n0ABe2oD058113@freefall.freebsd.org> The following reply was made to PR standards/130067; it has been noted by GNATS. From: Bruce Evans To: David Schultz Cc: John Hein , imp@freebsd.org, =?iso-8859-1?Q?V=E1clav?= Haisman , freebsd-standards@freebsd.org, freebsd-gnats-submit@freebsd.org Subject: Re: standards/130067: Wrong numeric limits in system headers? Date: Sat, 10 Jan 2009 22:35:59 +1100 (EST) On Fri, 9 Jan 2009, David Schultz wrote: > On Fri, Jan 09, 2009, John Hein wrote: >> FWIW, when you compile the OP's sample code on i386 with -pedantic >> (with 6.x's base gcc 3.4.6 or 7.x's base gcc 4.2.1), you get: >> >> x.cc:11: error: floating constant exceeds range of 'long double' >> >> (the LDBL_MAX line) >> >> That seems to tip the scale more to the 'float.h is wrong' side. No, it is strictly a bug in gcc (gcc is supposed to support FreeBSD's idea of a long double, since the special support is only used by FreeBSD, but it doesn't). The FreeBSD value of LDBL_MAX doesn't exceed the range of a long double with FreeBSD's idea of a long double. However, almost any operation on FreeBSD's LDBL_MAX would overflow. E.g., (LDBL_MAX + 0) and (LDBL_MAX * 1) both overflow to give a result of Inf. There may be optimization bugs related to this -- IIRC, evaluating x+0 as x at compile time is an invalid optimization, because x+0 should differ from x iff x is -0, but evaluating x*1 as x at compile time is a valid optimization because there should be no special cases; however LDBL_MAX*1 gives a special case. > gcc doesn't do quite the right thing with long double constants in > FreeBSD, and it causes no end of trouble when writing long double > routines that are intended to work when the FPU is switched to > extended precision mode. I think it does do the right thing from its viewpoint. In its viewpoint, long doubles have only 53 bits of precision. Since it refuses to construct long doubles with the full 64 bits of precision that are possible and expected by FreeBSD, this is a valid viewpoint -- there is no way to construct a long double with more than 53 bits of precision in C without invoking undefined behaviour, so the extra bits might as well not be there. This viewpoint also avoids surprises like LDBL_MAX*1 = Inf. > Older versions of gcc would evaluate long double constant > expressions at compile time using extended precision, which was > wrong because it didn't reflect what the FPU would have done at > runtime. More recent versions of gcc were "fixed" to evaluate all > long double constants using double precision, which matches what > the FPU does by default. However, now it's not even possible to > write a program that uses long double constants, even if the > program changes the FPU precision at runtime, because gcc > truncates all the constants at compile time (and generates > spurious complaints such as the one you mention). C99 defines some > pragmas that would improve the situation, but gcc doesn't > implement them. This is true. Bruce From bugmaster at FreeBSD.org Mon Jan 12 03:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 12 03:09:20 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200901121106.n0CB6xAB092140@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/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 [timedef] [patch] Invalid (long)date format in pl_PL.I 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 o kern/114578 standards [libc] wide character printing using swprintf(dst, n, 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/72006 standards floating point formating in non-C locales 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 53 problems total. From bugmaster at FreeBSD.org Mon Jan 19 03:07:06 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 19 03:09:11 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200901191107.n0JB75XJ063115@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/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 o kern/114578 standards [libc] wide character printing using swprintf(dst, n, 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/72006 standards floating point formating in non-C locales 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 53 problems total. From bugmaster at FreeBSD.org Mon Jan 26 03:07:07 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jan 26 03:09:10 2009 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200901261107.n0QB73Lr024408@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/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 o kern/114578 standards [libc] wide character printing using swprintf(dst, n, 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/72006 standards floating point formating in non-C locales 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 53 problems total. From linimon at FreeBSD.org Wed Jan 28 04:05:05 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Wed Jan 28 04:05:12 2009 Subject: standards/131071: Re: standards/127795: commit references a PR Message-ID: <200901281204.n0SC4fHh022670@freefall.freebsd.org> Old Synopsis: Re: standard/127795: commit references a PR New Synopsis: Re: standards/127795: commit references a PR State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Wed Jan 28 12:04:09 UTC 2009 State-Changed-Why: Misfiled followup to standards/127795; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-standards Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 28 12:04:09 UTC 2009 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=131071