From owner-freebsd-standards@FreeBSD.ORG Mon Apr 2 11:07:18 2012 Return-Path: Delivered-To: freebsd-standards@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6362710656D5 for ; Mon, 2 Apr 2012 11:07:18 +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 452FB8FC1A for ; Mon, 2 Apr 2012 11:07:18 +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 q32B7IUH046927 for ; Mon, 2 Apr 2012 11:07:18 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q32B7Hww046925 for freebsd-standards@FreeBSD.org; Mon, 2 Apr 2012 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 2 Apr 2012 11:07:17 GMT Message-Id: <201204021107.q32B7Hww046925@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, 02 Apr 2012 11:07:18 -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/166463 standards remquo[f] may return wrong sign in quo part and incorr o stand/166349 standards Support the assignment-allocation character for fscanf o stand/165236 standards The NONE Wi-Fi regulatory restricts use of channels 12 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/154842 standards invalid request authenticator in the second and subseq o stand/150093 standards C++ std::locale support is broken 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 35 problems total. From owner-freebsd-standards@FreeBSD.ORG Mon Apr 2 20:05:25 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 497B01065674; Mon, 2 Apr 2012 20:05:25 +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 DB7708FC24; Mon, 2 Apr 2012 20:05:24 +0000 (UTC) Received: by vcmm1 with SMTP id m1so2800368vcm.13 for ; Mon, 02 Apr 2012 13:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=iHzlTyip48bKnIaUZqi3RRaf/tOz1L+h011rrEOOJoQ=; b=H1Exa4j9JwFbzjwdufgglUwcdAnavxMzJPJt38+WZuMmCHCXosEzBu4wzy5hOK7IPh /JtH2mReY3e05Epk2bTcDcdqChqkgim7qSFO1In9a0lxn5PmedgIBeiuVB4dIu5eaq1u 8MvA35nvPpUBp2DmYZzT2TDgMf26b1UH2oYLiFLC6Ln61CBBnMQJxet7LhkpDrbB7o7v DGhsk3fRb/IWbTfmDIgQeQyqc0MYhIpEAI3Kq2OikeUJj6xBz0o5Eu6e99ofEc1O07iW S2Da4iYGzqEMBbymd9r3TBZUNzLgCaEd4kIU+WmE2jJ7LbZDtZHMFOYgTeDEVpwfBH6j C+ZQ== MIME-Version: 1.0 Received: by 10.52.64.200 with SMTP id q8mr3597532vds.92.1333397124390; Mon, 02 Apr 2012 13:05:24 -0700 (PDT) Received: by 10.52.117.66 with HTTP; Mon, 2 Apr 2012 13:05:24 -0700 (PDT) In-Reply-To: References: <201201312306.q0VN6roO091429@red.freebsd.org> Date: Mon, 2 Apr 2012 16:05:24 -0400 Message-ID: From: Matthew Story To: freebsd-gnats-submit@freebsd.org, freebsd-standards@freebsd.org Content-Type: multipart/mixed; boundary=20cf307813d4f19f8d04bcb7b558 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: Mon, 02 Apr 2012 20:05:25 -0000 --20cf307813d4f19f8d04bcb7b558 Content-Type: text/plain; charset=ISO-8859-1 [excerpts from other thread] On Wed, Mar 21, 2012 at 5:45 PM, David Schultz wrote: > On Mon, Mar 12, 2012, Matthew Story wrote: >> On Sun, Mar 4, 2012 at 2:03 PM, John Baldwin wrote: >> >> > My standard-parsing fu is weak. Can some other folks on this list look at >> > this PR, figure out what the correct semantics for *fprintf() in this case, >> > and evaluate the patch? Thanks. > [...] >> libc vfprintf currently behaves differently on un|buffered FILEs with >> ferror set: >> >> 1. Unbuffered FILEs >> >> -> does not transmit any bytes, and returns -1 >> >> 2. Buffered FILEs (fully buffered, or line buffered) >> >> -> transmits all bytes, and returns -1 >> >> I believe that this should be reconciled such that vfprintf (and all >> derivatives) returns sucess|failure based on transmission, not taking >> ferror state into account, but an alternate solution would be to reconcile >> the behavior of buffered FILEs with the current behavior of unbuffered >> FILEs (e.g. detect ferror state, transmit no bytes and return -1). > > I agree with this assessment. When the error indicator is set on > a stream, it means that an error has occurred at some point---not > that all subsequent operations on the stream should fail. > > There ought to be a less ugly fix than the one proposed. Probably > the PRINT macro and the various other evil macros in vfprintf() > should set ret to EOF, and the following lines in vfprintf.c should > be removed: > > if (__sferror(fp)) > ret = EOF; > > If vfprintf() is fixed so that printing to a buffered stream > always returns success after a successful write (regardless of the > prior state of the stream's error indicator), that should fix the > problem for unbuffered streams automatically. Unbuffered streams > go through __sbprintf(), which throws away the output if > vfprintf() returns -1. I've followed up on David's suggestion to remove this test and set ret = EOF prior to goto error in all relevant places. I audited all cases where __SERR could potentially be set, and determined that all cases are correctly setting __SERR, returning error in the bounding function, and properly going to error within __vf(w)printf already (I have an exhaustive list of these if anyone is curious ...). Original test program in the PR works with this patch, and the regressions for stdio all function as expected. I took the liberty of cleaning up a few return -1's, in favor of return EOF's. All in all, this is much less ugly than the previous solution. patch is against head ... -- regards, matt --20cf307813d4f19f8d04bcb7b558 Content-Type: text/plain; charset=US-ASCII; name="freebsd.PR164674-better.patch.txt" Content-Disposition: attachment; filename="freebsd.PR164674-better.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0jy3ng60 SW5kZXg6IGxpYi9saWJjL3N0ZGlvL3Zmd3ByaW50Zi5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpYi9saWJj L3N0ZGlvL3Zmd3ByaW50Zi5jCShyZXZpc2lvbiAyMzM3ODApCisrKyBsaWIvbGliYy9zdGRpby92 ZndwcmludGYuYwkod29ya2luZyBjb3B5KQpAQCAtNDQ5LDIwICs0NDksMjggQEAKIAogCS8qIEJF V0FSRSwgdGhlc2UgYGdvdG8gZXJyb3InIG9uIGVycm9yLiAqLwogI2RlZmluZQlQUklOVChwdHIs IGxlbikJZG8gewkJCVwKLQlpZiAoaW9fcHJpbnQoJmlvLCAocHRyKSwgKGxlbiksIGxvY2FsZSkp CVwKLQkJZ290byBlcnJvcjsgXAorCWlmIChpb19wcmludCgmaW8sIChwdHIpLCAobGVuKSwgbG9j YWxlKSkgewlcCisJCXJldCA9IEVPRjsJXAorCQlnb3RvIGVycm9yOwlcCisJfQlcCiB9IHdoaWxl ICgwKQogI2RlZmluZQlQQUQoaG93bWFueSwgd2l0aCkgeyBcCi0JaWYgKGlvX3BhZCgmaW8sICho b3dtYW55KSwgKHdpdGgpLCBsb2NhbGUpKSBcCi0JCWdvdG8gZXJyb3I7IFwKKwlpZiAoaW9fcGFk KCZpbywgKGhvd21hbnkpLCAod2l0aCksIGxvY2FsZSkpIHsJXAorCQlyZXQgPSBFT0Y7CVwKKwkJ Z290byBlcnJvcjsJXAorCX0JXAogfQogI2RlZmluZQlQUklOVEFORFBBRChwLCBlcCwgbGVuLCB3 aXRoKSB7CVwKLQlpZiAoaW9fcHJpbnRhbmRwYWQoJmlvLCAocCksIChlcCksIChsZW4pLCAod2l0 aCksIGxvY2FsZSkpIFwKLQkJZ290byBlcnJvcjsgXAorCWlmIChpb19wcmludGFuZHBhZCgmaW8s IChwKSwgKGVwKSwgKGxlbiksICh3aXRoKSwgbG9jYWxlKSkgewlcCisJCXJldCA9IEVPRjsJXAor CQlnb3RvIGVycm9yOwlcCisJfQlcCiB9CiAjZGVmaW5lCUZMVVNIKCkgeyBcCi0JaWYgKGlvX2Zs dXNoKCZpbywgbG9jYWxlKSkgXAotCQlnb3RvIGVycm9yOyBcCisJaWYgKGlvX2ZsdXNoKCZpbywg bG9jYWxlKSkgewlcCisJCXJldCA9IEVPRjsJXAorCQlnb3RvIGVycm9yOwlcCisJfQlcCiB9CiAK IAkvKgpAQCAtODk3LDYgKzkwNSw3IEBACiAJCQkJCWNvbnZidWYgPSBfX21ic2NvbnYobWJwLCBw cmVjKTsKIAkJCQkJaWYgKGNvbnZidWYgPT0gTlVMTCkgewogCQkJCQkJZnAtPl9mbGFncyB8PSBf X1NFUlI7CisJCQkJCQlyZXQgPSBFT0Y7CiAJCQkJCQlnb3RvIGVycm9yOwogCQkJCQl9CiAJCQkJ CWNwID0gY29udmJ1ZjsKQEAgLTEwMzAsOCArMTAzOSwxMCBAQAogCQkJLyogbGVhZGluZyB6ZXJv ZXMgZnJvbSBkZWNpbWFsIHByZWNpc2lvbiAqLwogCQkJUEFEKGRwcmVjIC0gc2l6ZSwgemVyb2Vz KTsKIAkJCWlmIChncy5ncm91cGluZykgewotCQkJCWlmIChncm91cGluZ19wcmludCgmZ3MsICZp bywgY3AsIGJ1ZitCVUYsIGxvY2FsZSkgPCAwKQorCQkJCWlmIChncm91cGluZ19wcmludCgmZ3Ms ICZpbywgY3AsIGJ1ZitCVUYsIGxvY2FsZSkgPCAwKSB7CisJCQkJCXJldCA9IEVPRjsKIAkJCQkJ Z290byBlcnJvcjsKKwkJCQl9CiAJCQl9IGVsc2UgewogCQkJCVBSSU5UKGNwLCBzaXplKTsKIAkJ CX0KQEAgLTEwNDcsMTAgKzEwNTgsMTEgQEAKIAkJCQkJcHJlYyArPSBleHB0OwogCQkJCX0gZWxz ZSB7CiAJCQkJCWlmIChncy5ncm91cGluZykgewotCQkJCQkJbiA9IGdyb3VwaW5nX3ByaW50KCZn cywgJmlvLAotCQkJCQkJICAgIGNwLCBjb252YnVmICsgbmRpZywgbG9jYWxlKTsKLQkJCQkJCWlm IChuIDwgMCkKKwkJCQkJCWlmICgobiA9IGdyb3VwaW5nX3ByaW50KCZncywgJmlvLAorCQkJCQkJ ICAgIGNwLCBjb252YnVmICsgbmRpZywgbG9jYWxlKSkgPCAwKSB7CisJCQkJCQkJcmV0ID0gRU9G OwogCQkJCQkJCWdvdG8gZXJyb3I7CisJCQkJCQl9CiAJCQkJCQljcCArPSBuOwogCQkJCQl9IGVs c2UgewogCQkJCQkJUFJJTlRBTkRQQUQoY3AsIGNvbnZidWYgKyBuZGlnLApAQCAtMTA4OSw4ICsx MTAxLDYgQEAKIAl2YV9lbmQob3JnYXApOwogCWlmIChjb252YnVmICE9IE5VTEwpCiAJCWZyZWUo Y29udmJ1Zik7Ci0JaWYgKF9fc2ZlcnJvcihmcCkpCi0JCXJldCA9IEVPRjsKIAlpZiAoKGFyZ3Rh YmxlICE9IE5VTEwpICYmIChhcmd0YWJsZSAhPSBzdGF0YXJndGFibGUpKQogCQlmcmVlIChhcmd0 YWJsZSk7CiAJcmV0dXJuIChyZXQpOwpJbmRleDogbGliL2xpYmMvc3RkaW8vdmZwcmludGYuYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBsaWIvbGliYy9zdGRpby92ZnByaW50Zi5jCShyZXZpc2lvbiAyMzM3ODAp CisrKyBsaWIvbGliYy9zdGRpby92ZnByaW50Zi5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMjcsNyAr MTI3LDcgQEAKIAljb25zdCBDSEFSICpjcDAgPSBjcDsKIAogCWlmIChpb19wcmludGFuZHBhZChp b3AsIGNwLCBlcCwgZ3MtPmxlYWQsIHplcm9lcywgbG9jYWxlKSkKLQkJcmV0dXJuICgtMSk7CisJ CXJldHVybiAoRU9GKTsKIAljcCArPSBncy0+bGVhZDsKIAl3aGlsZSAoZ3MtPm5zZXBzID4gMCB8 fCBncy0+bnJlcGVhdHMgPiAwKSB7CiAJCWlmIChncy0+bnJlcGVhdHMgPiAwKQpAQCAtMTM3LDkg KzEzNyw5IEBACiAJCQlncy0+bnNlcHMtLTsKIAkJfQogCQlpZiAoaW9fcHJpbnQoaW9wLCBncy0+ dGhvdXNhbmRzX3NlcCwgZ3MtPnRob3VzZXBfbGVuLCBsb2NhbGUpKQotCQkJcmV0dXJuICgtMSk7 CisJCQlyZXR1cm4gKEVPRik7CiAJCWlmIChpb19wcmludGFuZHBhZChpb3AsIGNwLCBlcCwgKmdz LT5ncm91cGluZywgemVyb2VzLCBsb2NhbGUpKQotCQkJcmV0dXJuICgtMSk7CisJCQlyZXR1cm4g KEVPRik7CiAJCWNwICs9ICpncy0+Z3JvdXBpbmc7CiAJfQogCWlmIChjcCA+IGVwKQpAQCAtMzY5 LDIwICszNjksMjggQEAKIAogCS8qIEJFV0FSRSwgdGhlc2UgYGdvdG8gZXJyb3InIG9uIGVycm9y LiAqLwogI2RlZmluZQlQUklOVChwdHIsIGxlbikgeyBcCi0JaWYgKGlvX3ByaW50KCZpbywgKHB0 ciksIChsZW4pLCBsb2NhbGUpKQlcCi0JCWdvdG8gZXJyb3I7IFwKKwlpZiAoaW9fcHJpbnQoJmlv LCAocHRyKSwgKGxlbiksIGxvY2FsZSkpIHsJXAorCQlyZXQgPSBFT0Y7CVwKKwkJZ290byBlcnJv cjsJXAorCX0JXAogfQogI2RlZmluZQlQQUQoaG93bWFueSwgd2l0aCkgeyBcCi0JaWYgKGlvX3Bh ZCgmaW8sIChob3dtYW55KSwgKHdpdGgpLCBsb2NhbGUpKSBcCisJaWYgKGlvX3BhZCgmaW8sICho b3dtYW55KSwgKHdpdGgpLCBsb2NhbGUpKSB7CVwKKwkJcmV0ID0gRU9GOwlcCiAJCWdvdG8gZXJy b3I7IFwKKwl9CVwKIH0KICNkZWZpbmUJUFJJTlRBTkRQQUQocCwgZXAsIGxlbiwgd2l0aCkgewlc Ci0JaWYgKGlvX3ByaW50YW5kcGFkKCZpbywgKHApLCAoZXApLCAobGVuKSwgKHdpdGgpLCBsb2Nh bGUpKSBcCi0JCWdvdG8gZXJyb3I7IFwKKwlpZiAoaW9fcHJpbnRhbmRwYWQoJmlvLCAocCksIChl cCksIChsZW4pLCAod2l0aCksIGxvY2FsZSkpIHsJXAorCQlyZXQgPSBFT0Y7CVwKKwkJZ290byBl cnJvcjsJXAorCX0JXAogfQogI2RlZmluZQlGTFVTSCgpIHsgXAotCWlmIChpb19mbHVzaCgmaW8s IGxvY2FsZSkpIFwKKwlpZiAoaW9fZmx1c2goJmlvLCBsb2NhbGUpKSB7CVwKKwkJcmV0ID0gRU9G OwlcCiAJCWdvdG8gZXJyb3I7IFwKKwl9CVwKIH0KIAogCS8qCkBAIC02MTcsNiArNjI1LDcgQEAK IAkJCQkgICAgKHdjaGFyX3QpR0VUQVJHKHdpbnRfdCksICZtYnMpOwogCQkJCWlmIChtYnNlcWxl biA9PSAoc2l6ZV90KS0xKSB7CiAJCQkJCWZwLT5fZmxhZ3MgfD0gX19TRVJSOworCQkJCQlyZXQg PSBFT0Y7CiAJCQkJCWdvdG8gZXJyb3I7CiAJCQkJfQogCQkJCXNpemUgPSAoaW50KW1ic2VxbGVu OwpAQCAtODI4LDYgKzgzNyw3IEBACiAJCQkJCWNvbnZidWYgPSBfX3djc2NvbnYod2NwLCBwcmVj KTsKIAkJCQkJaWYgKGNvbnZidWYgPT0gTlVMTCkgewogCQkJCQkJZnAtPl9mbGFncyB8PSBfX1NF UlI7CisJCQkJCQlyZXQgPSBFT0Y7CiAJCQkJCQlnb3RvIGVycm9yOwogCQkJCQl9CiAJCQkJCWNw ID0gY29udmJ1ZjsKQEAgLTk2Miw4ICs5NzIsMTAgQEAKIAkJCS8qIGxlYWRpbmcgemVyb2VzIGZy b20gZGVjaW1hbCBwcmVjaXNpb24gKi8KIAkJCVBBRChkcHJlYyAtIHNpemUsIHplcm9lcyk7CiAJ CQlpZiAoZ3MuZ3JvdXBpbmcpIHsKLQkJCQlpZiAoZ3JvdXBpbmdfcHJpbnQoJmdzLCAmaW8sIGNw LCBidWYrQlVGLCBsb2NhbGUpIDwgMCkKKwkJCQlpZiAoZ3JvdXBpbmdfcHJpbnQoJmdzLCAmaW8s IGNwLCBidWYrQlVGLCBsb2NhbGUpIDwgMCkgeworCQkJCQlyZXQgPSBFT0Y7CiAJCQkJCWdvdG8g ZXJyb3I7CisJCQkJfQogCQkJfSBlbHNlIHsKIAkJCQlQUklOVChjcCwgc2l6ZSk7CiAJCQl9CkBA IC05NzksMTAgKzk5MSwxMSBAQAogCQkJCQlwcmVjICs9IGV4cHQ7CiAJCQkJfSBlbHNlIHsKIAkJ CQkJaWYgKGdzLmdyb3VwaW5nKSB7Ci0JCQkJCQluID0gZ3JvdXBpbmdfcHJpbnQoJmdzLCAmaW8s Ci0JCQkJCQkgICAgY3AsIGR0b2FlbmQsIGxvY2FsZSk7Ci0JCQkJCQlpZiAobiA8IDApCisJCQkJ CQlpZiAoKG4gPSBncm91cGluZ19wcmludCgmZ3MsICZpbywKKwkJCQkJCSAgICBjcCwgZHRvYWVu ZCwgbG9jYWxlKSkgPCAwKSB7CisJCQkJCQkJcmV0ID0gRU9GOwogCQkJCQkJCWdvdG8gZXJyb3I7 CisJCQkJCQl9CiAJCQkJCQljcCArPSBuOwogCQkJCQl9IGVsc2UgewogCQkJCQkJUFJJTlRBTkRQ QUQoY3AsIGR0b2FlbmQsCkBAIC0xMDI0LDggKzEwMzcsNiBAQAogI2VuZGlmCiAJaWYgKGNvbnZi dWYgIT0gTlVMTCkKIAkJZnJlZShjb252YnVmKTsKLQlpZiAoX19zZmVycm9yKGZwKSkKLQkJcmV0 ID0gRU9GOwogCWlmICgoYXJndGFibGUgIT0gTlVMTCkgJiYgKGFyZ3RhYmxlICE9IHN0YXRhcmd0 YWJsZSkpCiAJCWZyZWUgKGFyZ3RhYmxlKTsKIAlyZXR1cm4gKHJldCk7Cg== --20cf307813d4f19f8d04bcb7b558-- From owner-freebsd-standards@FreeBSD.ORG Mon Apr 2 20:10:04 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 672BA106564A for ; Mon, 2 Apr 2012 20:10:04 +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 4821E8FC16 for ; Mon, 2 Apr 2012 20:10:04 +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 q32KA4CA050122 for ; Mon, 2 Apr 2012 20:10:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q32KA4sR050121; Mon, 2 Apr 2012 20:10:04 GMT (envelope-from gnats) Date: Mon, 2 Apr 2012 20:10:04 GMT Message-Id: <201204022010.q32KA4sR050121@freefall.freebsd.org> To: freebsd-standards@FreeBSD.org From: Matthew Story 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 Reply-To: Matthew Story List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 20:10:04 -0000 The following reply was made to PR kern/164674; it has been noted by GNATS. From: Matthew Story To: freebsd-gnats-submit@freebsd.org, freebsd-standards@freebsd.org Cc: Subject: Re: kern/164674: vsprintf/vswprintf return error (EOF) on success if __SERR flag is already set on file Date: Mon, 2 Apr 2012 16:05:24 -0400 --20cf307813d4f19f8d04bcb7b558 Content-Type: multipart/alternative; boundary=20cf307813d4f19f8804bcb7b556 --20cf307813d4f19f8804bcb7b556 Content-Type: text/plain; charset=ISO-8859-1 [excerpts from other thread] On Wed, Mar 21, 2012 at 5:45 PM, David Schultz wrote: > On Mon, Mar 12, 2012, Matthew Story wrote: >> On Sun, Mar 4, 2012 at 2:03 PM, John Baldwin wrote: >> >> > My standard-parsing fu is weak. Can some other folks on this list look at >> > this PR, figure out what the correct semantics for *fprintf() in this case, >> > and evaluate the patch? Thanks. > [...] >> libc vfprintf currently behaves differently on un|buffered FILEs with >> ferror set: >> >> 1. Unbuffered FILEs >> >> -> does not transmit any bytes, and returns -1 >> >> 2. Buffered FILEs (fully buffered, or line buffered) >> >> -> transmits all bytes, and returns -1 >> >> I believe that this should be reconciled such that vfprintf (and all >> derivatives) returns sucess|failure based on transmission, not taking >> ferror state into account, but an alternate solution would be to reconcile >> the behavior of buffered FILEs with the current behavior of unbuffered >> FILEs (e.g. detect ferror state, transmit no bytes and return -1). > > I agree with this assessment. When the error indicator is set on > a stream, it means that an error has occurred at some point---not > that all subsequent operations on the stream should fail. > > There ought to be a less ugly fix than the one proposed. Probably > the PRINT macro and the various other evil macros in vfprintf() > should set ret to EOF, and the following lines in vfprintf.c should > be removed: > > if (__sferror(fp)) > ret = EOF; > > If vfprintf() is fixed so that printing to a buffered stream > always returns success after a successful write (regardless of the > prior state of the stream's error indicator), that should fix the > problem for unbuffered streams automatically. Unbuffered streams > go through __sbprintf(), which throws away the output if > vfprintf() returns -1. I've followed up on David's suggestion to remove this test and set ret = EOF prior to goto error in all relevant places. I audited all cases where __SERR could potentially be set, and determined that all cases are correctly setting __SERR, returning error in the bounding function, and properly going to error within __vf(w)printf already (I have an exhaustive list of these if anyone is curious ...). Original test program in the PR works with this patch, and the regressions for stdio all function as expected. I took the liberty of cleaning up a few return -1's, in favor of return EOF's. All in all, this is much less ugly than the previous solution. patch is against head ... -- regards, matt --20cf307813d4f19f8804bcb7b556 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [excerpts from other thread]
On Wed, Mar 21, 2012 at 5:45 PM, Davi= d Schultz <das@freebsd.org> wr= ote:
> On Mon, Mar 12, 2012, Matthew Story wrote:
&g= t;> On Sun, Mar 4, 2012 at 2:03 PM, John Baldwin <jhb@freebsd.org> wrote:
>>
>> > My standard-parsing fu is weak. =A0Ca= n some other folks on this list look at
>> > this PR, fi= gure out what the correct semantics for *fprintf() in this case,
>> > and evaluate the patch? =A0Thanks.
> [...]
=
>> libc vfprintf currently behaves differently on un|buffered FI= LEs with
>> ferror set:
>>
>&g= t; 1. Unbuffered FILEs
>>
>> =A0 =A0 =A0 -> does not transmit any by= tes, and returns -1
>>
>> 2. Buffered FILEs= (fully buffered, or line buffered)
>>
>> = =A0 =A0 =A0 -> transmits all bytes, and returns -1
>>
>> I believe that this should be reconciled s= uch that vfprintf (and all
>> derivatives) returns sucess|f= ailure based on transmission, not taking
>> ferror state in= to account, but an alternate solution would be to reconcile
>> the behavior of buffered FILEs with the current behavior of u= nbuffered
>> FILEs (e.g. detect ferror state, transmit no b= ytes and return -1).
>
> I agree with this assess= ment. =A0When the error indicator is set on
> a stream, it means that an error has occurred at some point---not=
> that all subsequent operations on the stream should fail.
>
> There ought to be a less ugly fix than the one= proposed. =A0Probably
> the PRINT macro and the various other evil macros in vfprintf()
> should set ret to EOF, and the following lines in vfprintf.c = should
> be removed:
>
> =A0 =A0 =A0= =A0if (__sferror(fp))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ret =3D EOF;
>
<= div>> If vfprintf() is fixed so that printing to a buffered stream
=
> always returns success after a successful write (regardless of th= e
> prior state of the stream's error indicator), that sho= uld fix the
> problem for unbuffered streams automatically. =A0Unbuffered strea= ms
> go through __sbprintf(), which throws away the output if<= /div>
> vfprintf() returns -1.

I've fol= lowed up on David's suggestion to remove this test and set ret =3D EOF = prior to goto error in all relevant places. =A0I audited all cases where __= SERR could potentially be set, and determined that all cases are correctly = setting __SERR, returning error in the bounding function, and properly goin= g to error within __vf(w)printf already (I have an exhaustive list of these= if anyone is curious ...). =A0

Original test program in the PR works with this patch, = and the regressions for stdio all function as expected. =A0I took the liber= ty of cleaning up a few return -1's, in favor of return EOF's. =A0<= /div>

All in all, this is much less ugly than the previous so= lution. =A0patch is against head ...

--
regards,
matt
--20cf307813d4f19f8804bcb7b556-- --20cf307813d4f19f8d04bcb7b558 Content-Type: text/plain; charset=US-ASCII; name="freebsd.PR164674-better.patch.txt" Content-Disposition: attachment; filename="freebsd.PR164674-better.patch.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h0jy3ng60 SW5kZXg6IGxpYi9saWJjL3N0ZGlvL3Zmd3ByaW50Zi5jCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpYi9saWJj L3N0ZGlvL3Zmd3ByaW50Zi5jCShyZXZpc2lvbiAyMzM3ODApCisrKyBsaWIvbGliYy9zdGRpby92 ZndwcmludGYuYwkod29ya2luZyBjb3B5KQpAQCAtNDQ5LDIwICs0NDksMjggQEAKIAogCS8qIEJF V0FSRSwgdGhlc2UgYGdvdG8gZXJyb3InIG9uIGVycm9yLiAqLwogI2RlZmluZQlQUklOVChwdHIs IGxlbikJZG8gewkJCVwKLQlpZiAoaW9fcHJpbnQoJmlvLCAocHRyKSwgKGxlbiksIGxvY2FsZSkp CVwKLQkJZ290byBlcnJvcjsgXAorCWlmIChpb19wcmludCgmaW8sIChwdHIpLCAobGVuKSwgbG9j YWxlKSkgewlcCisJCXJldCA9IEVPRjsJXAorCQlnb3RvIGVycm9yOwlcCisJfQlcCiB9IHdoaWxl ICgwKQogI2RlZmluZQlQQUQoaG93bWFueSwgd2l0aCkgeyBcCi0JaWYgKGlvX3BhZCgmaW8sICho b3dtYW55KSwgKHdpdGgpLCBsb2NhbGUpKSBcCi0JCWdvdG8gZXJyb3I7IFwKKwlpZiAoaW9fcGFk KCZpbywgKGhvd21hbnkpLCAod2l0aCksIGxvY2FsZSkpIHsJXAorCQlyZXQgPSBFT0Y7CVwKKwkJ Z290byBlcnJvcjsJXAorCX0JXAogfQogI2RlZmluZQlQUklOVEFORFBBRChwLCBlcCwgbGVuLCB3 aXRoKSB7CVwKLQlpZiAoaW9fcHJpbnRhbmRwYWQoJmlvLCAocCksIChlcCksIChsZW4pLCAod2l0 aCksIGxvY2FsZSkpIFwKLQkJZ290byBlcnJvcjsgXAorCWlmIChpb19wcmludGFuZHBhZCgmaW8s IChwKSwgKGVwKSwgKGxlbiksICh3aXRoKSwgbG9jYWxlKSkgewlcCisJCXJldCA9IEVPRjsJXAor CQlnb3RvIGVycm9yOwlcCisJfQlcCiB9CiAjZGVmaW5lCUZMVVNIKCkgeyBcCi0JaWYgKGlvX2Zs dXNoKCZpbywgbG9jYWxlKSkgXAotCQlnb3RvIGVycm9yOyBcCisJaWYgKGlvX2ZsdXNoKCZpbywg bG9jYWxlKSkgewlcCisJCXJldCA9IEVPRjsJXAorCQlnb3RvIGVycm9yOwlcCisJfQlcCiB9CiAK IAkvKgpAQCAtODk3LDYgKzkwNSw3IEBACiAJCQkJCWNvbnZidWYgPSBfX21ic2NvbnYobWJwLCBw cmVjKTsKIAkJCQkJaWYgKGNvbnZidWYgPT0gTlVMTCkgewogCQkJCQkJZnAtPl9mbGFncyB8PSBf X1NFUlI7CisJCQkJCQlyZXQgPSBFT0Y7CiAJCQkJCQlnb3RvIGVycm9yOwogCQkJCQl9CiAJCQkJ CWNwID0gY29udmJ1ZjsKQEAgLTEwMzAsOCArMTAzOSwxMCBAQAogCQkJLyogbGVhZGluZyB6ZXJv ZXMgZnJvbSBkZWNpbWFsIHByZWNpc2lvbiAqLwogCQkJUEFEKGRwcmVjIC0gc2l6ZSwgemVyb2Vz KTsKIAkJCWlmIChncy5ncm91cGluZykgewotCQkJCWlmIChncm91cGluZ19wcmludCgmZ3MsICZp bywgY3AsIGJ1ZitCVUYsIGxvY2FsZSkgPCAwKQorCQkJCWlmIChncm91cGluZ19wcmludCgmZ3Ms ICZpbywgY3AsIGJ1ZitCVUYsIGxvY2FsZSkgPCAwKSB7CisJCQkJCXJldCA9IEVPRjsKIAkJCQkJ Z290byBlcnJvcjsKKwkJCQl9CiAJCQl9IGVsc2UgewogCQkJCVBSSU5UKGNwLCBzaXplKTsKIAkJ CX0KQEAgLTEwNDcsMTAgKzEwNTgsMTEgQEAKIAkJCQkJcHJlYyArPSBleHB0OwogCQkJCX0gZWxz ZSB7CiAJCQkJCWlmIChncy5ncm91cGluZykgewotCQkJCQkJbiA9IGdyb3VwaW5nX3ByaW50KCZn cywgJmlvLAotCQkJCQkJICAgIGNwLCBjb252YnVmICsgbmRpZywgbG9jYWxlKTsKLQkJCQkJCWlm IChuIDwgMCkKKwkJCQkJCWlmICgobiA9IGdyb3VwaW5nX3ByaW50KCZncywgJmlvLAorCQkJCQkJ ICAgIGNwLCBjb252YnVmICsgbmRpZywgbG9jYWxlKSkgPCAwKSB7CisJCQkJCQkJcmV0ID0gRU9G OwogCQkJCQkJCWdvdG8gZXJyb3I7CisJCQkJCQl9CiAJCQkJCQljcCArPSBuOwogCQkJCQl9IGVs c2UgewogCQkJCQkJUFJJTlRBTkRQQUQoY3AsIGNvbnZidWYgKyBuZGlnLApAQCAtMTA4OSw4ICsx MTAxLDYgQEAKIAl2YV9lbmQob3JnYXApOwogCWlmIChjb252YnVmICE9IE5VTEwpCiAJCWZyZWUo Y29udmJ1Zik7Ci0JaWYgKF9fc2ZlcnJvcihmcCkpCi0JCXJldCA9IEVPRjsKIAlpZiAoKGFyZ3Rh YmxlICE9IE5VTEwpICYmIChhcmd0YWJsZSAhPSBzdGF0YXJndGFibGUpKQogCQlmcmVlIChhcmd0 YWJsZSk7CiAJcmV0dXJuIChyZXQpOwpJbmRleDogbGliL2xpYmMvc3RkaW8vdmZwcmludGYuYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBsaWIvbGliYy9zdGRpby92ZnByaW50Zi5jCShyZXZpc2lvbiAyMzM3ODAp CisrKyBsaWIvbGliYy9zdGRpby92ZnByaW50Zi5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMjcsNyAr MTI3LDcgQEAKIAljb25zdCBDSEFSICpjcDAgPSBjcDsKIAogCWlmIChpb19wcmludGFuZHBhZChp b3AsIGNwLCBlcCwgZ3MtPmxlYWQsIHplcm9lcywgbG9jYWxlKSkKLQkJcmV0dXJuICgtMSk7CisJ CXJldHVybiAoRU9GKTsKIAljcCArPSBncy0+bGVhZDsKIAl3aGlsZSAoZ3MtPm5zZXBzID4gMCB8 fCBncy0+bnJlcGVhdHMgPiAwKSB7CiAJCWlmIChncy0+bnJlcGVhdHMgPiAwKQpAQCAtMTM3LDkg KzEzNyw5IEBACiAJCQlncy0+bnNlcHMtLTsKIAkJfQogCQlpZiAoaW9fcHJpbnQoaW9wLCBncy0+ dGhvdXNhbmRzX3NlcCwgZ3MtPnRob3VzZXBfbGVuLCBsb2NhbGUpKQotCQkJcmV0dXJuICgtMSk7 CisJCQlyZXR1cm4gKEVPRik7CiAJCWlmIChpb19wcmludGFuZHBhZChpb3AsIGNwLCBlcCwgKmdz LT5ncm91cGluZywgemVyb2VzLCBsb2NhbGUpKQotCQkJcmV0dXJuICgtMSk7CisJCQlyZXR1cm4g KEVPRik7CiAJCWNwICs9ICpncy0+Z3JvdXBpbmc7CiAJfQogCWlmIChjcCA+IGVwKQpAQCAtMzY5 LDIwICszNjksMjggQEAKIAogCS8qIEJFV0FSRSwgdGhlc2UgYGdvdG8gZXJyb3InIG9uIGVycm9y LiAqLwogI2RlZmluZQlQUklOVChwdHIsIGxlbikgeyBcCi0JaWYgKGlvX3ByaW50KCZpbywgKHB0 ciksIChsZW4pLCBsb2NhbGUpKQlcCi0JCWdvdG8gZXJyb3I7IFwKKwlpZiAoaW9fcHJpbnQoJmlv LCAocHRyKSwgKGxlbiksIGxvY2FsZSkpIHsJXAorCQlyZXQgPSBFT0Y7CVwKKwkJZ290byBlcnJv cjsJXAorCX0JXAogfQogI2RlZmluZQlQQUQoaG93bWFueSwgd2l0aCkgeyBcCi0JaWYgKGlvX3Bh ZCgmaW8sIChob3dtYW55KSwgKHdpdGgpLCBsb2NhbGUpKSBcCisJaWYgKGlvX3BhZCgmaW8sICho b3dtYW55KSwgKHdpdGgpLCBsb2NhbGUpKSB7CVwKKwkJcmV0ID0gRU9GOwlcCiAJCWdvdG8gZXJy b3I7IFwKKwl9CVwKIH0KICNkZWZpbmUJUFJJTlRBTkRQQUQocCwgZXAsIGxlbiwgd2l0aCkgewlc Ci0JaWYgKGlvX3ByaW50YW5kcGFkKCZpbywgKHApLCAoZXApLCAobGVuKSwgKHdpdGgpLCBsb2Nh bGUpKSBcCi0JCWdvdG8gZXJyb3I7IFwKKwlpZiAoaW9fcHJpbnRhbmRwYWQoJmlvLCAocCksIChl cCksIChsZW4pLCAod2l0aCksIGxvY2FsZSkpIHsJXAorCQlyZXQgPSBFT0Y7CVwKKwkJZ290byBl cnJvcjsJXAorCX0JXAogfQogI2RlZmluZQlGTFVTSCgpIHsgXAotCWlmIChpb19mbHVzaCgmaW8s IGxvY2FsZSkpIFwKKwlpZiAoaW9fZmx1c2goJmlvLCBsb2NhbGUpKSB7CVwKKwkJcmV0ID0gRU9G OwlcCiAJCWdvdG8gZXJyb3I7IFwKKwl9CVwKIH0KIAogCS8qCkBAIC02MTcsNiArNjI1LDcgQEAK IAkJCQkgICAgKHdjaGFyX3QpR0VUQVJHKHdpbnRfdCksICZtYnMpOwogCQkJCWlmIChtYnNlcWxl biA9PSAoc2l6ZV90KS0xKSB7CiAJCQkJCWZwLT5fZmxhZ3MgfD0gX19TRVJSOworCQkJCQlyZXQg PSBFT0Y7CiAJCQkJCWdvdG8gZXJyb3I7CiAJCQkJfQogCQkJCXNpemUgPSAoaW50KW1ic2VxbGVu OwpAQCAtODI4LDYgKzgzNyw3IEBACiAJCQkJCWNvbnZidWYgPSBfX3djc2NvbnYod2NwLCBwcmVj KTsKIAkJCQkJaWYgKGNvbnZidWYgPT0gTlVMTCkgewogCQkJCQkJZnAtPl9mbGFncyB8PSBfX1NF UlI7CisJCQkJCQlyZXQgPSBFT0Y7CiAJCQkJCQlnb3RvIGVycm9yOwogCQkJCQl9CiAJCQkJCWNw ID0gY29udmJ1ZjsKQEAgLTk2Miw4ICs5NzIsMTAgQEAKIAkJCS8qIGxlYWRpbmcgemVyb2VzIGZy b20gZGVjaW1hbCBwcmVjaXNpb24gKi8KIAkJCVBBRChkcHJlYyAtIHNpemUsIHplcm9lcyk7CiAJ CQlpZiAoZ3MuZ3JvdXBpbmcpIHsKLQkJCQlpZiAoZ3JvdXBpbmdfcHJpbnQoJmdzLCAmaW8sIGNw LCBidWYrQlVGLCBsb2NhbGUpIDwgMCkKKwkJCQlpZiAoZ3JvdXBpbmdfcHJpbnQoJmdzLCAmaW8s IGNwLCBidWYrQlVGLCBsb2NhbGUpIDwgMCkgeworCQkJCQlyZXQgPSBFT0Y7CiAJCQkJCWdvdG8g ZXJyb3I7CisJCQkJfQogCQkJfSBlbHNlIHsKIAkJCQlQUklOVChjcCwgc2l6ZSk7CiAJCQl9CkBA IC05NzksMTAgKzk5MSwxMSBAQAogCQkJCQlwcmVjICs9IGV4cHQ7CiAJCQkJfSBlbHNlIHsKIAkJ CQkJaWYgKGdzLmdyb3VwaW5nKSB7Ci0JCQkJCQluID0gZ3JvdXBpbmdfcHJpbnQoJmdzLCAmaW8s Ci0JCQkJCQkgICAgY3AsIGR0b2FlbmQsIGxvY2FsZSk7Ci0JCQkJCQlpZiAobiA8IDApCisJCQkJ CQlpZiAoKG4gPSBncm91cGluZ19wcmludCgmZ3MsICZpbywKKwkJCQkJCSAgICBjcCwgZHRvYWVu ZCwgbG9jYWxlKSkgPCAwKSB7CisJCQkJCQkJcmV0ID0gRU9GOwogCQkJCQkJCWdvdG8gZXJyb3I7 CisJCQkJCQl9CiAJCQkJCQljcCArPSBuOwogCQkJCQl9IGVsc2UgewogCQkJCQkJUFJJTlRBTkRQ QUQoY3AsIGR0b2FlbmQsCkBAIC0xMDI0LDggKzEwMzcsNiBAQAogI2VuZGlmCiAJaWYgKGNvbnZi dWYgIT0gTlVMTCkKIAkJZnJlZShjb252YnVmKTsKLQlpZiAoX19zZmVycm9yKGZwKSkKLQkJcmV0 ID0gRU9GOwogCWlmICgoYXJndGFibGUgIT0gTlVMTCkgJiYgKGFyZ3RhYmxlICE9IHN0YXRhcmd0 YWJsZSkpCiAJCWZyZWUgKGFyZ3RhYmxlKTsKIAlyZXR1cm4gKHJldCk7Cg== --20cf307813d4f19f8d04bcb7b558-- From owner-freebsd-standards@FreeBSD.ORG Sat Apr 7 03:39:42 2012 Return-Path: Delivered-To: freebsd-standards@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2B79106564A; Sat, 7 Apr 2012 03:39:42 +0000 (UTC) (envelope-from das@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 94CB28FC0C; Sat, 7 Apr 2012 03:39:42 +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 q373dgVn045355; Sat, 7 Apr 2012 03:39:42 GMT (envelope-from das@freefall.freebsd.org) Received: (from das@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q373dglX045351; Sat, 7 Apr 2012 03:39:42 GMT (envelope-from das) Date: Sat, 7 Apr 2012 03:39:42 GMT Message-Id: <201204070339.q373dglX045351@freefall.freebsd.org> To: das@FreeBSD.org, freebsd-standards@FreeBSD.org, das@FreeBSD.org From: das@FreeBSD.org Cc: Subject: Re: standards/166463: remquo[f] may return wrong sign in quo part and incorrect rem part on denormals 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: Sat, 07 Apr 2012 03:39:42 -0000 Synopsis: remquo[f] may return wrong sign in quo part and incorrect rem part on denormals Responsible-Changed-From-To: freebsd-standards->das Responsible-Changed-By: das Responsible-Changed-When: Sat Apr 7 03:38:23 UTC 2012 Responsible-Changed-Why: This looks like the right fix. I will look into it. http://www.freebsd.org/cgi/query-pr.cgi?pr=166463