From owner-freebsd-standards@FreeBSD.ORG Mon Feb 13 11:08:12 2012 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A483B106566C for ; Mon, 13 Feb 2012 11:08:12 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 77B238FC17 for ; Mon, 13 Feb 2012 11:08:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1DB8CeL091036 for ; Mon, 13 Feb 2012 11:08:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1DB8BFt091034 for freebsd-standards@FreeBSD.org; Mon, 13 Feb 2012 11:08:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Feb 2012 11:08:11 GMT Message-Id: <201202131108.q1DB8BFt091034@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 Cc: Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 11:08:12 -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/164787 standards dirfd() function not available when _POSIX_C_SOURCE is o stand/162434 standards getaddrinfo: addrinfo.ai_family is an address family, o stand/154842 standards invalid request authenticator in the second and subseq o stand/150093 standards C++ std::locale support is broken o docs/143472 standards gethostname(3) references undefined value: HOST_NAME_M s stand/141705 standards [libc] [request] libc lacks cexp (and friends) 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 o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings 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 32 problems total. From owner-freebsd-standards@FreeBSD.ORG Tue Feb 14 22:10:06 2012 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7E0F106568A for ; Tue, 14 Feb 2012 22:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF8998FC13 for ; Tue, 14 Feb 2012 22:10:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1EMA57A089399 for ; Tue, 14 Feb 2012 22:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1EMA57P089398; Tue, 14 Feb 2012 22:10:05 GMT (envelope-from gnats) Resent-Date: Tue, 14 Feb 2012 22:10:05 GMT Resent-Message-Id: <201202142210.q1EMA57P089398@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, Matthew Story Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17C3D106564A for ; Tue, 14 Feb 2012 22:00:48 +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 DFBFE8FC13 for ; Tue, 14 Feb 2012 22:00:47 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q1EM0lf1074852 for ; Tue, 14 Feb 2012 22:00:47 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q1EM0lDM074851; Tue, 14 Feb 2012 22:00:47 GMT (envelope-from nobody) Message-Id: <201202142200.q1EM0lDM074851@red.freebsd.org> Date: Tue, 14 Feb 2012 22:00:47 GMT From: Matthew Story To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: standards/165155: [PATCH][bin][standards] xargs does not print diagnostic information on utility termination via signal, or utility exit 255 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 22:10:06 -0000 >Number: 165155 >Category: standards >Synopsis: [PATCH][bin][standards] xargs does not print diagnostic information on utility termination via signal, or utility exit 255 >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: Tue Feb 14 22:10:05 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Matthew Story >Release: 9.0 >Organization: >Environment: FreeBSD matt9fromouterspace 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: Per POSIX (IEEE Std 1003.1-2008): If a command line meeting the specified requirements cannot be assembled, the utility cannot be invoked, an invocation of the utility is terminated by a signal, or an invocation of the utility exits with exit status 255, the xargs utility shall write a diagnostic message and exit without processing any remaining input. (via: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/xargs.html) FreeBSD xargs does exit without processing any remaining input if an invocation of utility terminates as a result of a signal, or if an invocation of utility exits with exit status 255, but it does not write a diagnostic message as required by the spec. >How-To-Repeat: $ jot - 1 10 | xargs -n1 sh -c 'kill $$' $ # note no output $ jot - 1 10 | xargs -n1 sh -c 'exit 255;' $ # note no output >Fix: apply patch, result is: $ jot - 1 10 | xargs -n1 sh -c 'kill $$' xargs: sh: terminated with signal 15, aborting $ jot - 1 10 | xargs -n1 sh -c 'exit 255' xargs: sh: exited with status 255, aborting Patch attached with submission follows: diff -u a/usr.bin/xargs/xargs.c b/usr.bin/xargs/xargs.c --- a/usr.bin/xargs/xargs.c 2012-01-02 22:23:44.000000000 -0500 +++ b/usr.bin/xargs/xargs.c 2012-02-14 16:39:20.000000000 -0500 @@ -608,8 +608,11 @@ * If utility signaled or exited with a value of 255, * exit 1-125. */ - if (WIFSIGNALED(status) || WEXITSTATUS(status) == 255) - exit(1); + if (WIFSIGNALED(status)) + errx(1, "%s: terminated with signal %d, aborting", + name, WTERMSIG(status)); + if (WEXITSTATUS(status) == 255) + errx(1, "%s: exited with status 255, aborting", name); if (WEXITSTATUS(status)) rval = 1; } >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-standards@FreeBSD.ORG Wed Feb 15 05:50:10 2012 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B586106566B for ; Wed, 15 Feb 2012 05:50:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 052408FC17 for ; Wed, 15 Feb 2012 05:50:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1F5o937026706 for ; Wed, 15 Feb 2012 05:50:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1F5o9UU026705; Wed, 15 Feb 2012 05:50:09 GMT (envelope-from gnats) Date: Wed, 15 Feb 2012 05:50:09 GMT Message-Id: <201202150550.q1F5o9UU026705@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Matthew Story Cc: Subject: Re: standards/165155: [PATCH][bin][standards] xargs does not print diagnostic information on utility termination via signal, or utility exit 255 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Matthew Story List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 05:50:10 -0000 The following reply was made to PR standards/165155; it has been noted by GNATS. From: Matthew Story To: freebsd-gnats-submit@freebsd.org Cc: Subject: Re: standards/165155: [PATCH][bin][standards] xargs does not print diagnostic information on utility termination via signal, or utility exit 255 Date: Wed, 15 Feb 2012 00:42:39 -0500 --bcaec5014bf3f3f9da04b8fa2daa Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 14, 2012 at 5:00 PM, Matthew Story wrote: > > >Number: 165155 > [...snip] > Patch attached with submission follows: > > diff -u a/usr.bin/xargs/xargs.c b/usr.bin/xargs/xargs.c > --- a/usr.bin/xargs/xargs.c 2012-01-02 22:23:44.000000000 -0500 > +++ b/usr.bin/xargs/xargs.c 2012-02-14 16:39:20.000000000 -0500 > @@ -608,8 +608,11 @@ > * If utility signaled or exited with a value of 255, > * exit 1-125. > */ > - if (WIFSIGNALED(status) || WEXITSTATUS(status) == 255) > - exit(1); > + if (WIFSIGNALED(status)) > + errx(1, "%s: terminated with signal %d, aborting", > + name, WTERMSIG(status)); > + if (WEXITSTATUS(status) == 255) > + errx(1, "%s: exited with status 255, aborting", > name); > if (WEXITSTATUS(status)) > rval = 1; > } > This fix exposes an existing, but hard to reproduce bug ( see: PR 165164: http://www.freebsd.org/cgi/query-pr.cgi?pr=165164 ). The patch from PR 165164 should be applied prior to, on along side this patch, else you will see a lot more: xargs: (null): error diagnostic messages. > > > >Release-Note: > >Audit-Trail: > >Unformatted: > _______________________________________________ > freebsd-standards@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-standards > To unsubscribe, send any mail to " > freebsd-standards-unsubscribe@freebsd.org" > -- regards, matt --bcaec5014bf3f3f9da04b8fa2daa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Feb 14, 2012 at 5:00 PM, Matthew Story <matthewstory@gmail.com> w= rote:

>Number: =A0 =A0 =A0 =A0 165155
[...snip]
Patch attached with submission follows:

diff -u a/usr.bin/xargs/xargs.c b/usr.bin/xargs/xargs.c
--- a/usr.bin/xargs/xargs.c =A0 =A0 2012-01-02 22:23:44.000000000 -0500
+++ b/usr.bin/xargs/xargs.c =A0 =A0 2012-02-14 16:39:20.000000000 -0500
@@ -608,8 +608,11 @@
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * If utility signaled or exited with a val= ue of 255,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * exit 1-125.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 */
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (WIFSIGNALED(status) || WEXITSTATUS(status= ) =3D=3D 255)
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 exit(1);
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (WIFSIGNALED(status))
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 errx(1, "%s: terminated = with signal %d, aborting",
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 name, WTERMSI= G(status));
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (WEXITSTATUS(status) =3D=3D 255)
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 errx(1, "%s: exited with= status 255, aborting", name);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (WEXITSTATUS(status))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0rval =3D 1;
=A0 =A0 =A0 =A0}

This fix exposes an e= xisting, but hard to reproduce bug ( see: PR 165164: http://www.freebsd.org/cgi/query-= pr.cgi?pr=3D165164 ). =A0The patch from PR 165164 should be applied pri= or to, on along side this patch, else you will see a lot more:

xargs: (null): error

diagnosti= c messages.
=A0


>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
freebsd-standards@freebsd.= org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-standards<= /a>
To unsubscribe, send any mail to "freebsd-standards-unsubscribe@freebsd.org"= ;



--
regards,
= matt
--bcaec5014bf3f3f9da04b8fa2daa-- From owner-freebsd-standards@FreeBSD.ORG Wed Feb 15 13:55:17 2012 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C6DF106564A for ; Wed, 15 Feb 2012 13:55:17 +0000 (UTC) (envelope-from nicolas.bourdaud@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 814F88FC19 for ; Wed, 15 Feb 2012 13:55:16 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so1198291bkc.13 for ; Wed, 15 Feb 2012 05:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; bh=IWjW83CqYLjJG/d556Kod8rHXrshbJoo5Gmu1pQjE4c=; b=LGv70O17lZjIL/mSEtiaYodBiDm/BgsASUCNE43UtWrLSTPnQ/rPM8o2IpRgjEx2Ta f3nakpVmQbK+FYK7gjwn3ouoZY8aY9TqExt0gdzbHvDiiDC6OzMnWMhLrAVEhpRX2PRA gct/PkzPH48erickgCTwiZijhzbpV5hl+wZlI= Received: by 10.205.121.136 with SMTP id gc8mr11837215bkc.126.1329312655215; Wed, 15 Feb 2012 05:30:55 -0800 (PST) Received: from [128.178.22.156] (cnbipc27.epfl.ch. [128.178.22.156]) by mx.google.com with ESMTPS id ey8sm6741473bkb.1.2012.02.15.05.30.54 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 05:30:54 -0800 (PST) Message-ID: <4F3BB384.9060607@gmail.com> Date: Wed, 15 Feb 2012 14:30:44 +0100 From: Nicolas Bourdaud User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Lightning/1.0b2 Thunderbird/3.1.18 MIME-Version: 1.0 To: freebsd-standards@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig2C1B1EFD1A709EFD994612A5" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: write system call violates POSIX standard X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 13:55:17 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2C1B1EFD1A709EFD994612A5 Content-Type: multipart/mixed; boundary="------------060608040201020506000708" This is a multi-part message in MIME format. --------------060608040201020506000708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, When a write() cannot transfer as many bytes as requested (because of a file limit), it fails instead of transferring as many bytes as there is room to write. This is a violation of the POSIX standard: http://pubs.opengroup.org/onlinepubs/007904975/functions/write.html I have provided a small test to verify the problem (fsize-lim.c). I have also created a bug report but I have been advised to post on this mailing list anyway: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D164793 Best regards Nicolas --------------060608040201020506000708-- --------------enig2C1B1EFD1A709EFD994612A5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPO7OEAAoJEMTcslrXGllyMEcQAKhxMEwlDfYRxVOl9b4L6Q9l 09TGsG+hYSqx3eAS2M7NpgmHMM1mHF7lJhoAWIE3c5NFgEcNxnCIaHubAuwndYQG V3IbI/1X9ixzYCBR4esVsXoUjRkd05DpRcP7BpfZGbDJMvagZdMAKNKph/X2mees jRInjFV2LzthgArYgm1T99xQ8VdijpW9mqxCLx00Mxf+JDQvEE8u0x/i2mxI4/zZ Wuavx2tOCpJeuJcB9aEauxGuXqxCq9TW0CX5fRcfRCS2fCrfV2hYFzuPL8sugGjk Vt9caOESYCqR+W2y39CkZPbHsJi2iRAYTT2Uh05OdfRBOMJTRk1oWdHJvAPK22tI 2irw+kwFotbI5rSGQMp7eJLS+ONY+xlX/xVQVwFeTpCAu06XRiYjuoR84EYyvTzb kQT+Stg7FhTxz7k90buySE4ReEPQEsTsMIm0BvUHwr/Dp88tqImltDzJe6fG+2if XUC7m13t3Pm4y/PxIblk0Q8aLOZSiFKdR8SszSnFqJKBOqb/aUnmbEWIYtpbgYTz Kx9pB8XNqjWs04dLvpxV1WuY1uJwTyJ2i0jJDkTIptZyg2QSLsif1zrpP3MViPdN 0dsEmv1d2Yri/53OItlVmAIpT12jsesm+P6/+hBaYF2mLSeQLP7XvoJkVpnh05sl O7AzfYv0Efb3hpNYBq8q =rwA+ -----END PGP SIGNATURE----- --------------enig2C1B1EFD1A709EFD994612A5-- From owner-freebsd-standards@FreeBSD.ORG Wed Feb 15 14:36:16 2012 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D00B106566C for ; Wed, 15 Feb 2012 14:36:16 +0000 (UTC) (envelope-from nicolas.bourdaud@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 947758FC15 for ; Wed, 15 Feb 2012 14:36:15 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so1258651bkc.13 for ; Wed, 15 Feb 2012 06:36:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=BSwYS9Pp/T5F/wuhf2XsvxkyQCEloh9CXyxkcV8cPYU=; b=aMQEmhxC4ajULd0vD3vyqJ9K133w2/0Mlt0omc6nk5u1oiSQoalQB+3RAWA9jLz8s5 qvi8IbjKdS3FF+PFYLpaI9TO/p049MbTkiR3KnBhwTrDKYGsKG51r/QIekD2uqxEKTbh MdyGTfhpGOhI/3h5XUm5qYDhcXy1TE4f7DmWg= Received: by 10.205.112.6 with SMTP id eq6mr11983155bkc.16.1329316572982; Wed, 15 Feb 2012 06:36:12 -0800 (PST) Received: from [128.178.22.156] (cnbipc27.epfl.ch. [128.178.22.156]) by mx.google.com with ESMTPS id ut6sm6949599bkb.14.2012.02.15.06.36.12 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 06:36:12 -0800 (PST) Message-ID: <4F3BC2DB.6080703@gmail.com> Date: Wed, 15 Feb 2012 15:36:11 +0100 From: Nicolas Bourdaud User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Lightning/1.0b2 Thunderbird/3.1.18 MIME-Version: 1.0 To: freebsd-standards@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: write system call violates POSIX standard X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:36:16 -0000 [resent since the signature messed my previous message on the mailing list archive] Hi all, When a write() cannot transfer as many bytes as requested (because of a file limit), it fails instead of transferring as many bytes as there is room to write. This is a violation of the POSIX standard: http://pubs.opengroup.org/onlinepubs/007904975/functions/write.html I have provided a small test to verify the problem (fsize-lim.c). I have also created a bug report but I have been advised to post on this mailing list anyway: http://www.freebsd.org/cgi/query-pr.cgi?pr=164793 Best regards Nicolas test file: fsize-lim.c: #include #include #include #include #include #include #include #include #include #include #define TARGETSIZE 80000 #define LIMSIZE 60000 #define PATTSIZE 27 int main(void) { struct rlimit lim; int fd; ssize_t retc; size_t count = 0; const char pattern[PATTSIZE] = "Hello world!"; signal(SIGXFSZ, SIG_IGN); getrlimit(RLIMIT_FSIZE, &lim); lim.rlim_cur = LIMSIZE; setrlimit(RLIMIT_FSIZE, &lim); fd = open("result.txt", O_WRONLY|O_CREAT|O_TRUNC, S_IRUSR|S_IWUSR); while (count < TARGETSIZE) { retc = write(fd, pattern, PATTSIZE); if (retc < PATTSIZE && retc > 0) fprintf(stderr, "added %zi bytes instead of %u bytes after %zu bytes\n", retc, PATTSIZE, count); else if (retc < 0) { fprintf(stderr, "failed when adding %u bytes after %zu bytes (error: %s)\n", PATTSIZE, count, strerror(errno)); break; } count += retc; } close(fd); return 0; } From owner-freebsd-standards@FreeBSD.ORG Wed Feb 15 16:45:20 2012 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F16921065676 for ; Wed, 15 Feb 2012 16:45:20 +0000 (UTC) (envelope-from nicolas.bourdaud@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 78A158FC19 for ; Wed, 15 Feb 2012 16:45:20 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so1456515bkc.13 for ; Wed, 15 Feb 2012 08:45:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=E/ggEClhRMzezquPs9LdKLsie6KylJPRwiJmLfO3ELU=; b=XNs5vLLzSfy1wd5GdNOVMBddhQ2STpmiO3tcIP80efLowBpFB45i26nqGOXQXXHtTv ZhbkNIC6HvfcL09IY5b3iLapYwRuSJK6wso3eS9wkcfdpP9HjYB6KXTkrz9dMLya5+rg OsAVDA2NVglGSgFqFQCY0aBQRLJ2AorgLoKIA= Received: by 10.204.149.198 with SMTP id u6mr12114419bkv.138.1329324319355; Wed, 15 Feb 2012 08:45:19 -0800 (PST) Received: from [128.178.22.156] (cnbipc27.epfl.ch. [128.178.22.156]) by mx.google.com with ESMTPS id y9sm7799303bkw.5.2012.02.15.08.45.18 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 08:45:18 -0800 (PST) Message-ID: <4F3BE109.9060702@gmail.com> Date: Wed, 15 Feb 2012 17:44:57 +0100 From: Nicolas Bourdaud User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.26) Gecko/20120131 Lightning/1.0b2 Thunderbird/3.1.18 MIME-Version: 1.0 To: Konstantin Belousov References: <4F3BC2DB.6080703@gmail.com> <20120215163800.GA3283@deviant.kiev.zoral.com.ua> In-Reply-To: <20120215163800.GA3283@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigD018DA2A110BA37996BD6FE2" Cc: freebsd-standards@freebsd.org Subject: Re: write system call violates POSIX standard X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 16:45:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD018DA2A110BA37996BD6FE2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Konstantin, On 15/02/2012 17:38, Konstantin Belousov wrote: > It seems that you are right. >=20 > A solution could be to return an error if uio->uio_offset itself is > larger them RLIMIT_FSIZE. If it is less then the limit, the function > could trim the supplied uio at the RLIMIT_FSIZE value instead. >=20 > Do you want to work on the patch ? Oooohhh, no I don't know freebsd kernel enough for this!!!! I hit the problem for a Debian package. So I am just reporting the bug :-). Bruce Evans seems to have also ideas about the underlying problem, see his comments in the bug report: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D164793 Good luck! Cheers Nicolas --------------enigD018DA2A110BA37996BD6FE2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJPO+EJAAoJEMTcslrXGllyNd4P/1UdMwoG/usObeBntYRMy3zf SRfxrUmiSz4m1Ey+SoZpc7yF+N3hvj1SVuYSFZjAnivgjQnEEX7a62YPUyJCFNMq FP6c0d1shs9RiqpQsewkjmNQWrXz+k4byeFRN2OCnOMu9JPADLTuMYO5Mkx3iUFf oou/eVnwfdZpWk9RjKjQusYlF/3Q7xcH0v09yYCbb1fSbF8p4bp305w+ZgCKDjVh d7Z6Couxw5h42DOJtFiwXn/I2zO25I+RIOdOgm/XjSUzmYHGMo9Eruf+6h3BfUFH 2VzujrWybiktSgNeAv6WUuSUKfk+BMQF1BJzI1+uCsVlzWwLovAUeBJ7ys7NIG/a 3PQhD8Fzf32LV5ZD9Sgm+K5gIvXuhocy8cess20FFphLG4jh4kQqpjYLDjJ6iLE3 M7+mgSsxU+G/0FwAdd42wTP8iilg8xVZXify9NZ7eZdZ1PDkfADgdMeuruliv4RP HP68vLhM+yfgwnaUo4vaL2qFr9yv7UbL6l4LcbEAKyE713OGwR9MagTQOIoG2yB9 4nMz4PyuNCigbLei8e3UTH+xhfO/+PzUq2Nx2ewhD9vH1l4Nsi9c2ITQDSdIRhP+ hPT6kCaKl0/IWe9zXOTpXW8CjW9SXOmiB4wlhxQMaZXYTuOZh5hKz+Xaegs0w38j 7L9waF3E2VM7kxdLxTAv =uirY -----END PGP SIGNATURE----- --------------enigD018DA2A110BA37996BD6FE2-- From owner-freebsd-standards@FreeBSD.ORG Wed Feb 15 17:09:16 2012 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F15871065670 for ; Wed, 15 Feb 2012 17:09:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8495A8FC0C for ; Wed, 15 Feb 2012 17:09:15 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1FGc0im061143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 18:38:01 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1FGc0E3005572; Wed, 15 Feb 2012 18:38:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1FGc0UU005571; Wed, 15 Feb 2012 18:38:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 15 Feb 2012 18:38:00 +0200 From: Konstantin Belousov To: Nicolas Bourdaud Message-ID: <20120215163800.GA3283@deviant.kiev.zoral.com.ua> References: <4F3BC2DB.6080703@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="68DmL13w0Y+UeQNe" Content-Disposition: inline In-Reply-To: <4F3BC2DB.6080703@gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-standards@freebsd.org Subject: Re: write system call violates POSIX standard X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 17:09:16 -0000 --68DmL13w0Y+UeQNe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2012 at 03:36:11PM +0100, Nicolas Bourdaud wrote: > [resent since the signature messed my previous message on the mailing > list archive] >=20 > Hi all, >=20 > When a write() cannot transfer as many bytes as requested (because of a > file limit), it fails instead of transferring as many bytes as there is > room to write. >=20 > This is a violation of the POSIX standard: > http://pubs.opengroup.org/onlinepubs/007904975/functions/write.html >=20 >=20 > I have provided a small test to verify the problem (fsize-lim.c). >=20 > I have also created a bug report but I have been advised to post on this > mailing list anyway: > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D164793 >=20 >=20 > Best regards >=20 > Nicolas >=20 > test file: fsize-lim.c: >=20 > #include > #include > #include > #include > #include > #include > #include > #include > #include > #include >=20 > #define TARGETSIZE 80000 > #define LIMSIZE 60000 > #define PATTSIZE 27 >=20 >=20 > int main(void) > { > struct rlimit lim; > int fd; > ssize_t retc; > size_t count =3D 0; > const char pattern[PATTSIZE] =3D "Hello world!"; > =09 > signal(SIGXFSZ, SIG_IGN); > getrlimit(RLIMIT_FSIZE, &lim); > lim.rlim_cur =3D LIMSIZE; > setrlimit(RLIMIT_FSIZE, &lim); >=20 > fd =3D open("result.txt", O_WRONLY|O_CREAT|O_TRUNC, S_IRUSR|S_IWUSR); >=20 > while (count < TARGETSIZE) { > retc =3D write(fd, pattern, PATTSIZE); >=20 > if (retc < PATTSIZE && retc > 0) > fprintf(stderr, > "added %zi bytes instead of %u bytes after %zu bytes\n", > retc, PATTSIZE, count); > else if (retc < 0) { > fprintf(stderr, > "failed when adding %u bytes after %zu bytes (error: %s)\n", > PATTSIZE, count, strerror(errno)); > break; > } > count +=3D retc; > } >=20 > close(fd); >=20 > return 0; > } It seems that you are right. A solution could be to return an error if uio->uio_offset itself is larger them RLIMIT_FSIZE. If it is less then the limit, the function could trim the supplied uio at the RLIMIT_FSIZE value instead. Do you want to work on the patch ? --68DmL13w0Y+UeQNe Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk8732gACgkQC3+MBN1Mb4itxACg9PwlSrxjdyO8oy92PHMXxkpO V+IAn3yMTyl62vfoASXQm4XcdH3GVlNe =E/dV -----END PGP SIGNATURE----- --68DmL13w0Y+UeQNe-- From owner-freebsd-standards@FreeBSD.ORG Wed Feb 15 20:02:52 2012 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 219A8106566C for ; Wed, 15 Feb 2012 20:02:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9FA648FC13 for ; Wed, 15 Feb 2012 20:02:51 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1FK2mpX031556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Feb 2012 07:02:49 +1100 Date: Thu, 16 Feb 2012 07:02:48 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov In-Reply-To: <20120215163800.GA3283@deviant.kiev.zoral.com.ua> Message-ID: <20120216054457.H3935@besplex.bde.org> References: <4F3BC2DB.6080703@gmail.com> <20120215163800.GA3283@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@freebsd.org, Nicolas Bourdaud Subject: Re: write system call violates POSIX standard X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 20:02:52 -0000 On Wed, 15 Feb 2012, Konstantin Belousov wrote: > On Wed, Feb 15, 2012 at 03:36:11PM +0100, Nicolas Bourdaud wrote: >> When a write() cannot transfer as many bytes as requested (because of a >> file limit), it fails instead of transferring as many bytes as there is >> room to write. >> >> This is a violation of the POSIX standard: >> http://pubs.opengroup.org/onlinepubs/007904975/functions/write.html >> ... > It seems that you are right. Here is a corresponding test to show the complete brokenness of RLIMIT_FSIZE for [f]truncate(): %%% #include #include #include #include #include #include #include #define LIMSIZE 60000 int main(void) { struct rlimit lim; struct stat sb; int fd; if (signal(SIGXFSZ, SIG_IGN) == SIG_ERR) err(1, "signal"); if (getrlimit(RLIMIT_FSIZE, &lim) != 0) err(1, "getrlimit"); lim.rlim_cur = LIMSIZE; if (setrlimit(RLIMIT_FSIZE, &lim) != 0) err(1, "setrlimit"); fd = open("result.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd < 0) err(1, "open"); if (fstat(fd, &sb) != 0) err(1, "first stat"); if (sb.st_size != 0) errx(1, "O_TRUNC failed to truncate the file"); if (ftruncate(fd, 2 * LIMSIZE) != 0) err(1, "ftruncate"); if (fstat(fd, &sb) != 0) err(1, "stat"); warnx("size = %jd", (intmax_t)sb.st_size); if (sb.st_size == 2 * LIMSIZE) errx(1, "ftruncate failed to honour RLIMIT_FSIZE, as expected"); if (sb.st_size != 0) errx(1, "ftruncate worked incorrectly, but not as expected"); errx(0, "ftruncate worked correctly, but not as expected"); } %%% > A solution could be to return an error if uio->uio_offset itself is > larger them RLIMIT_FSIZE. If it is less then the limit, the function ^ or equal to, and the count is not 0 (?) > could trim the supplied uio at the RLIMIT_FSIZE value instead. > > Do you want to work on the patch ? Only indirectly for me :-). Note that both of these are XSI extensions, and FreeBSD doesn't claim to support XSI, so it doesn't have to duplicate any XSI bugs in these APIs. But it is clearly a bug to not honor the rlimit at all. Anyone can try to create multiple-petabyte files in FreeBSD, and often succeed, and such files may take a lot of space for metadata although all blocks beyond the rlimit must be zero. Note that the error handling is different but simpler for [f]truncate(). The current error checking in vfs is correct for these. Except, see below about null changes. There is another thread (PR or POSIX mail?) about truncate() having different, broken, semantics than iftruncate() when its effect is null. POSIX specifies that ftruncate() shall mark times for update on successful completion, as usual, but POSIX specifies that "if the file size is changed, this function shall mark for update...". This is a bug in POSIX, but Linux apparently implemented it. FreeBSD doesn't implement it, at least in ffs. In ffs_update(), the implementation is to check for this case early and do nothing except mark for update before returning. POSIX has fuzzy wording for the interaction of these bugs. Suppose that the file size is already larger than the rlimit, and we try to truncate it to its current size. Is this a null change or an EFBIG error? POSIX only says (for [f]truncate) that "if the request _would_ _cause_ the file size to exceed the soft file limit, [then it is an error]". I think a null change "wouldn't cause" the file to exceed the limit in this case, because the cause of exceeding the limit is that the limit was already exceeded. However, it takes a delicate reading of "would case" to get this interpretation, and FreeBSD never did it this way in cases where it actually checks the limit -- for write(), the limit is checked before even looking at the current file size. The centralization of the limit checking makes it harder to change this, because the central function doesn't know the file size. Truncations that would reduce the file size from beyond the limit to less beyond the limit are also interesting. Are these allowed? Now they cause something, but they don't cause the file size to exceed the limit, so a strict reading of "would cause" again allows them. write() has some very nice, different bugs depending on the interpretation of to the corresponding "would cause" for it. In FreeBSD, because the limit checking is done before even looking at the size of the file, write()s to the middle of a big file are rejected if they would extend past the limit. But the POSIX specification is that "if the request _would_ _cause_ the file size to exceed the soft file limit, [then as for truncate, except it is not an error if the write starts before the limit, and bytes shall be written if possible up to the limit in this case]". This wording is not very different that that for ftruncate, but now it seems even harder to blame the write for causing the limit to be exceeded if the write would be in the middle of the file. It seems useful to allow writing in the middle of a big file irrespective of the limit, to allow not-fully-trusted applications to scribble in a big file that you have reserved for them. But the above bug in ftruncate becomes enormous if you allow writing in the middle of a big file that the bug has allowed creation of. Just above the paragraph about this, handling related to ENOSPC is specified as "if a write() requests that more bytes be written than there is room for (for example, ... the physical end of the medium), only as many bytes as there is room for shall be written". This is a little fuzzy, but it seems to be intended to mean that these bytes shall be written with no error if possible. This disallows the ffs treatment of backing out of the entire write after an ENOSPC error in the same way as after an EIO error. Bruce From owner-freebsd-standards@FreeBSD.ORG Thu Feb 16 16:19:47 2012 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F582106564A for ; Thu, 16 Feb 2012 16:19:47 +0000 (UTC) (envelope-from matthewstory@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 51FEA8FC12 for ; Thu, 16 Feb 2012 16:19:46 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2343460vcm.13 for ; Thu, 16 Feb 2012 08:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=R0yyzgoKHJQ4qHSrBOA8pznYt599Wsy8rMVEwJUhxGY=; b=MU7a/LUq52nVgLS58taV9Cahl+MAnUPMW6AaEl1IG5E0EVtgn4zOGPfdxqFOqClbds K9ds9jXdMQdLbabEo2zw89X1cvQNwk+TX0TRGU3YClzZ8F2jxPAOyG7y78LUXO/rwIrh 03GTF77V8NIwYP2Fx6FWsfmqK8d+htdKnQuK0= MIME-Version: 1.0 Received: by 10.220.228.73 with SMTP id jd9mr1596243vcb.58.1329407711842; Thu, 16 Feb 2012 07:55:11 -0800 (PST) Received: by 10.52.21.84 with HTTP; Thu, 16 Feb 2012 07:55:11 -0800 (PST) In-Reply-To: <201201312306.q0VN6roO091429@red.freebsd.org> References: <201201312306.q0VN6roO091429@red.freebsd.org> Date: Thu, 16 Feb 2012 10:55:11 -0500 Message-ID: From: Matthew Story To: freebsd-gnats-submit@freebsd.org, freebsd-standards@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: kern/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:19:47 -0000 On Tue, Jan 31, 2012 at 6:06 PM, Matthew Story wrote: > > >Number: 164674 > >Category: kern > >Synopsis: vfprintf/vfwprintf return error (EOF) on success if > __SERR flag is already set on file > Apologies for cross-posting, but I think that standards might be a more appropriate responsible party for this than -bugs or kern. See description for more info, but the basic issue is that C99 and C11 stipulate that fprintf should return -1 "if an output or encoding error occurred." Currently, printf is encoding and outputting successfully (on line or fully buffered FILEs), but returning -1 if the FILE has an error. The C99/C11 specifications make no mention of FILE state in fprintf return conditions, so this functionality seems to not conform to the specification, attached patch resolves that issue. > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-bugs > >State: open > [...snip] > >Description: > The printf family of functions behaves unpredictably if the file passed to > the function has the __SERR flag set in _flags. The one consistency across > all of the cases detailed below is that regardless of the number of bytes > written to the file, and the success/failure of that operation, the printf > functions (printf, fprintf, wprintf, fwprintf) will always return -1 (EOF). > > * For the case of an unbuffered file, the operation currently fails > transmitting no bytes, and returns -1. > * For the case of a buffered file, the operation transmits all bytes and > the function returns -1. > > The problem is that the behavior here is inconsistent, and should not be. > The question is wether all should be made to fail consistently and > transmit no bytes if __SERR is set on _flags, or if failure should be > determined based on the success of byte transmission, discounting file > state. > > Per the ISO/IEC 9899:201x (C11) Section 7.21.6.1, 14: > > The fprintf function returns the number of characters transmitted, or a > negative value if an output or encoding error occurred. > > My reading of this specification is that success should be determined > based on byte-transmission, and should not factor-in file state. In > addition to the ISO standard, the glibc implementation will reliably > succeed with any error flag set if bytes are successfully transmitted > (although it will transmit partial messages prior to successful conversion, > which is unfortunate). > > The attached patch makes the operation on buffered and unbuffered files > consistent across the affected printf/wprintf functions, determines > success/failure based on successful byte-transmission alone, and preserves > _flags state for __SERR as passed in. > > [...snip] -- regards, matt From owner-freebsd-standards@FreeBSD.ORG Thu Feb 16 16:32:47 2012 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BFA8106564A for ; Thu, 16 Feb 2012 16:32:47 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id B857C8FC17 for ; Thu, 16 Feb 2012 16:32:46 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q1GGWgdR030271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Feb 2012 03:32:44 +1100 Date: Fri, 17 Feb 2012 03:32:42 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans In-Reply-To: <20120216054457.H3935@besplex.bde.org> Message-ID: <20120217031824.R760@besplex.bde.org> References: <4F3BC2DB.6080703@gmail.com> <20120215163800.GA3283@deviant.kiev.zoral.com.ua> <20120216054457.H3935@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@freebsd.org, Nicolas Bourdaud Subject: Re: write system call violates POSIX standard X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:32:47 -0000 On Thu, 16 Feb 2012, Bruce Evans wrote: > ... > Here is a corresponding test to show the complete brokenness of > RLIMIT_FSIZE for [f]truncate(): I tried this under Linux-2.6.10. Linux worked like I think is correct for truncate, but not for write. > %%% > #include > #include > > #include > #include > #include > #include > #include > > #define LIMSIZE 60000 > > int > main(void) > { > struct rlimit lim; > struct stat sb; > int fd; > > if (signal(SIGXFSZ, SIG_IGN) == SIG_ERR) > err(1, "signal"); > if (getrlimit(RLIMIT_FSIZE, &lim) != 0) > err(1, "getrlimit"); > lim.rlim_cur = LIMSIZE; > if (setrlimit(RLIMIT_FSIZE, &lim) != 0) > err(1, "setrlimit"); > > fd = open("result.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); > if (fd < 0) > err(1, "open"); > if (fstat(fd, &sb) != 0) > err(1, "first stat"); > if (sb.st_size != 0) > errx(1, "O_TRUNC failed to truncate the file"); > if (ftruncate(fd, 2 * LIMSIZE) != 0) > err(1, "ftruncate"); I had to fix this. With a working truncate, this is expected to fail. Linux failed correctly. > if (fstat(fd, &sb) != 0) > err(1, "stat"); > warnx("size = %jd", (intmax_t)sb.st_size); > if (sb.st_size == 2 * LIMSIZE) > errx(1, "ftruncate failed to honour RLIMIT_FSIZE, as expected"); > if (sb.st_size != 0) > errx(1, "ftruncate worked incorrectly, but not as expected"); > errx(0, "ftruncate worked correctly, but not as expected"); > } > %%% > ... > POSIX has fuzzy wording for the interaction of these bugs. Suppose > that the file size is already larger than the rlimit, and we try to > truncate it to its current size. Is this a null change or an EFBIG > error? POSIX only says (for [f]truncate) that "if the request _would_ > _cause_ the file size to exceed the soft file limit, [then it is an > error]". I think a null change "wouldn't cause" the file to exceed > the limit in this case, because the cause of exceeding the limit is > that the limit was already exceeded. However, it takes a delicate > reading of "would case" to get this interpretation, and FreeBSD never > did it this way in cases where it actually checks the limit -- for > write(), the limit is checked before even looking at the current > file size. The centralization of the limit checking makes it harder > to change this, because the central function doesn't know the file > size. > > Truncations that would reduce the file size from beyond the limit to less > beyond the limit are also interesting. Are these allowed? Now they > cause something, but they don't cause the file size to exceed the limit, > so a strict reading of "would cause" again allows them. Linux allows such truncations. To test this, remove the O_TRUNC from the above and copy a file larger than 120000 bytes to result.txt before running the program. > write() has some very nice, different bugs depending on the > interpretation of to the corresponding "would cause" for it. In > FreeBSD, because the limit checking is done before even looking at the > size of the file, write()s to the middle of a big file are rejected > if they would extend past the limit. But the POSIX specification is > that "if the request _would_ _cause_ the file size to exceed the soft > file limit, [then as for truncate, except it is not an error if the > write starts before the limit, and bytes shall be written if possible > up to the limit in this case]". This wording is not very different > that that for ftruncate, but now it seems even harder to blame the > write for causing the limit to be exceeded if the write would be in > the middle of the file. It seems useful to allow writing in the middle > of a big file irrespective of the limit, to allow not-fully-trusted > applications to scribble in a big file that you have reserved for them. > But the above bug in ftruncate becomes enormous if you allow writing > in the middle of a big file that the bug has allowed creation of. Linux doesn't allow writing beyond the limit in a file whose size is already beyond the limit. To test this, remove the O_TRUNC and the ftruncate from the original program, then start with a large file. Hmm, I was sloppy in testing and might have forgotten to remove the ftruncate. Bruce From owner-freebsd-standards@FreeBSD.ORG Fri Feb 17 15:10:14 2012 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88869106564A for ; Fri, 17 Feb 2012 15:10:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 60DB28FC12 for ; Fri, 17 Feb 2012 15:10:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q1HFAE9O033388 for ; Fri, 17 Feb 2012 15:10:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1HFAEgo033387; Fri, 17 Feb 2012 15:10:14 GMT (envelope-from gnats) Resent-Date: Fri, 17 Feb 2012 15:10:14 GMT Resent-Message-Id: <201202171510.q1HFAEgo033387@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, Petko Bordjukov Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26326106564A for ; Fri, 17 Feb 2012 15:01:37 +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 EB0618FC08 for ; Fri, 17 Feb 2012 15:01:36 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q1HF1a9B099014 for ; Fri, 17 Feb 2012 15:01:36 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q1HF1aOq099013; Fri, 17 Feb 2012 15:01:36 GMT (envelope-from nobody) Message-Id: <201202171501.q1HF1aOq099013@red.freebsd.org> Date: Fri, 17 Feb 2012 15:01:36 GMT From: Petko Bordjukov To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: standards/165236: The NONE Wi-Fi regulatory restricts use of channels 12:ht/40- and 13:ht/40- X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 15:10:14 -0000 >Number: 165236 >Category: standards >Synopsis: The NONE Wi-Fi regulatory restricts use of channels 12:ht/40- and 13:ht/40- >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: Fri Feb 17 15:10:13 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Petko Bordjukov >Release: 10.0-CURRENT >Organization: >Environment: # uname -a FreeBSD apd3n 10.0-CURRENT FreeBSD 10.0-CURRENT #6 r231845M: Thu Jan 1 02:00:00 EET 1970 root@dummy:/crossbuild/mipseb/obj/mips.mipseb/src-head/sys/ROUTERSTATION mips >Description: The current specification of the NONE regulatory domain does not permit use of channels 12:ht/40- and 13:ht/40-. There is a large possibility that usage of these channels is permitted under the EU regulations, however I was unable to find concrete information to support this, except the contents of the regulatory database found here: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=blob_plain;f=db.txt;hb=HEAD More info: http://en.wikipedia.org/wiki/802.11n#40.C2.A0MHz_in_2.4.C2.A0GHz http://en.wikipedia.org/wiki/List_of_WLAN_channels EU Standards: ETSI EN 300 328 V1.7.1 # dmesg --- cut --- ath0: irq 0 at device 17.0 on pci0 ath0: [HT] enabling HT modes ath0: [HT] 2 RX streams; 2 TX streams ath0: AR9220 mac 128.2 RF5133 phy 13.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 --- cut --- # ifconfig wlan0 country BG # ifconfig wlan0 regdomain NONE # ifconfig wlan0 wlan0: flags=8802 metric 0 mtu 1500 ether <-- removed --> inet6 fe80::<-- removed -->%wlan0 prefixlen 64 scopeid 0x7 nd6 options=21 media: IEEE 802.11 Wireless Ethernet autoselect mode 11ng (autoselect ) status: no carrier ssid test channel 1 (2412 MHz 11b) regdomain NONE country BG indoor ecm authmode OPEN privacy OFF txpower 30 scanvalid 60 wme burst dtimperiod 1 # ifconfig wlan0 up # ifconfig wlan0 channel 13:ht/40- ifconfig: unknown/undefined channel number 13 flags 0x40000 >How-To-Repeat: ifconfig wlan0 create wlandev ath0 wlanmode hostap ssid test ifconfig wlan0 country BG ifconfig wlan0 regdomain NONE ifconfig wlan0 channel 13:ht/40- >Fix: Apply the attached patch to /etc/regdomain.xml Patch attached with submission follows: Index: etc/regdomain.xml =================================================================== --- etc/regdomain.xml (revision 231845) +++ etc/regdomain.xml (working copy) @@ -1154,7 +1154,7 @@ IEEE80211_CHAN_HT20 - + 30 IEEE80211_CHAN_G IEEE80211_CHAN_HT40 >Release-Note: >Audit-Trail: >Unformatted: