From owner-freebsd-standards Sun Dec 2 2:21:38 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id DFB1337B416 for ; Sun, 2 Dec 2001 02:21:33 -0800 (PST) Received: from straylight.ringlet.net (roam@discworld.nanolink.com [217.75.135.248]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with SMTP id fB2ALUG53986 for ; Sun, 2 Dec 2001 05:21:31 -0500 (EST) (envelope-from roam@ringlet.net) Received: (qmail 2318 invoked by uid 1000); 2 Dec 2001 10:20:38 -0000 Date: Sun, 2 Dec 2001 12:20:37 +0200 From: Peter Pentchev To: Garance A Drosihn Cc: Bruce Evans , Wes Peters , Bill Fenner , mike@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation Message-ID: <20011202122036.C523@straylight.oblivion.bg> References: <20011202011045.F5026-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from drosih@rpi.edu on Sat, Dec 01, 2001 at 11:47:52PM -0500 Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Dec 01, 2001 at 11:47:52PM -0500, Garance A Drosihn wrote: > At 1:52 AM +1100 12/2/01, Bruce Evans wrote: > > > > > The last change is a whitespace error. Mustn't have any style(9) > > > > > nits, right? ;^) > > > > > > > > I agree, so about 10 more of them in strerror() alone ;^). They > > > > were in the following classes: > > > > (1) missing parens around return values > >> > >> style(9) remains silent on this subject. Until required to do so by > > > >It is not silent, but not very verbose. All of the examples of returning > >a value in style(9) use "return (foo)". There is a whole one such example. > >It apparently didn't occur to the origianal author of style(9) that this > >needed an explicit rule. > > In the argumentative half of my message (this here message...), I will note > that style(9) also says that parenthesis should not be added unless they are > necessary, and previous discussions have indicated that parentheses are not > in fact necessary in C on return statements... The more I have thought > about this, the more I have felt that it is better to NOT use parentheses > on 'return' statements, as that makes it absolutely clear that the return > statement is not a function call. And, when there are no parentheses, then > it is much easier to remember to put a blank between 'return' and the value > being returned ... :-) > I personally have found parentheses on return statements very useful for debugging, should return be redefined as a macro. Something like: #ifdef EBUG #define return(r) return errreturn(r) rs_err_t errreturn(rs_err_t r) { if ((x == RS_ERR_NONE) || (x == RS_ERR_BACKOFF)) return r; rs_prerror("ERR", r); abort(); } #endif ..which provides me with nice tracebacks in addition to the error message at the first point an error is encountered. G'luck, Peter -- What would this sentence be like if it weren't self-referential? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Dec 2 6:14:18 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 2961E37B416 for ; Sun, 2 Dec 2001 06:14:13 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB2EEAG55792 for ; Sun, 2 Dec 2001 09:14:11 -0500 (EST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id BAA22252; Mon, 3 Dec 2001 01:13:49 +1100 Date: Mon, 3 Dec 2001 01:14:04 +1100 (EST) From: Bruce Evans X-X-Sender: To: Garance A Drosihn Cc: Wes Peters , Bill Fenner , , Subject: Re: strerror_r() implementation In-Reply-To: Message-ID: <20011203005459.N8502-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 1 Dec 2001, Garance A Drosihn wrote: > At 1:52 AM +1100 12/2/01, Bruce Evans wrote: > > > > (1) missing parens around return values > >> > >> style(9) remains silent on this subject. Until required to do so by > > > >It is not silent, but not very verbose. All of the examples of returning > >a value in style(9) use "return (foo)". There is a whole one such example. > >It apparently didn't occur to the origianal author of style(9) that this > >needed an explicit rule. > > In the argumentative half of my message (this here message...), I will note > that style(9) also says that parenthesis should not be added unless they are > necessary, and previous discussions have indicated that parentheses are not > in fact necessary in C on return statements... The more I have thought Individual rules have precedence over general ones. > >I tested it a bit more and found a bug in the test code: the test of a > >short buffer returns an unterminated string (as expected), and printing > >this non-string using %s gives garbage. > > Hmm. I do not have the standards document for strerror_r(), but I am > surprised that a short buffer is expected to return a string which is > not null-terminated. Note that I am not arguing the point, I'm just > surprised. That means all callers to strerror_r() should never treat > the result as a null-terminated string, even though it usually will > be null-terminated. Seems to me that is asking for trouble. I think the contents of the buffer is indeterminate when strerror_r() fails. POSIX-1.200x-draft7 is not completely clear on this. strerror_r() is also permitted to fail if the error number is invalid. It must then return EINVAL. So the conversion to ASCII is not needed for strerror_r(), and it may be considered a bug that strerror_r() doesn't fail for bogus error numbers. However, the conversion is needed for strerror(). Here is my current version of the cleanups for strerror(). New changes: - don't resever bogus extra space for UPREFIX in ebuf[]. - fix breakage of reentrancy of strerror_r() in previous verions (tmp[] must be auto). %%% Index: strerror.c =================================================================== RCS file: /home/ncvs/src/lib/libc/string/strerror.c,v retrieving revision 1.5 diff -u -2 -r1.5 strerror.c --- strerror.c 27 Nov 2001 07:39:46 -0000 1.5 +++ strerror.c 1 Dec 2001 23:26:14 -0000 @@ -42,4 +42,5 @@ #include +#define EBUFSIZE 40 /* enough for 64-bit number + slop */ int @@ -49,5 +50,5 @@ unsigned int uerr; char *p, *t; - char tmp[40]; /* 64-bit number + slop */ + char tmp[EBUFSIZE]; int len; @@ -84,30 +85,15 @@ } - -/* - * NOTE: the following length should be enough to hold the longest defined - * error message in sys_errlist, defined in ../gen/errlst.c. This is a WAG - * that is better than the previous value. - */ -#define ERR_LEN 64 - char * strerror(num) int num; { - unsigned int uerr; - static char ebuf[ERR_LEN]; + static char ebuf[EBUFSIZE]; - uerr = num; /* convert to unsigned */ - if (uerr < sys_nerr) - return (char *)sys_errlist[uerr]; - - /* strerror can't fail so handle truncation semi-elegantly */ - if (strerror_r(num, ebuf, (size_t) ERR_LEN) != 0) - ebuf[ERR_LEN - 1] = '\0'; - - return ebuf; + if (num >= 0 && num < sys_nerr) + return ((char *)sys_errlist[num]); + (void)strerror_r(num, ebuf, sizeof(ebuf)); + return (ebuf); } - #ifdef STANDALONE_TEST %%% To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Dec 2 7:53:49 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 5162B37B416 for ; Sun, 2 Dec 2001 07:53:47 -0800 (PST) Received: from rover.village.org (warner@rover.bsdimp.com [204.144.255.66]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB2FrhG56788 for ; Sun, 2 Dec 2001 10:53:46 -0500 (EST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id fB2Frfa34614; Sun, 2 Dec 2001 08:53:42 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost [127.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id fB2FrfM58746; Sun, 2 Dec 2001 08:53:41 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200112021553.fB2FrfM58746@harmony.village.org> To: Garance A Drosihn Subject: Re: strerror_r() implementation Cc: freebsd-standards@bostonradio.org In-reply-to: Your message of "Sat, 01 Dec 2001 23:47:52 EST." References: <20011202011045.F5026-100000@gamplex.bde.org> Date: Sun, 02 Dec 2001 08:53:41 -0700 From: Warner Losh Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spoke style(9): return (eight); This matches usage in the kernel and libc :-) Most of style(9) is in the examples. While not strictly necessary, many people believe that it looks better. Many don't, but current FreeBSD usage says that it is required. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Dec 2 19:12:25 2001 Delivered-To: freebsd-standards@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id CAC8D37B41E for ; Sun, 2 Dec 2001 19:12:21 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB33CEU175700; Sun, 2 Dec 2001 22:12:18 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20011203005459.N8502-100000@gamplex.bde.org> References: <20011203005459.N8502-100000@gamplex.bde.org> Date: Sun, 2 Dec 2001 22:12:13 -0500 To: Bruce Evans From: Garance A Drosihn Subject: Re: strerror_r() implementation Cc: standards@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 1:14 AM +1100 12/3/01, Bruce Evans wrote: >On Sat, 1 Dec 2001, Garance A Drosihn wrote: > > Hmm. I do not have the standards document for strerror_r(), but I am >> surprised that a short buffer is expected to return a string which is >> not null-terminated. Note that I am not arguing the point, I'm just >> surprised. That means all callers to strerror_r() should never treat >> the result as a null-terminated string, even though it usually will >> be null-terminated. Seems to me that is asking for trouble. > >I think the contents of the buffer is indeterminate when strerror_r() >fails. POSIX-1.200x-draft7 is not completely clear on this. Hmm. Should we bug someone to make that more explicit, at least for the case of a truncated message? I just have this fear that some OS's will implement truncated messages to always include the terminating null, and others will prefer to put one extra byte of the error msg into the buffer. Programs written on the OS which chooses the first behavior might then run into trouble on the second group of OS's. I don't mind too much which is chosen, but it seems to me it would be safer to have the behavior stated explicitly in the standard. Well, I guess I should admit that would prefer that the msg was always terminated with a null, but I wouldn't mind if the standard explicitly stated that a truncated message will not include a null. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Dec 2 20:37:57 2001 Delivered-To: freebsd-standards@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id 2F28D37B416 for ; Sun, 2 Dec 2001 20:37:49 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id fB34aQv53595; Sun, 2 Dec 2001 23:36:26 -0500 (EST) (envelope-from mike) Date: Sun, 2 Dec 2001 23:36:26 -0500 From: Mike Barcroft To: Garance A Drosihn Cc: Bruce Evans , standards@FreeBSD.ORG Subject: Re: strerror_r() implementation Message-ID: <20011202233626.A52804@espresso.q9media.com> References: <20011203005459.N8502-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from drosih@rpi.edu on Sun, Dec 02, 2001 at 10:12:13PM -0500 Organization: The FreeBSD Project Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn writes: > Hmm. Should we bug someone to make that more explicit, at least for > the case of a truncated message? I just have this fear that some OS's > will implement truncated messages to always include the terminating > null, and others will prefer to put one extra byte of the error msg > into the buffer. Programs written on the OS which chooses the first > behavior might then run into trouble on the second group of OS's. Properly written applications will check the return value. It's not our job to hold the application writter's hand. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon Dec 3 22: 9:20 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id C0BE837B41A for ; Mon, 3 Dec 2001 22:09:07 -0800 (PST) Received: from softweyr.com (4ca48dfbdab208736284f35a566d51d6@softweyr.com [65.88.244.127]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB4696G78655 for ; Tue, 4 Dec 2001 01:09:06 -0500 (EST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 16B9Qc-000CrS-00; Mon, 03 Dec 2001 23:51:42 -0700 Message-ID: <3C0C77B8.26C050B0@softweyr.com> Date: Tue, 04 Dec 2001 00:14:00 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Bill Fenner , mike@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation References: <20011202011045.F5026-100000@gamplex.bde.org> Content-Type: multipart/mixed; boundary="------------4F6730CC3992A54C281FAB7D" Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------4F6730CC3992A54C281FAB7D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce Evans wrote: > > On Sat, 1 Dec 2001, Wes Peters wrote: > > > Bruce Evans wrote: > > > > > > I prefer the version enclosed at the end. It has the following additional > > > non-formatting changes: > > > - parametrize the buffer size according to the sizes in strerror_r() > > > > ...but do it in a way that doesn't break the function. > > I've tested it a bit and have only found one cosmetic bug, an old one: > the prefix for strerror(0) is "Undefined error: " (from sys_errlist[0]), > but the prefix for other unusual errors is "Unknown error: " (from the > function). You BROKE strerror_r. You took an auto temporary character buffer and converted it into a static. Please report to us what will happen when the currently executing thread is interrupted in the middle of the loop that writes into this static buffer by another call to strerror_r. I am certainly not impressed by this incredibly basic error. > One more cosmetic bug turned up in this thread, a not so old one: adding > the length of the prefix to the size of the temporary buffer is bogus. > > > > - unobfuscate uerr (don't use an unsigned variable just to hand-optimize > > > for 20-year-old compilers). > > > > When did "don't change code that is known to work" get thrown out? > > uerr is used because the simplistic ASCII conversion doesn't really > > grok signedness. It does do quite a nice job in very little code. > > When it's badly written. uerr is used in strerror() because it was > copied from strerror_r(). uerr is used in strerror because it remains from the prior implementation. > strerror() doesn't do any integer to string > conversions, so using uerr in it is just an obfuscation. But it does do range checking; I suppose 0 < errnum < sys_nerr would be more clear. > > > - remove redundant code (the strerror_r() can't fail unless we used the > > > wrong buffer size, and we should get this right by not hard-coding the > > > size of tmp[]) > > > `tmp' should have a better name now that it is more global. I didn't > > > change it because that would require large changes in strerror_r(). > > > > It's a throw-away character buffer and making it more global is an error. > > Either it or its size needs to be more global so that knowledge of its > size doesn't need to be hard-coded into strerror(). > > > > > The last change is a whitespace error. Mustn't have any style(9) nits, > > > > right? ;^) > > > > > > I agree, so about 10 more of them in strerror() alone ;^). They were in > > > the following classes: > > > (1) missing parens around return values > > > > style(9) remains silent on this subject. Until required to do so by > > It is not silent, but not very verbose. All of the examples of returning > a value in style(9) use "return (foo)". There is a whole one such example. > It apparently didn't occur to the origianal author of style(9) that this > needed an explicit rule. > > > style(9) I will not submit to this barbarism. A quick check of other > > routines in libc/string showed about 50% usage of return (foo) vs. > > return foo. > > libc/string might not be a good example. The best examples are: > sys/kern (CSRG version), libc/stdio (CSRG version), and contrib/vi > for a slightly more modern version, or even the CSRG version of > libc/string. The opposite of my statement above applies as well. Should you update style(9) to more explicity require this, I will examine all of my code in the system tree and apply parenthesis around return values. This is an opportunity to make style(9) much more succint. I find it unfortunate that developers new to FreeBSD are so often clubbed with this vague document; it is truly impossible to find general agreement on what "KNF" really is. So I'll let you update the document to truly reflect what you think it means, take the inevitable flames and bickering, and turn it into a working document, since it seems to be your passion. As long as the definition of what "KNF" really means is "whatever BDE says it means" everyone will continue to commit whatever slop they like and then wait for your judgement. This is a rather silly bottleneck to impose on the entire development team. > > > (2) comments not English sentences > > > > Mine were. Existing ones often were not. > > Except for: > > /* strerror can't fail so handle truncation semi-elegantly */ That *is* a complete English sentence if you add a period at the end. I did. See attached. > > > (3) excessive vertical whitespace (KNF uses indent -sob) > > > > This would be much more understandable if style(9) spelled out what is > > "acceptable" or "required" vertical whitespace. As it currently stands, > > there is no mention of the word "vertical" anywhere, and no mention of > > "blank line" after the description of include files. Again, existing > > usage in the libc/string directory is all over the map, and style(9) > > is completely opaque on the subject. > > You have to look at some KNF code. The old version of strerror.c is a > good enough example here. It uses doesn't use any blank lines except > before the block of code begun by a comment. This was intentional. The "indent -sob" was all the hint needed. So why don't we put this in the style(9) man page instead of having me learn about it after a non- conforming commit and negative review? You, Bruce, are the accepted authority on this, let's take your accumulated knowlege and document it rather than relying in you reviewing every commit to /src. If nothing else, it might at least cut down on the amount of negative feedback you have to give. > > > (4) excessive indentation for comments at the right of code (32 is normal). > > > > The only mention of right-comments in style(9) simply says "Try to align > > the comments". > > > > style(9) would be much easier to adhere to if it were actually documented > > in style(9), rather than being the unagreed-upon figment of the imagination > > of several dozen different people. > > It might be simpler to fix indent(1) and filter commits through it. Documenting the options to indent(1) that most closely produces style(9) compliant code would certainly be a starting point. I think you could easily make the point that FreeBSD's indent should default to style(9) settings as well, or at least support a flag that does so. > > > %%% > > > Index: strerror.c > > > ... > > > This has not been tested. > > > > Please clarify this comment? > > "I rebuilt libc to check that this compiles, but have not installed libc > or done any runtime tests". But *I* have. I grepped the system sources for something that uses strerror and contrived a simple test to verify libc.so worked correctly. The test is quite simple: strip a non-existant file, as in strip /foo/bar. I would like to have a place to document this, but neither the source nor the commit message seems appropriate. This seems appropriate for the "standards" group to discuss; where should we document regression tests and/or standards compliance tests? In or near the source tree would be an ideal location, I think. Test cases developers can use to prove their work would be a great addition. > I tested it a bit more and found a bug in the test code: the test of a > short buffer returns an unterminated string (as expected), and printing > this non-string using %s gives garbage. The latest iteration of this pre-fills the buffer with a known character to demonstrate that the string does not get terminated. More tests are always welcome. Please note that the lack of an end-to-end and system integration test does not invalidate a unit test. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ --------------4F6730CC3992A54C281FAB7D Content-Type: text/plain; charset=us-ascii; name="strerror.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="strerror.c" /* * Copyright (c) 1988, 1993 The Regents of the University of California. All * rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are * met: 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. 2. * Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. 3. All advertising * materials mentioning features or use of this software must display the * following acknowledgement: This product includes software developed by the * University of California, Berkeley and its contributors. 4. Neither the * name of the University nor the names of its contributors may be used to * endorse or promote products derived from this software without specific * prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #if defined(LIBC_SCCS) && !defined(lint) static char sccsid[] = "@(#)strerror.c 8.1 (Berkeley) 6/4/93"; #endif /* LIBC_SCCS and not lint */ #ifndef lint static const char rcsid[] = "$FreeBSD: src/lib/libc/string/strerror.c,v 1.2.14.1 2001/07/09 23:30:06 obrien Exp $"; #endif #include #include #include static char const * unknown_prefix = "Unknown error: "; /* * Define a buffer size big enough to describe a 64-bit number in ASCII * decimal, with optional leading sign and trailing NUL. */ #define NUMSTRINGLEN 22 int strerror_r(int errnum, char *strerrbuf, size_t buflen) { unsigned int uerr; char *p, *t; char tmp[NUMSTRINGLEN]; int len; uerr = errnum; if (uerr < sys_nerr) { len = strlcpy(strerrbuf, (char *)sys_errlist[uerr], buflen); return (len <= buflen) ? 0 : ERANGE; } /* * Print unknown errno by hand so we don't link to stdio(3). This * collects the ASCII digits in reverse order. */ t = tmp; if (errnum < 0) uerr = -uerr; do { *t++ = "0123456789"[uerr % 10]; } while (uerr /= 10); if (errnum < 0) *t++ = '-'; /* * Copy the "unkown" message and the number into the caller supplied * buffer, inverting the number string. */ strlcpy(strerrbuf, unknown_prefix, buflen); for (p = strerrbuf + sizeof(unknown_prefix) - 1; p < strerrbuf + buflen; ) { *p++ = *--t; if (t <= tmp) break; } if (p < strerrbuf + buflen) { *p = '\0'; return 0; } /* * We ran out of space in strerrbuf. */ return ERANGE; } char * strerror(num) int num; { static char ebuf[sizeof unknown_prefix + NUMSTRINGLEN]; if ((num > 0) && (num < sys_nerr)) return (char *)sys_errlist[num]; /* * strerror must not fail so handle truncation semi-elegantly. */ if (strerror_r(num, ebuf, sizeof ebuf) != 0) ebuf[sizeof ebuf - 1] = '\0'; return ebuf; } #ifdef STANDALONE_TEST main() { char mybuf[64]; int ret; printf("strerror(47) yeilds: %s\n", strerror(47)); strerror_r(11, mybuf, 64); printf("strerror_r(11) yeilds: %s\n", mybuf); strerror_r(1234, mybuf, 64); printf("strerror_r(1234) yeilds: %s\n", mybuf); memset(mybuf, '*', 63); ret = strerror_r(4321, mybuf, 16); printf("strerror_r on short buffer returns %d (%s)\n", ret, mybuf); } #endif --------------4F6730CC3992A54C281FAB7D-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Mon Dec 3 22:10: 5 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 5902F37B416 for ; Mon, 3 Dec 2001 22:10:01 -0800 (PST) Received: from softweyr.com (f30268a7e555877e287b4a0829e4d5cb@softweyr.com [65.88.244.127]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB46A0G78663 for ; Tue, 4 Dec 2001 01:10:00 -0500 (EST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 16B9Rr-000CrV-00; Mon, 03 Dec 2001 23:52:59 -0700 Message-ID: <3C0C7815.43A3C576@softweyr.com> Date: Tue, 04 Dec 2001 00:15:33 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Mike Barcroft Cc: Bill Fenner , freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation References: <20011125014216.A84711@espresso.q9media.com> <3C00A43B.9929E9C7@softweyr.com> <200111281854.KAA13574@windsor.research.att.com> <3C05BE3A.1DF1A539@softweyr.com> <200111300454.UAA06333@windsor.research.att.com> <20011130001910.C23064@espresso.q9media.com> <3C0882A9.EF07073@softweyr.com> <20011201033530.A35631@espresso.q9media.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Mike Barcroft wrote: > > Wes Peters writes: > > Room for the 40 characters for the number + 13 characters of message > > plus a trailing null plus 1 byte in case somebody miscounted? Is > > anyone here actually reading the freaking CODE? > > Assuming the number is a 64-bit signed integer the maximum number of > characters that is would require is 19. The string "Unknown error: " > takes up 15 characters and 1 character for the terminating NUL. > > 19 + 15 + 1 = 35 > > Did I miss something? Yeah, the 40 was left over from the previous implementation. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Dec 4 1:10:56 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 6F64337B419 for ; Tue, 4 Dec 2001 01:10:53 -0800 (PST) Received: from a96180.upc-a.chello.nl (postfix@a96180.upc-a.chello.nl [62.163.96.180]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB49ApG80699 for ; Tue, 4 Dec 2001 04:10:52 -0500 (EST) (envelope-from asmodai@malbolge.dnsalias.net) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id B125C2150; Tue, 4 Dec 2001 10:10:50 +0100 (CET) Date: Tue, 4 Dec 2001 10:10:50 +0100 From: Jeroen Ruigrok/Asmodai To: Wes Peters Cc: freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation Message-ID: <20011204101050.M6664@daemon.ninth-circle.org> References: <20011202011045.F5026-100000@gamplex.bde.org> <3C0C77B8.26C050B0@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C0C77B8.26C050B0@softweyr.com> User-Agent: Mutt/1.3.23i Organisation: Ninth Circle Enterprises Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -On [20011204 07:15], Wes Peters (wes@softweyr.com) wrote: >Documenting the options to indent(1) that most closely produces style(9) >compliant code would certainly be a starting point. I think you could >easily make the point that FreeBSD's indent should default to style(9) >settings as well, or at least support a flag that does so. The following in vim works wonders for me: augroup cprog " Remove all cprog autocommands autocmd! autocmd BufNewFile,BufRead *.c,*.h set formatoptions=croql autocmd BufNewFile,BufRead *.c,*.h set cindent autocmd BufNewFile,BufRead *.c,*.h set comments=sr:/*,mb:*,el:*/,:// autocmd BufNewFile,BufRead *.c,*.h set cinoptions=t0(0 augroup END [Of course, this works only when you actively edit the document.] -- Jeroen Ruigrok van der Werven / Asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org, www.xmach.org I raise a sunken smile, as I serve the ones who served... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Dec 4 1:16: 6 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id D128937B416 for ; Tue, 4 Dec 2001 01:16:03 -0800 (PST) Received: from a96180.upc-a.chello.nl (postfix@a96180.upc-a.chello.nl [62.163.96.180]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB49G2G80796 for ; Tue, 4 Dec 2001 04:16:03 -0500 (EST) (envelope-from asmodai@malbolge.dnsalias.net) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id AD7331F1B; Tue, 4 Dec 2001 10:16:01 +0100 (CET) Date: Tue, 4 Dec 2001 10:16:01 +0100 From: Jeroen Ruigrok/Asmodai To: Wes Peters Cc: freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation Message-ID: <20011204101601.N6664@daemon.ninth-circle.org> References: <20011202011045.F5026-100000@gamplex.bde.org> <3C0C77B8.26C050B0@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C0C77B8.26C050B0@softweyr.com> User-Agent: Mutt/1.3.23i Organisation: Ninth Circle Enterprises Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG -On [20011204 07:15], Wes Peters (wes@softweyr.com) wrote: >I would like to have a place to document this, but neither the source nor >the commit message seems appropriate. This seems appropriate for the >"standards" group to discuss; where should we document regression tests >and/or standards compliance tests? In or near the source tree would be >an ideal location, I think. Test cases developers can use to prove >their work would be a great addition. /usr/src/tools/regression and/or /usr/src/tools/test But it seems both strive to accomplish the same. Personally, in my little mind, tools/regression makes more sense to put regression tests in which test the sources present under /usr/src, whereas test would be extra tests people could run to test other uses of the system as well as extra regression-like tests. -- Jeroen Ruigrok van der Werven / Asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org, www.xmach.org We never know the worth of water, 'till the well is dry... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Dec 4 8:31:43 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 9070337B416 for ; Tue, 4 Dec 2001 08:31:24 -0800 (PST) Received: from softweyr.com (a84d307d4a1716afc2dca86609488ab9@softweyr.com [65.88.244.127]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB4GVMG90251 for ; Tue, 4 Dec 2001 11:31:23 -0500 (EST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 16BJ8v-000DHB-00; Tue, 04 Dec 2001 10:14:05 -0700 Message-ID: <3C0D0995.A7FEFB47@softweyr.com> Date: Tue, 04 Dec 2001 10:36:21 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Garance A Drosihn , Bill Fenner , mike@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation References: <20011203005459.N8502-100000@gamplex.bde.org> Content-Type: multipart/mixed; boundary="------------3F65B277ABF926BCC3633994" Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. --------------3F65B277ABF926BCC3633994 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruce Evans wrote: > > On Sat, 1 Dec 2001, Garance A Drosihn wrote: > > > At 1:52 AM +1100 12/2/01, Bruce Evans wrote: > > > > > (1) missing parens around return values > > >> > > >> style(9) remains silent on this subject. Until required to do so by > > > > > >It is not silent, but not very verbose. All of the examples of returning > > >a value in style(9) use "return (foo)". There is a whole one such example. > > >It apparently didn't occur to the origianal author of style(9) that this > > >needed an explicit rule. > > > > In the argumentative half of my message (this here message...), I will note > > that style(9) also says that parenthesis should not be added unless they are > > necessary, and previous discussions have indicated that parentheses are not > > in fact necessary in C on return statements... The more I have thought > > Individual rules have precedence over general ones. That would be fine, if there were indeed an individual rule. Please feel free to commit one at any time. > > >I tested it a bit more and found a bug in the test code: the test of a > > >short buffer returns an unterminated string (as expected), and printing > > >this non-string using %s gives garbage. > > > > Hmm. I do not have the standards document for strerror_r(), but I am > > surprised that a short buffer is expected to return a string which is > > not null-terminated. Note that I am not arguing the point, I'm just > > surprised. That means all callers to strerror_r() should never treat > > the result as a null-terminated string, even though it usually will > > be null-terminated. Seems to me that is asking for trouble. > > I think the contents of the buffer is indeterminate when strerror_r() > fails. POSIX-1.200x-draft7 is not completely clear on this. The POSIX specificaion Mike mailed to me said "indeterminate". Not nul-terminated seems consistent with "indeterminate", and is documented as so in the man page. > strerror_r() is also permitted to fail if the error number is invalid. > It must then return EINVAL. So the conversion to ASCII is not needed > for strerror_r(), and it may be considered a bug that strerror_r() > doesn't fail for bogus error numbers. However, the conversion is > needed for strerror(). Which leads to an interested conundrum about what "invalid" might be. Is an errno not in the system list "invalid" or just "not predefined?" Does the POSIX specification lead us off this slippery slope, or should the handling of errnos >= sys_nerr be moved to strerror? > Here is my current version of the cleanups for strerror(). New changes: > - don't resever bogus extra space for UPREFIX in ebuf[]. > - fix breakage of reentrancy of strerror_r() in previous verions (tmp[] > must be auto). But this one seems to be dependent on the non-conforming behavior of strerror_r you have noted. I have attached a rewritten version in which strerror_r returns a message only for "known" errors, otherwise it returns EINVAL. The "unknown" message rendering code has been returned to strerror. The number buffer has been sized appropriately at 21 characters, and the static buffer is just long enough to hold the "Unknown error: " message plus the number. I have even obfuscated all returns with unnecessary ()s for Bruce. strerror is no longer implemented in terms of strerror_r since the requirements are so divergent. Please review at your leisure. Once we agree this is "good enough" I'll commit it. I'd prefer to be able to MFC this before the 4.5 freeze. Could one of you standards guys provide a standards compliance statement for the man page? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ --------------3F65B277ABF926BCC3633994 Content-Type: text/plain; charset=us-ascii; name="strerror.3" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="strerror.3" .\" Copyright (c) 1980, 1991, 1993 .\" The Regents of the University of California. All rights reserved. .\" .\" This code is derived from software contributed to Berkeley by .\" the American National Standards Committee X3, on Information .\" Processing Systems. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\" notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\" notice, this list of conditions and the following disclaimer in the .\" documentation and/or other materials provided with the distribution. .\" 3. All advertising materials mentioning features or use of this software .\" must display the following acknowledgement: .\" This product includes software developed by the University of .\" California, Berkeley and its contributors. .\" 4. Neither the name of the University nor the names of its contributors .\" may be used to endorse or promote products derived from this software .\" without specific prior written permission. .\" .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF .\" SUCH DAMAGE. .\" .\" @(#)strerror.3 8.1 (Berkeley) 6/9/93 .\" $FreeBSD: src/lib/libc/string/strerror.3,v 1.7.2.4 2001/08/17 15:42:43 ru Exp $ .\" .Dd Nov 26, 2001 .Dt STRERROR 3 .Os .Sh NAME .Nm perror , .Nm strerror , .Nm strerror_r , .Nm sys_errlist , .Nm sys_nerr .Nd system error messages .Sh LIBRARY .Lb libc .Sh SYNOPSIS .In stdio.h .Ft void .Fn perror "const char *string" .Vt extern const char * const sys_errlist[] ; .Vt extern const int sys_nerr ; .In string.h .Ft char * .Fn strerror "int errnum" .Ft int .Fn strerror_r "int errnum" "char * strerrbuf" "size_t buflen" .Sh DESCRIPTION The .Fn strerror , .Fn strerror_r and .Fn perror functions look up the error message string corresponding to an error number. .Pp The .Fn strerror function accepts an error number argument .Fa errnum and returns a pointer to the corresponding message string. .Pp The .Fn strerror_r function renders the same result into .Fa strerrbuf for a maximum of .Fa buflen characters and returns 0 upon success. .Pp The .Fn perror function finds the error message corresponding to the current value of the global variable .Va errno .Pq Xr intro 2 and writes it, followed by a newline, to the standard error file descriptor. If the argument .Fa string is .Pf non- Dv NULL and does not point to the null character, this string is prepended to the message string and separated from it by a colon and space .Pq Ql \&:\ \& ; otherwise, only the error message string is printed. .Pp If .Fa errnum is not a recognized error number, .Fn strerror returns an error message string containing .Dq Li "Unknown error:\ " followed by the error number in decimal, while .Fn strerror_r returns .Er EINVAL . .Pp If insufficient storage is provided in .Fa strerrbuf (as specified in .Fa buflen ) to contain the error string, .Fn strerror_r returns .Er ERANGE and the contents of .Fa strerrbuf are indeterminate. .Pp The message strings can be accessed directly using the external array .Va sys_errlist . The external value .Va sys_nerr contains a count of the messages in .Va sys_errlist . The use of these variables is deprecated; .Fn strerror or .Fn strerror_r should be used instead. .Sh SEE ALSO .Xr intro 2 , .Xr psignal 3 .Sh HISTORY The .Fn strerror and .Fn perror functions first appeared in .Bx 4.4 . The .Fn strerror_r function was implemented in .Fx 4.4 by .An Wes Peters .Aq wes@freebsd.org . .Sh BUGS For unknown error numbers, the .Fn strerror function will return its result in a static buffer which may be overwritten by subsequent calls. .Pp Programs that use the deprecated .Va sys_errlist variable often fail to compile because they declare it inconsistently. --------------3F65B277ABF926BCC3633994 Content-Type: text/plain; charset=us-ascii; name="strerror.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="strerror.c" /* * Copyright (c) 1988, 1993 The Regents of the University of California. All * rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions are * met: 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. 2. * Redistributions in binary form must reproduce the above copyright notice, * this list of conditions and the following disclaimer in the documentation * and/or other materials provided with the distribution. 3. All advertising * materials mentioning features or use of this software must display the * following acknowledgement: This product includes software developed by the * University of California, Berkeley and its contributors. 4. Neither the * name of the University nor the names of its contributors may be used to * endorse or promote products derived from this software without specific * prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND ANY * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR * ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #if defined(LIBC_SCCS) && !defined(lint) static char sccsid[] = "@(#)strerror.c 8.1 (Berkeley) 6/4/93"; #endif /* LIBC_SCCS and not lint */ #ifndef lint static const char rcsid[] = "$FreeBSD: src/lib/libc/string/strerror.c,v 1.2.14.1 2001/07/09 23:30:06 obrien Exp $"; #endif #include #include #include int strerror_r(int errnum, char *strerrbuf, size_t buflen) { int len; if ((errnum > 0) && (errnum < sys_nerr)) { len = strlcpy(strerrbuf, (char *)sys_errlist[errnum], buflen); return ((len <= buflen) ? 0 : ERANGE); } return (EINVAL); } char * strerror(num) int num; { char *p, *t; unsigned int uerr; static char const unknown_prefix[] = "Unknown error: "; /* * Define a buffer size big enough to describe a 64-bit * number in ASCII decimal (19), with optional leading sign * (+1) and trailing NUL (+1). */ # define NUMLEN 21 # define EBUFLEN (sizeof unknown_prefix + NUMLEN) char tmp[NUMLEN]; /* temporary number */ static char ebuf[EBUFLEN]; /* error message */ if ((num > 0) && (num < sys_nerr)) return ((char *)sys_errlist[num]); /* * Print unknown errno by hand so we don't link to stdio(3). * This collects the ASCII digits in reverse order. */ uerr = (num > 0) ? num : -num; t = tmp; do { *t++ = "0123456789"[uerr % 10]; } while (uerr /= 10); if (num < 0) *t++ = '-'; /* * Copy the "unknown" message and the number into the caller * supplied buffer, inverting the number string. */ strcpy(ebuf, unknown_prefix); for (p = ebuf + sizeof unknown_prefix - 1; t >= tmp; ) *p++ = *--t; *p = '\0'; return (ebuf); } #ifdef STANDALONE_TEST #include main() { char mybuf[64]; int ret; printf("strerror(47) yeilds: %s\n", strerror(47)); printf("strerror(437) yeilds: %s\n", strerror(437)); printf("strerror(LONG_MAX) yeilds: %s\n", strerror(LONG_MAX)); printf("strerror(LONG_MIN) yeilds: %s\n", strerror(LONG_MIN)); printf("strerror(ULONG_MAX) yeilds: %s\n", strerror(ULONG_MAX)); memset(mybuf, '*', 63); mybuf[63] = '\0'; strerror_r(11, mybuf, 64); printf("strerror_r(11) yeilds: %s\n", mybuf); memset(mybuf, '*', 63); mybuf[63] = '\0'; ret = strerror_r(1234, mybuf, 64); printf("strerror_r(1234) returns %d (%s)\n", ret, mybuf); memset(mybuf, '*', 63); mybuf[63] = '\0'; ret = strerror_r(1, mybuf, 10); printf("strerror_r on short buffer returns %d (%s)\n", ret, mybuf); } #endif --------------3F65B277ABF926BCC3633994-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Dec 4 11: 7:26 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 1599237B85C for ; Tue, 4 Dec 2001 11:05:22 -0800 (PST) Received: from mail.rpi.edu (root@mail.rpi.edu [128.113.22.40]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB4J5KG91843 for ; Tue, 4 Dec 2001 14:05:21 -0500 (EST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB4J54X176464; Tue, 4 Dec 2001 14:05:07 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3C0D0995.A7FEFB47@softweyr.com> References: <20011203005459.N8502-100000@gamplex.bde.org> <3C0D0995.A7FEFB47@softweyr.com> Date: Tue, 4 Dec 2001 14:05:00 -0500 To: Wes Peters , Bruce Evans From: Garance A Drosihn Subject: Re: strerror_r() implementation Cc: Bill Fenner , mike@FreeBSD.org, freebsd-standards@bostonradio.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 10:36 AM -0700 12/4/01, Wes Peters wrote: >Bruce Evans wrote: > > On Sat, 1 Dec 2001, Garance A Drosihn wrote: >> > > > Hmm. I do not have the standards document for strerror_r(), but I am >> > surprised that a short buffer is expected to return a string which is >> > not null-terminated. Note that I am not arguing the point, I'm just >> > surprised. That means all callers to strerror_r() should never treat >> > the result as a null-terminated string, even though it usually will >> > be null-terminated. Seems to me that is asking for trouble. >> >> I think the contents of the buffer is indeterminate when strerror_r() >> fails. POSIX-1.200x-draft7 is not completely clear on this. > >The POSIX specificaion Mike mailed to me said "indeterminate". Not >nul-terminated seems consistent with "indeterminate", and is documented >as so in the man page. Well, I understand what "indeterminate" means. It means you can have anything there. Anything. Elvish runes, if you wish. Fine. The fact that the standard says "indeterminate" can not be offered as proof that this particular decision is the "most desirable" one. I merely wanted to offer an alternate opinion as what might be a safer implementation. "Safer" is just as consistent with "indeterminate" as is "not null-terminated". I would present a case that it might be better if we happened to choose to say the buffer will always be null-terminated, but you seem to be loaded for bear on this topic, and I don't wish to seem like I am also loaded for bear. I do think it will be good to get strerror_r() done, and appreciate the work you've done. I will note that in your own patch you have: > memset(mybuf, '*', 63); mybuf[63] = '\0'; > strerror_r(11, mybuf, 64); > printf("strerror_r(11) yeilds: %s\n", mybuf); > > memset(mybuf, '*', 63); mybuf[63] = '\0'; > ret = strerror_r(1234, mybuf, 64); > printf("strerror_r(1234) returns %d (%s)\n", ret, mybuf); > > memset(mybuf, '*', 63); mybuf[63] = '\0'; > ret = strerror_r(1, mybuf, 10); > printf("strerror_r on short buffer returns %d (%s)\n", ret, mybuf); If I understand you right, then you are saying that this implementation of strerror_r() may return a full "mybuf", which will not have any null character in it. If that is our implementation, then I would think that every call to strerror_r() should check the return code, and if the return code is not zero then it should treat the buffer as a constant- width string (ie, a string which does not necessarily have a null character in it). So, not just the last call here, but all of the calls should be checking the return code before doing anything with the buffer. Our implementation claims that it is "laziness" on the part of the programmer to not check that return code, and yet our own example shows that laziness. "We know" that the buffer is long enough, so we assume we don't have to check. What happens if someone changes strerror to localize all the messages (to german, or Ent), and those longer messages no longer fit in the buffer "we know" to be long enough? Just my 2 cents. I don't meant to be argumentative just to rain on your parade. I am just trying to make some observations here without seeming to be ungrateful for the work you're doing. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Dec 4 23:19:36 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 4ACC137B416 for ; Tue, 4 Dec 2001 23:19:26 -0800 (PST) Received: from softweyr.com (e0a38ecb410b1b7dcc129e589bdf3f15@softweyr.com [65.88.244.127]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB57JOG97213 for ; Wed, 5 Dec 2001 02:19:25 -0500 (EST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 16BX11-000E14-00; Wed, 05 Dec 2001 01:02:51 -0700 Message-ID: <3C0DDA2E.8B6C3117@softweyr.com> Date: Wed, 05 Dec 2001 01:26:22 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Garance A Drosihn Cc: Bruce Evans , Bill Fenner , mike@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation References: <20011203005459.N8502-100000@gamplex.bde.org> <3C0D0995.A7FEFB47@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn wrote: > > At 10:36 AM -0700 12/4/01, Wes Peters wrote: > >Bruce Evans wrote: > > > On Sat, 1 Dec 2001, Garance A Drosihn wrote: > >> > > > > Hmm. I do not have the standards document for strerror_r(), but I am > >> > surprised that a short buffer is expected to return a string which is > >> > not null-terminated. Note that I am not arguing the point, I'm just > >> > surprised. That means all callers to strerror_r() should never treat > >> > the result as a null-terminated string, even though it usually will > >> > be null-terminated. Seems to me that is asking for trouble. > >> > >> I think the contents of the buffer is indeterminate when strerror_r() > >> fails. POSIX-1.200x-draft7 is not completely clear on this. > > > >The POSIX specificaion Mike mailed to me said "indeterminate". Not > >nul-terminated seems consistent with "indeterminate", and is documented > >as so in the man page. > > Well, I understand what "indeterminate" means. It means you can > have anything there. Anything. Elvish runes, if you wish. Fine. > The fact that the standard says "indeterminate" can not be offered > as proof that this particular decision is the "most desirable" one. No, but it can be offered as proof that it is "acceptable." But read on, perhaps I *have* come up with something more desirable. ;^) > I merely wanted to offer an alternate opinion as what might be a safer > implementation. "Safer" is just as consistent with "indeterminate" > as is "not null-terminated". > > I would present a case that it might be better if we happened to choose > to say the buffer will always be null-terminated, but you seem to be > loaded for bear on this topic, and I don't wish to seem like I am also > loaded for bear. I do think it will be good to get strerror_r() done, > and appreciate the work you've done. Actually, in the new, improved implementation, if strerror_r touches strerrbuf at all, it will copy in a null-terminated string bearing the first 'len' characters from one of the sys_errlst messages. If the string was truncated, it is still nul-terminated but ERANGE is returned. If errnum is not a known value for errno, EINVAL is returned and strerrbuf is *untouched.* This attempts to be strictly compatible with POSIX. strerror cannot encounter a 'not enough room' error; it either returns a pointer one of the messages from sys_errlst, or a pointer to an internal buffer that contains the message "Unknown error: {num}" that is sized such that it cannot fail. Does this seem OK? > I will note that in your own patch you have: > > > memset(mybuf, '*', 63); mybuf[63] = '\0'; > > strerror_r(11, mybuf, 64); > > printf("strerror_r(11) yeilds: %s\n", mybuf); > > > > memset(mybuf, '*', 63); mybuf[63] = '\0'; > > ret = strerror_r(1234, mybuf, 64); > > printf("strerror_r(1234) returns %d (%s)\n", ret, mybuf); > > > > memset(mybuf, '*', 63); mybuf[63] = '\0'; > > ret = strerror_r(1, mybuf, 10); > > printf("strerror_r on short buffer returns %d (%s)\n", ret, mybuf); > > If I understand you right, then you are saying that this implementation > of strerror_r() may return a full "mybuf", which will not have any null > character in it. If that is our implementation, then I would think that > every call to strerror_r() should check the return code, and if the > return code is not zero then it should treat the buffer as a constant- > width string (ie, a string which does not necessarily have a null > character in it). So, not just the last call here, but all of the > calls should be checking the return code before doing anything with > the buffer. Our implementation claims that it is "laziness" on the > part of the programmer to not check that return code, and yet our own > example shows that laziness. That's not an example, it's a test case. In the current implementation, the last call returns ERANGE and 'mybuf' still contains 63 *'s. Despite what many C programmers think, checking the return value of library functions is NOT OPTIONAL, especially in "Posix-me-harder" land. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Dec 5 8:13:35 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 538E137B422 for ; Wed, 5 Dec 2001 08:13:14 -0800 (PST) Received: from mail.rpi.edu (root@mail.rpi.edu [128.113.22.40]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB5GDDG01489 for ; Wed, 5 Dec 2001 11:13:13 -0500 (EST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id fB5GCir79652; Wed, 5 Dec 2001 11:12:48 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <3C0DDA2E.8B6C3117@softweyr.com> References: <20011203005459.N8502-100000@gamplex.bde.org> <3C0D0995.A7FEFB47@softweyr.com> <3C0DDA2E.8B6C3117@softweyr.com> Date: Wed, 5 Dec 2001 11:12:42 -0500 To: Wes Peters From: Garance A Drosihn Subject: Re: strerror_r() implementation Cc: Bruce Evans , Bill Fenner , mike@FreeBSD.org, freebsd-standards@bostonradio.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 1:26 AM -0700 12/5/01, Wes Peters wrote: >Actually, in the new, improved implementation, if strerror_r touches >strerrbuf at all, it will copy in a null-terminated string bearing >the first 'len' characters from one of the sys_errlst messages. If the >string was truncated, it is still nul-terminated but ERANGE is returned. >If errnum is not a known value for errno, EINVAL is returned and strerrbuf >is *untouched.* This attempts to be strictly compatible with POSIX. > >strerror cannot encounter a 'not enough room' error; it either returns >a pointer one of the messages from sys_errlst, or a pointer to an >internal buffer that contains the message "Unknown error: {num}" that >is sized such that it cannot fail. > >Does this seem OK? Well, this sounds pretty good to me. I have no suggestions which might make it better. Thanks. I will now tiptoe away quietly... :-) -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Dec 6 0: 7: 7 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 8048E37B416 for ; Thu, 6 Dec 2001 00:06:59 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB686uG08800 for ; Thu, 6 Dec 2001 03:06:57 -0500 (EST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA19990; Thu, 6 Dec 2001 19:06:12 +1100 Date: Thu, 6 Dec 2001 19:06:39 +1100 (EST) From: Bruce Evans X-X-Sender: To: Wes Peters Cc: Garance A Drosihn , Bill Fenner , , Subject: Re: strerror_r() implementation In-Reply-To: <3C0D0995.A7FEFB47@softweyr.com> Message-ID: <20011206183558.N14527-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 4 Dec 2001, Wes Peters wrote: > Bruce Evans wrote: > > Individual rules have precedence over general ones. > > That would be fine, if there were indeed an individual rule. Please feel > free to commit one at any time. The example (of "return (eight)") implicitly gives a rule. > > I think the contents of the buffer is indeterminate when strerror_r() > > fails. POSIX-1.200x-draft7 is not completely clear on this. > > The POSIX specificaion Mike mailed to me said "indeterminate". Not > nul-terminated seems consistent with "indeterminate", and is documented > as so in the man page. Which POSIX specification? > > strerror_r() is also permitted to fail if the error number is invalid. > > It must then return EINVAL. So the conversion to ASCII is not needed > > for strerror_r(), and it may be considered a bug that strerror_r() > > doesn't fail for bogus error numbers. However, the conversion is > > needed for strerror(). > > Which leads to an interested conundrum about what "invalid" might be. > Is an errno not in the system list "invalid" or just "not predefined?" > Does the POSIX specification lead us off this slippery slope, or should > the handling of errnos >= sys_nerr be moved to strerror? "valid" is not specified POSIX.1-200x-draft7 (except in some special context), so it has its normal English meaning. > > Here is my current version of the cleanups for strerror(). New changes: > > - don't resever bogus extra space for UPREFIX in ebuf[]. > > - fix breakage of reentrancy of strerror_r() in previous verions (tmp[] > > must be auto). > > But this one seems to be dependent on the non-conforming behavior > of strerror_r you have noted. It only depends on strerror() knowing the implementation details of strerror_r(). > I have attached a rewritten version in which strerror_r returns a message > only for "known" errors, otherwise it returns EINVAL. The "unknown" > message rendering code has been returned to strerror. The number buffer > has been sized appropriately at 21 characters, and the static buffer > is just long enough to hold the "Unknown error: " message plus the > number. I have even obfuscated all returns with unnecessary ()s for > Bruce. > > strerror is no longer implemented in terms of strerror_r since the > requirements are so divergent. Please review at your leisure. Once > we agree this is "good enough" I'll commit it. I'd prefer to be able > to MFC this before the 4.5 freeze. I agree that this is an improvement but not that it is "good enough". The best thing about it is that it makes strerror() self-contained again, so most of the style bugs are now easy to fix by reverting to the version of sterror() in rev.1.4. It makes the dubious non-cosmetic change not using sys_errlist[0] in either strerror_r() or sterror(), so an error code of 0 is now considered invalid for strerror_r(), and the string returned by strerror(0) is changed from "Undefined error: 0" in sys_errlist[0] to "Unknown error: 0" generated in strerror(). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Dec 6 0:47: 3 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 6C15B37B416 for ; Thu, 6 Dec 2001 00:46:58 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB68kuG09283 for ; Thu, 6 Dec 2001 03:46:56 -0500 (EST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA23110; Thu, 6 Dec 2001 19:45:37 +1100 Date: Thu, 6 Dec 2001 19:46:04 +1100 (EST) From: Bruce Evans X-X-Sender: To: Wes Peters Cc: Bill Fenner , , Subject: Re: strerror_r() implementation In-Reply-To: <3C0C77B8.26C050B0@softweyr.com> Message-ID: <20011206192801.M14527-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 4 Dec 2001, Wes Peters wrote: > int > strerror_r(int errnum, char *strerrbuf, size_t buflen) > { > unsigned int uerr; > char *p, *t; > char tmp[NUMSTRINGLEN]; > int len; > > uerr = errnum; > if (uerr < sys_nerr) { > len = strlcpy(strerrbuf, (char *)sys_errlist[uerr], buflen); > return (len <= buflen) ? 0 : ERANGE; > } I just noticed a non-cosmetic bug (which is also in 1.5, later mail, and 1.6). The check of strlcpy()'s return value is of by 1. This causes truncated messages. E.g., char buf[23]; strerror_r(1, buf, 23) writes "Operation not permitte" in buf and bogusly succeeds. STANDALONE_TEST doesn't go near this since it always uses a large enough buffer. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Dec 6 22:35:22 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 15EBE37B41B for ; Thu, 6 Dec 2001 22:35:17 -0800 (PST) Received: from softweyr.com (ef6200df68a4b3c6419c8e2028837fc4@softweyr.com [65.88.244.127]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB76ZFG20381 for ; Fri, 7 Dec 2001 01:35:15 -0500 (EST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 16CFH5-000FuI-00; Fri, 07 Dec 2001 00:18:23 -0700 Message-ID: <3C10728D.56A8FDF1@softweyr.com> Date: Fri, 07 Dec 2001 00:41:01 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Garance A Drosihn , Bill Fenner , mike@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation References: <20011206183558.N14527-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans wrote: > > On Tue, 4 Dec 2001, Wes Peters wrote: > > > Bruce Evans wrote: > > > Individual rules have precedence over general ones. > > > > That would be fine, if there were indeed an individual rule. Please feel > > free to commit one at any time. > > The example (of "return (eight)") implicitly gives a rule. The example of "return (eight)" implicitly says nothing. It's two tiny characters buried in the middle of a lot of text that is EXPLICITLY pointing out several unrelated rules. Make it an EXPLICIT rule in style(9) or stop beating people up about it. You're being an ass about this. I do not understand why you think it is appropriate to be sly about this when it would be quite simple to just make a simple, explicit statement. > > > I think the contents of the buffer is indeterminate when strerror_r() > > > fails. POSIX-1.200x-draft7 is not completely clear on this. > > > > The POSIX specificaion Mike mailed to me said "indeterminate". Not > > nul-terminated seems consistent with "indeterminate", and is documented > > as so in the man page. > > Which POSIX specification? 1003.1-200x Draft June 14, 2001. Upon careful reading, this is completely silent on the issue of what happens with strerrbuf if insufficient space is allowed to contain the string. That's pretty much the ultimate in indeterminate. This implementation fills in as much of sys_errlist as will fit and properly nul-terminates it. I have updated the man page to more accurately describe what is done. > > > strerror_r() is also permitted to fail if the error number is invalid. > > > It must then return EINVAL. So the conversion to ASCII is not needed > > > for strerror_r(), and it may be considered a bug that strerror_r() > > > doesn't fail for bogus error numbers. However, the conversion is > > > needed for strerror(). > > > > Which leads to an interested conundrum about what "invalid" might be. > > Is an errno not in the system list "invalid" or just "not predefined?" > > Does the POSIX specification lead us off this slippery slope, or should > > the handling of errnos >= sys_nerr be moved to strerror? > > "valid" is not specified POSIX.1-200x-draft7 (except in some special > context), so it has its normal English meaning. So this is an untestable requirement and any particular choice we make is as conforming as any other. Love those specs. It seems that strerror is required to set errno to EINVAL if "The value of errnum is not a valid error number." I have implemented this as well. > > strerror is no longer implemented in terms of strerror_r since the > > requirements are so divergent. Please review at your leisure. Once > > we agree this is "good enough" I'll commit it. I'd prefer to be able > > to MFC this before the 4.5 freeze. > > I agree that this is an improvement but not that it is "good enough". > The best thing about it is that it makes strerror() self-contained > again, so most of the style bugs are now easy to fix by reverting to > the version of sterror() in rev.1.4. In spite of the style rants you held against the version of strerror() in rev. 1.4? Or are EXISTING style nits somehow less worrisome than new style nits? Is it that somehow in your mind the programmers of the past are so much better than those of the current that their style bogons are acceptable while ours are not? Since strerror doesn't properly set errno, it is not Posix complaint in rev. 1.4, so this is not a solution either. > It makes the dubious non-cosmetic > change not using sys_errlist[0] in either strerror_r() or sterror(), > so an error code of 0 is now considered invalid for strerror_r(), and > the string returned by strerror(0) is changed from "Undefined error: 0" > in sys_errlist[0] to "Unknown error: 0" generated in strerror(). Easily enough fixed. I somehow imagined having "Undefined error: 0" use the same message as "Undefined error: 437" to be an improvement. sys_errlist messages will be used where 0 <= errnum < sys_nerr, and I have documented this as the "recognized range" in the man page. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Thu Dec 6 23:57:15 2001 Delivered-To: freebsd-standards@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id DC5AC37B419 for ; Thu, 6 Dec 2001 23:57:11 -0800 (PST) Received: from softweyr.com (6a7325e4e3fd8de51393f555495f341c@softweyr.com [65.88.244.127]) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) with ESMTP id fB77vAG20866 for ; Fri, 7 Dec 2001 02:57:10 -0500 (EST) (envelope-from wes@softweyr.com) Received: from homer.softweyr.com ([204.68.178.39] helo=softweyr.com) by softweyr.com with esmtp (Exim 3.33 #1) id 16CGZb-000Fvw-00; Fri, 07 Dec 2001 01:41:35 -0700 Message-ID: <3C10861A.93F7D090@softweyr.com> Date: Fri, 07 Dec 2001 02:04:26 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Bruce Evans Cc: Garance A Drosihn , Bill Fenner , mike@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: strerror_r() implementation References: <20011206183558.N14527-100000@gamplex.bde.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Wes Peters ranted: > > Bruce Evans wrote: > > > > On Tue, 4 Dec 2001, Wes Peters wrote: > > > > > Bruce Evans wrote: > > > > Individual rules have precedence over general ones. > > > > > > That would be fine, if there were indeed an individual rule. Please feel > > > free to commit one at any time. > > > > The example (of "return (eight)") implicitly gives a rule. > > The example of "return (eight)" implicitly says nothing. It's two > tiny characters buried in the middle of a lot of text that is > EXPLICITLY pointing out several unrelated rules. Make it an EXPLICIT > rule in style(9) or stop beating people up about it. You're being an > ass about this. This was unwarranted and impolite. Please accept my apologies, and allow me to clarify my position on style(9). FreeBSD has often been accused of being clannish and of having undocumented and imprecise rules that are seen more as hazing than as constructive ways to move the project forward. One of the many examples cited have been code reviews based on rules that are not documented anywhere; programmers are told to "read the code" and "make it look like KNF" rather than given guidelines to code by. Clarifying style(9) to the point where the rules are simply stated, obvious to all readers, and do not rely on outside sources will help FreeBSD in many ways. It will help improve the consistency of the code, it will help us recruit and retain fine new programmers, and it will make us look less capricious to newcomers and outsiders. Since much of our existing knowlege about what style(9) should be is locked within your head, you are one of the few who can really accomplish this work. Your reviews are valuable to FreeBSD and to all of the contributors to FreeBSD because of your depth and breadth of knowlege about FreeBSD, the various standards efforts we attempt to support, and the world of UNIX and C in general. Please help us by extending this knowlege into further development and clarification of style(9) into a resoure for all programmers looking into FreeBSD. If you feel that crafting the actual explanations is something you might wish to have help with, Mike has expressed an interest in this area. I too am interested and willing to help. While KNF is not my preferred programming style, I am willing to help because I think any documented coding style for a project is better than none at all, and I am willing to conform to the group style as far as it is clearly and unambiguously documented. Again, Bruce, please accept my apologies for the above-quoted message. I should not respond to reviews late at night when I am not prepared to make clear responses, the fault is all mine. Thank you for your time and your help. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Dec 8 11: 9:51 2001 Delivered-To: freebsd-standards@freebsd.org Received: from whale.sunbay.crimea.ua (whale.sunbay.crimea.ua [212.110.138.65]) by hub.freebsd.org (Postfix) with ESMTP id E5CA437B405 for ; Sat, 8 Dec 2001 11:09:40 -0800 (PST) Received: (from ru@localhost) by whale.sunbay.crimea.ua (8.11.6/8.11.2) id fB8J9Ww70860 for standards@FreeBSD.org; Sat, 8 Dec 2001 21:09:32 +0200 (EET) (envelope-from ru) Date: Sat, 8 Dec 2001 21:09:32 +0200 From: Ruslan Ermilov To: standards@FreeBSD.org Subject: Please welcome POSIX.1-2001! Message-ID: <20011208210932.A70511@sunbay.com> References: <200112081902.fB8J2a295543@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200112081902.fB8J2a295543@freefall.freebsd.org> User-Agent: Mutt/1.3.23i Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi! I've just added the .St mdoc(7) macro support for just ratified IEEE Std 1003.1-2001 (``POSIX.1''). Please feel free to use it in manpages' STANDARDS section. An example: : .Sh STANDARDS : The : .Nm : utility conforms to : .St -p1003.1-2001 . On Sat, Dec 08, 2001 at 11:02:36AM -0800, Ruslan Ermilov wrote: > ru 2001/12/08 11:02:36 PST > > Modified files: > gnu/usr.bin/groff/tmac mdoc.local > Log: > December 6th -- the IEEE Standards Board approves the Austin Group > Specification as IEEE Std 1003.1-2001. Yay! > > Revision Changes Path > 1.7 +10 -0 src/gnu/usr.bin/groff/tmac/mdoc.local Cheers, -- Ruslan Ermilov Oracle Developer/DBA, ru@sunbay.com Sunbay Software AG, ru@FreeBSD.org FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Dec 8 12:22:47 2001 Delivered-To: freebsd-standards@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id E538437B405; Sat, 8 Dec 2001 12:22:45 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id fB8KLSn15618; Sat, 8 Dec 2001 15:21:28 -0500 (EST) (envelope-from mike) Date: Sat, 8 Dec 2001 15:21:28 -0500 From: Mike Barcroft To: Ruslan Ermilov Cc: standards@FreeBSD.org Subject: Re: Please welcome POSIX.1-2001! Message-ID: <20011208152128.E1956@espresso.q9media.com> References: <200112081902.fB8J2a295543@freefall.freebsd.org> <20011208210932.A70511@sunbay.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011208210932.A70511@sunbay.com>; from ru@FreeBSD.org on Sat, Dec 08, 2001 at 09:09:32PM +0200 Organization: The FreeBSD Project Sender: owner-freebsd-standards@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ruslan Ermilov writes: > I've just added the .St mdoc(7) macro support for just ratified > IEEE Std 1003.1-2001 (``POSIX.1''). Please feel free to use it > in manpages' STANDARDS section. An example: > > : .Sh STANDARDS > : The > : .Nm > : utility conforms to > : .St -p1003.1-2001 . Great, thanks. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message