From owner-freebsd-standards@FreeBSD.ORG Mon Mar 4 01:53:07 2013 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B25C0E83 for ; Mon, 4 Mar 2013 01:53:07 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 237E12B1 for ; Mon, 4 Mar 2013 01:53:06 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id x10so4140047wey.17 for ; Sun, 03 Mar 2013 17:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=JbjX+QxFOO0Y+dSOeDhOvLya0p5fza11oXSmdgXWc2U=; b=mNnw9XXSpNlQrMJo/jv1zwubj8ia+IZ6mqlP6Dg2d+CRr7cLfNl1/QfA/Hl+fFavc5 w8jwg/+fWrBCOeXhnGQ4zsi6NlFW0nByUL2swW8VWzaGwUbFduAQKpbdaVH7KE122fGW Lp+2njokDXLD5rh2H3SYJzvknRZe/oc9SdNNU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=JbjX+QxFOO0Y+dSOeDhOvLya0p5fza11oXSmdgXWc2U=; b=ow7VfvYEQ2qIxk7NeqKhh2fN8mskGwEAr3CKLq/M4qGHxh6Emxi9dIXTj2mr8ZLFKs YMMnBCMjnFHOTyFEAbCVkCGJ4j0EiT1XeI5atUi6giDqdmeY06MxktMIVwXz/K7JIvOL 9vhoUUgAmuSjZyx5Gn9ehgjTIiFiR0QZaXK9GYd1kgsrtxAPzEOtOiBpRne8/X9UZus9 NfJu8Cku6TdAzmlZOTPUEgD608Ii86MBWwswv7Zzk9aL6s1x2SaLuAhIpOgAk5yRuEcf aBu8KxWcnO+/RD3gMQwX8EaHYgxjzbm0Cgb7MhU8wIVzisle3bJ6v4lSndrkwubA7G1n 6E1w== X-Received: by 10.180.98.98 with SMTP id eh2mr8578865wib.7.1362361986376; Sun, 03 Mar 2013 17:53:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.44.130 with HTTP; Sun, 3 Mar 2013 17:52:36 -0800 (PST) In-Reply-To: <20130304014401.603DB48E@hades.panopticon> References: <20130304014401.603DB48E@hades.panopticon> From: Eitan Adler Date: Sun, 3 Mar 2013 20:52:36 -0500 Message-ID: Subject: Fwd: misc/176628: [stdint.h] use safer way of definint __WORDSIZE To: FreeBSD Standards Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlGwJK/jP+i/z5ElA00XU2WMSHIwj8gRSuI5auS/I5K+3rsym4Y3AtgRUJXVz0RxZX4ICDY X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 01:53:07 -0000 FYI ---------- Forwarded message ---------- From: Dmitry Marakasov Date: 3 March 2013 20:44 Subject: misc/176628: [stdint.h] use safer way of definint __WORDSIZE To: FreeBSD-gnats-submit@freebsd.org >Number: 176628 >Category: misc >Synopsis: [stdint.h] use safer way of definint __WORDSIZE >Confidential: no >Severity: serious >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Mar 04 01:50:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Dmitry Marakasov >Release: FreeBSD 9.0-RELEASE-p3 amd64 >Organization: >Environment: System: FreeBSD hades.panopticon 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Wed Jun 13 17:39:20 MSK 2012 root@hades.panopticon:/usr/obj/usr/src/sys/HADES amd64 >Description: r228529 introduced __WORDSIZE macro: --- sys/sys/stdint.h +#if defined(UINTPTR_MAX) && defined(UINT64_MAX) && (UINTPTR_MAX == UINT64_MAX) +#define __WORDSIZE 64 +#else +#define __WORDSIZE 32 +#endif --- However the way it's defined is utterly unsafe: when UINTPTR_MAX or UINT64_MAX are not defined (which is the case for C++, as their definitions in e.g. x86/_stint.h are wrapped in #if !defined(__cplusplus) || defined(__STDC_LIMIT_MACROS) __WORDSIZE is always defined as 32, which is wrong on 64bit systems. I have two solutions for the problem. First one uses the same way of testing for 64bit pointers, but doesn't define __WORDSIZE if it can't be detected reliably. Second one uses different way of testing for 64bit pointers with checking for __LP64__. The second one looks much more useful, but I'm not sure if __LP64__ has the right semantics and will work in all platforms. Also, can't it just be unconditionally defined to (sizeof(int*)*8)? >How-To-Repeat: >Fix: --- wordsize.patch begins here --- diff --git sys/sys/stdint.h sys/sys/stdint.h index 762e879..de10869 100644 --- sys/sys/stdint.h +++ sys/sys/stdint.h @@ -65,10 +65,12 @@ typedef __uintmax_t uintmax_t; #endif /* GNU and Darwin define this and people seem to think it's portable */ -#if defined(UINTPTR_MAX) && defined(UINT64_MAX) && (UINTPTR_MAX == UINT64_MAX) -#define __WORDSIZE 64 -#else -#define __WORDSIZE 32 +#if defined(UINTPTR_MAX) && defined(UINT64_MAX) +# if UINTPTR_MAX == UINT64_MAX +# define __WORDSIZE 64 +# else +# define __WORDSIZE 32 +# endif #endif /* Limits of wchar_t. */ --- wordsize.patch ends here --- --- wordsize.1.patch begins here --- diff --git sys/sys/stdint.h sys/sys/stdint.h index 762e879..b921b99 100644 --- sys/sys/stdint.h +++ sys/sys/stdint.h @@ -65,7 +65,7 @@ typedef __uintmax_t uintmax_t; #endif /* GNU and Darwin define this and people seem to think it's portable */ -#if defined(UINTPTR_MAX) && defined(UINT64_MAX) && (UINTPTR_MAX == UINT64_MAX) +#if defined(__LP64__) #define __WORDSIZE 64 #else #define __WORDSIZE 32 --- wordsize.1.patch ends here --- >Release-Note: >Audit-Trail: >Unformatted: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org" -- Eitan Adler From owner-freebsd-standards@FreeBSD.ORG Mon Mar 4 11:06:50 2013 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2623FF31 for ; Mon, 4 Mar 2013 11:06:50 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 182A7E66 for ; Mon, 4 Mar 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r24B6nsx038914 for ; Mon, 4 Mar 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r24B6nXc038912 for freebsd-standards@FreeBSD.org; Mon, 4 Mar 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Mar 2013 11:06:49 GMT Message-Id: <201303041106.r24B6nXc038912@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-standards@FreeBSD.org Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 11:06:50 -0000 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/176412 standards newfs writes by default, compare to bsdlabel/disklabel o stand/175711 standards When the server has more than 3 days, rising interrupt o stand/175453 standards Catching C++ std::bad_cast doesn't work in FreeBSD 9.1 o stand/174938 standards Problem statement: iSCSI target failure o stand/173421 standards [libc] [patch] strptime() accepts formats that should o stand/173087 standards pax(1) does not support the pax interchange format o stand/172805 standards Fix catopen(3)'s EINVAL usage and document EFTYPE o stand/172276 standards POSIX: {get,set}groups gidsetsize is u_int not int o stand/172215 standards localeconv() grouping appears not to match POSIX o stand/170403 standards wrong ntohs expression type tickling clang o stand/169697 standards syslogd(8) is not BOM aware o stand/166349 standards Support the assignment-allocation character for fscanf o stand/164787 standards dirfd() function not available when _POSIX_C_SOURCE is o kern/164674 standards [patch] [libc] vfprintf/vfwprintf return error (EOF) o o stand/162434 standards getaddrinfo: addrinfo.ai_family is an address family, o stand/150093 standards C++ std::locale support is broken o stand/130067 standards Wrong numeric limits in system headers? o stand/124860 standards flockfile(3) doesn't work when the memory has been exh o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) 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/100017 standards [Patch] Add fuser(1) functionality to fstat(1) a stand/86484 standards [patch] mkfifo(1) uses wrong permissions 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( o stand/56476 standards [patch] cd9660 unicode support simple hack 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/44365 standards [headers] [patch] [request] introduce ulong and unchar a stand/41576 standards ln(1): replacing old dir-symlinks a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h s stand/24590 standards timezone function not compatible witn Single Unix Spec o stand/21519 standards sys/dir.h should be deprecated some more s bin/14925 standards getsubopt isn't poisonous enough 41 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Mar 4 14:50:01 2013 Return-Path: Delivered-To: freebsd-standards@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8225CEEC for ; Mon, 4 Mar 2013 14:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 553E61E4B for ; Mon, 4 Mar 2013 14:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r24Eo1Dc081902 for ; Mon, 4 Mar 2013 14:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r24Eo1fC081901; Mon, 4 Mar 2013 14:50:01 GMT (envelope-from gnats) Date: Mon, 4 Mar 2013 14:50:01 GMT Message-Id: <201303041450.r24Eo1fC081901@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org Cc: From: Giorgos Keramidas Subject: Re: standards/176412: newfs writes by default, compare to bsdlabel/disklabel. X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Giorgos Keramidas List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 14:50:01 -0000 The following reply was made to PR standards/176412; it has been noted by GNATS. From: Giorgos Keramidas To: root@ai1.alaska.net Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: standards/176412: newfs writes by default, compare to bsdlabel/disklabel. Date: Mon, 4 Mar 2013 15:47:34 +0100 On 2013-02-24 15:31, root@ai1.alaska.net wrote: > >Number: 176412 > >Category: standards > >Synopsis: newfs writes by default, compare to bsdlabel/disklabel. > > fdisk/bsdlabel will not write to a drive by default, and require > special options to do so, yet newfs will destroy an entire drive, > easily and accidently, unlike other dangerous utilities. This can > cause severe problems when a user only wants newfs to read and report > superblocks, and in utilizing the command, may easily forget the -N > option, whereafter, the user loses his entire drive and all data. It > is also easy to be careless with newfs when previously, fdisk/bsdlabel > are used without worry of accidental destructive writes to a drive. > > Play with newfs to read superblocks on a drive, and while > experimenting with options, forget the -N option one time, and your > drive and data are lost forever. > > It would be consistent with dangerous utilities like fdisk/bsdlabel > for newfs to read by default, and only write when a user clearly > demands such functionality. There is no good reason for newfs to > operate otherwise. It's an accident waiting to happen, almost as if > deliberately. newfs is not the only utility that can 'write by default' on a raw disk, possibly overwriting important data. dd(1), cat(1) and pretty much any other tool that can be pointed at a disk can do the same. For instance it's always possible to write the wrong disk number in commands like: dd bs=4m if=imagefile.bin of=/dev/ada1 ssh remotehost 'cat imagefile.bin' | tee /dev/ada0 The -N option is fine in newfs as an equivalent of --dry-run in other tools, but I don't think it makes sense to break compatibility with almost 40 years of history just because it can be unsafe if misused. From owner-freebsd-standards@FreeBSD.ORG Wed Mar 6 12:00:01 2013 Return-Path: Delivered-To: freebsd-standards@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24C4A74B for ; Wed, 6 Mar 2013 12:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 08490627 for ; Wed, 6 Mar 2013 12:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r26C00S2069870 for ; Wed, 6 Mar 2013 12:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r26C00Ej069869; Wed, 6 Mar 2013 12:00:00 GMT (envelope-from gnats) Resent-Date: Wed, 6 Mar 2013 12:00:00 GMT Resent-Message-Id: <201303061200.r26C00Ej069869@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-standards@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Torsten Eichstädt Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DCE4F72C for ; Wed, 6 Mar 2013 11:58:19 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 9D87A615 for ; Wed, 6 Mar 2013 11:58:19 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.5/8.14.5) with ESMTP id r26BwJvu058634 for ; Wed, 6 Mar 2013 11:58:19 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.5/8.14.5/Submit) id r26BwJbo058633; Wed, 6 Mar 2013 11:58:19 GMT (envelope-from nobody) Message-Id: <201303061158.r26BwJbo058633@red.freebsd.org> Date: Wed, 6 Mar 2013 11:58:19 GMT From: Torsten Eichstädt To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: standards/176683: catman pages shall be stored in /var (/usr/local/var, /var/local) X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:00:01 -0000 >Number: 176683 >Category: standards >Synopsis: catman pages shall be stored in /var (/usr/local/var,/var/local) >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: change-request >Submitter-Id: current-users >Arrival-Date: Wed Mar 06 12:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Torsten Eichstädt >Release: 9.1-RELEASE (PCBSD-9.1-RELEASE) >Organization: >Environment: FreeBSD paul-lifebook 9.1-RELEASE FreeBSD 9.1-RELEASE #0: Tue Jan 29 15:02:50 EST 2013 root@avenger:/usr/obj/pcbsd-build64/fbsd-source/src-patched/sys/GENERIC amd64 >Description: I'd like to request to change the default location of preformatted catman pages to an own subdirectory (supposed /var/catman and /var/local/catman) and not beside the unformatted manpages under /usr/share/man (usr/local/man). Rationale: The catman pages are variable content, in contrast to the unformatted man pages. The current default location complicates the configuration of automatic indexers, e.g. desktop search engines, because the user has to specify many subdirectories under the standard locations (only the man* folders). Specifying only /usr/share/man and /usr/local/man would index duplicate content. Furthermore, when a new application is installed, it can create a new man* subdirectory, which does not get indexed until the indexer's configuration is adjusted. Separating the catman page's location would easily solve this limitation. Sincerely, Torsten Eichstädt >How-To-Repeat: >Fix: I'm wondering if preformatted (catman) manpages are still beeing used at all. All the catman* folders on my system are empty... So maybe this is not really a problem? At least I can mount the root filesystem read-only, a simple method to enhance system security. Then the 'man' utility is fully functional. >Release-Note: >Audit-Trail: >Unformatted: