From owner-freebsd-standards Mon Feb 25 20:40:39 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E8D7D37B405 for ; Mon, 25 Feb 2002 20:40:28 -0800 (PST) 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 PAA32103; Tue, 26 Feb 2002 15:40:12 +1100 Date: Tue, 26 Feb 2002 15:40:36 +1100 (EST) From: Bruce Evans X-X-Sender: To: Bill Fenner Cc: Subject: Re: scanf(3) patches for review In-Reply-To: <200201300531.g0U5VEh48095@stash.attlabs.att.com> Message-ID: <20020226141642.A43061-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, 29 Jan 2002, Bill Fenner wrote: > Here are some long-standing scanf(3) patches, which add the new c99 > size modifiers to scanf(3). They've been languishing in my tree waiting Here is a belated review. > for me to get around to implementing %n$, but I am clearly not getting > to it so there's nothing to win by sitting on 'em. > > One thing that I haven't decided yet is whether it makes sense to > rewrite the size modifier narrative to a table in the same way as > I did for printf(3). Input is solicited. I didn't look at the mdoc parts. > Index: vfscanf.c > =================================================================== > RCS file: /home/ncvs/src/lib/libc/stdio/vfscanf.c,v > retrieving revision 1.19 > diff -u -r1.19 vfscanf.c > --- vfscanf.c 29 Nov 2001 03:03:55 -0000 1.19 > +++ vfscanf.c 30 Jan 2002 05:16:58 -0000 > @@ -45,6 +45,7 @@ > #include "namespace.h" > #include > #include > +#include > #include > #if __STDC__ > #include > @@ -52,6 +53,7 @@ > #include > #endif > #include > +#include > #include "un-namespace.h" > > #include "collate.h" Includes more disordered than before. > @@ -76,7 +78,11 @@ > #define SUPPRESS 0x08 /* suppress assignment */ > #define POINTER 0x10 /* weird %p pointer (`fake hex') */ > #define NOSKIP 0x20 /* do not skip blanks */ > -#define QUAD 0x400 > +#define LONGLONG 0x400 /* ll: long long (+ deprecated q: quad) */ > +#define INTMAXT 0x800 /* j: intmax_t */ > +#define PTRDIFFT 0x1000 /* t: ptrdiff_t */ > +#define SIZET 0x2000 /* z: size_t */ > +#define SHORTSHORT 0x4000 /* hh: char */ > > /* > * The following are used in numeric conversions only: Please change all the old comments to have the same format (e.g., "p: void * (`fake hex')" for POINTER. > @@ -98,13 +104,10 @@ > #define CT_CHAR 0 /* %c conversion */ > #define CT_CCL 1 /* %[...] conversion */ > #define CT_STRING 2 /* %s conversion */ > -#define CT_INT 3 /* integer, i.e., strtoq or strtouq */ > +#define CT_INT 3 /* integer, i.e., strtoimax or strtoumax */ > #define CT_FLOAT 4 /* floating, i.e., strtod */ I think naming the conversion function(s) is not as useful as naming all the format specifiers. > @@ -136,8 +139,8 @@ > int nassigned; /* number of fields assigned */ > int nconversions; /* number of conversions */ > int nread; /* number of characters consumed from fp */ > - int base; /* base argument to strtoq/strtouq */ > - u_quad_t(*ccfn)(); /* conversion function (strtoq/strtouq) */ > + int base; /* base argument to strtoimax/strtoumax */ > + uintmax_t(*ccfn)(); /* conversion function (strtoimax/strtoumax) */ Missing space after uintmax_t (from style bug in rev.1.11). Naming the conversion functions all over is even less useful than above. We should start fixing incomplete prototypes in libc. They are more common for function pointers like the above than for functions. > @@ -205,61 +225,49 @@ > > /* > * Conversions. > - * Those marked `compat' are for 4.[123]BSD compatibility. > - * > - * (According to ANSI, E and X formats are supposed > - * to the same as e and x. Sorry about that.) > */ > - case 'D': /* compat */ > - flags |= LONG; > - /* FALLTHROUGH */ Maybe abort() for obsolete formats. > case 'd': > c = CT_INT; > - ccfn = (u_quad_t (*)())strtoq; > + ccfn = (uintmax_t (*)())strtoimax; > base = 10; > break; I was unhappy with the corresponding global change from strto[u]l to strto[u]q in rev.1.11. It pessimized the usual case and changes the handling of overflow. scanf'ing the integer one larger than LONG_MAX using %ld used to give LONG_MAX and set errno = ERANGE, but it gives undefined behaviour (usually silent truncation to LONG_MIN). Rev.1.1 had the same problem with the integer one larger than INT_MIN if INT_MIN < LONG_MIN. I just learned that all these misbehaviours are standards conformant. The behaviour is undefined if the integer (parsed in the same way as strto[u]l execpt with infinite precsion) is too large to be representatable by the specified type. So we can parse all integers using strto[u]max() and blindly truncate them. No programs should notice the inefficiency for this, since no programs should use the scanf family, at least with integer formats, since there is no way to determine if the scan really worked :-). > #ifdef FLOATING_POINT > - case 'E': /* compat XXX */ > - case 'F': /* compat */ > - flags |= LONG; > - /* FALLTHROUGH */ > + case 'E': case 'F': case 'G': Oops, we can't abort in most cases, since the specifier is used for something else. > @@ -278,7 +289,7 @@ > case 'p': /* pointer format is like hex */ > flags |= POINTER | PFXOK; > c = CT_INT; > - ccfn = strtouq; > + ccfn = strtoumax; > base = 16; > break; > Strictly, pointers might need more precision than strtoumax(), and we might even have a function to support this if we had a machine that needed it, but the function wouldn't fit into the current framework. > ... > @@ -451,7 +465,7 @@ > continue; > > case CT_INT: > - /* scan an integer as if by strtoq/strtouq */ > + /* scan an integer as if by strtoimax/strtoumax */ As above about naming the conversion functions all over. The standard actually only says that the subject sequence is in the same format as expected by strtol(). > @@ -569,19 +583,27 @@ > (void) __ungetc(c, fp); > } > if ((flags & SUPPRESS) == 0) { > - u_quad_t res; > + uintmax_t res; > > *p = 0; > res = (*ccfn)(buf, (char **)NULL, base); This invokes undefined behaviour (calling through a function pointer with a type different from the original function). This can be fixed easily by throwing away the function pointer and all the dubious casts to it. Just set an UNSIGNED flag if we don't already have a suitable flag, and use it here as follows: if (flags & UNSIGNED) res = strtoumax(buf, NULL, base); else res = strtoimax(buf, NULL, base); Better code would use a a specialized function for each result type and not risk gratutous sign extension bugs for storing all the results in a common type. About 15 specialized functgions would be needed. This is too much for a function that should never be used, so I'm not seriously suggesting it :-). > if (flags & POINTER) > *va_arg(ap, void **) = > - (void *)(u_long)res; > + (void *)(uintptr_t)res; Strictly, uintmax_t is not suitable for storing pointers. The cast to uintptr_t is main to break warnings about this. Better code would use: *va_arg(ap, void **) = strtovoidstar(...); This is even simpler, except strtovoidstar() doesn't exist. > + else if (flags & SHORTSHORT) > + *va_arg(ap, char *) = res; Better code for this would not be as simple as for pointers, since it would require 2 elseif clauases instead of 1 (for the signed and unsigned cases). Similarly for all the other integer types except ptrdiff_t and size_t. I like most of your changes but didn't check them against the standard. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Feb 26 8:48:25 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id 10BD937B430 for ; Tue, 26 Feb 2002 08:48:13 -0800 (PST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 6D15D4CE33; Tue, 26 Feb 2002 11:48:12 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA13482; Tue, 26 Feb 2002 11:48:11 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA20603; Tue, 26 Feb 2002 08:48:11 -0800 (PST) Message-Id: <200202261648.IAA20603@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: bde@zeta.org.au Subject: Re: scanf(3) patches for review Cc: standards@freebsd.org Date: Tue, 26 Feb 2002 08:48:10 -0800 Versions: dmail (solaris) 2.3/makemail 2.9b 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 >Better code would use a a specialized function for each result type and >not risk gratutous sign extension bugs for storing all the results in a >common type. I actually typedef'd a type to avoid all the prototype-free casts: typedef uintmax_t (*ccfn_t) (const char *, char **, int); The big if is almost there already (as you noted later), dealing with assigning back to the right vararg type. Strictly speaking, it's cheating for unsigned values, so a truly correct function would have to have the extra ifs for signed/unsigned anyway. At that point, putting the right conversion function instead of "res" would be trivial. >Strictly, uintmax_t is not suitable for storing pointers. I thought uintmax_t was the largest integer type, and uintptr_t was an integer type large enough to store a pointer -- so sizeof(uintmax_t) >= sizeof(uintptr_t). Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Feb 26 9:55:19 2002 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 878EF37B402; Tue, 26 Feb 2002 09:55:14 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.6) id g1QHssM96824; Tue, 26 Feb 2002 12:54:54 -0500 (EST) (envelope-from wollman) Date: Tue, 26 Feb 2002 12:54:54 -0500 (EST) From: Garrett Wollman Message-Id: <200202261754.g1QHssM96824@khavrinen.lcs.mit.edu> To: Alexey Dokuchaev Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org, standards@freebsd.org Subject: Re: or not ? [Was: cvs commit: src/include grp.h] In-Reply-To: <20020226151423.A57693@cytherea.weblab.nsu.ru> References: <200202251355.g1PDtmb35078@freefall.freebsd.org> <20020225140030.GD33818@nagual.pp.ru> <3C7A458F.427FFF8A@FreeBSD.org> <20020225142352.GA34378@nagual.pp.ru> <200202251828.g1PISL382207@khavrinen.lcs.mit.edu> <20020226084959.GA43948@nagual.pp.ru> <20020226151423.A57693@cytherea.weblab.nsu.ru> 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 [Follow-ups to FreeBSD-standards, please!] < said: > Is there any chance we will come anywhere close to POSIX 2001 at all? Yes. We already came close on 1990. The way 2001 is structured makes it much easier to comply (than 1996) while still providing a modern programming environment (with 64-bit file sizes, etc.). There are many obscure options in 2001 that we will likely never implement -- but that's why they're options; most other operating systems won't implement them either. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Feb 26 10:24:28 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E6E7237B477 for ; Tue, 26 Feb 2002 10:24:03 -0800 (PST) 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 FAA23783; Wed, 27 Feb 2002 05:23:59 +1100 Date: Wed, 27 Feb 2002 05:24:19 +1100 (EST) From: Bruce Evans X-X-Sender: To: Bill Fenner Cc: Subject: Re: scanf(3) patches for review In-Reply-To: <200202261648.IAA20603@windsor.research.att.com> Message-ID: <20020227051758.Y45742-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, 26 Feb 2002, Bill Fenner wrote: > >Strictly, uintmax_t is not suitable for storing pointers. > > I thought uintmax_t was the largest integer type, and uintptr_t was > an integer type large enough to store a pointer -- so > sizeof(uintmax_t) >= sizeof(uintptr_t). Strictly, uintptr_t might not exist. Of course, we are unlikely to support machines where it doesn't. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Feb 26 21:40:34 2002 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 92A1F37B41A for ; Tue, 26 Feb 2002 21:39:51 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g1R5Yli24966 for standards@FreeBSD.org; Wed, 27 Feb 2002 00:34:47 -0500 (EST) (envelope-from mike) Date: Wed, 27 Feb 2002 00:34:47 -0500 From: Mike Barcroft To: standards@FreeBSD.org Subject: Garrett's POSIX versions patch for review Message-ID: <20020227003447.O31007@espresso.q9media.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline 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 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Rather than take forever updating Garrett's patch to a more recent -current, I thought I'd post just the changes to , and work on using the primitive as I work on various headers. Attached is a diff against my version of . I added __ISO_C_VISIBLE in order to identify ISO C features. There is no way to specify a pristine ISO C environment, but we could require a #define before any headers, and document that requirement in the soon- to-be-created c99(7) manual. I also changed the logic, which wasn't quite right (POSIX versions would always be demoted because of fallthru). This meant using a ANSI C construct, specificly #elif. Yes, this means K&R would not work on FreeBSD anymore. But since there is an effort to actively remove K&R support, I don't see this as a problem. If there are objections to this, I can change it to use a long indented list of #if/#else's (yuk!). Best regards, Mike Barcroft --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cdefs.diff" Index: cdefs.h =================================================================== RCS file: /work/repo/src/sys/sys/cdefs.h,v retrieving revision 1.49 diff -u -r1.49 cdefs.h --- cdefs.h 4 Dec 2001 01:29:54 -0000 1.49 +++ cdefs.h 27 Feb 2002 03:28:19 -0000 @@ -268,4 +268,99 @@ #define __DEQUALIFY(type, var) ((type)(uintptr_t)(const volatile void *)(var)) #endif +/*- + * The following definitions are an extension of the behavior + * originally implemented in , but with a different + * level of granularity. POSIX.1 requires that the macros we test + * be defined before any standard header file is included. + * + * Here's a quick run-down of the versions: + * defined(_POSIX_SOURCE) 1003.1-1988 + * _POSIX_C_SOURCE == 1 1003.1-1990 + * _POSIX_C_SOURCE == 199309 1003.1b-1993 + * _POSIX_C_SOURCE == 199506 1003.1c-1995, 1003.1i-1995, + * and the omnibus ISO/IEC 9945-1: 1996 + * _POSIX_C_SOURCE == 200112 1003.1-2001 + * + * In addition, the X/Open Portability Guide, which is now the Single + * UNIX Specification, defines a feature-test macro which indicates the + * version of that specification, and which subsumes _POSIX_C_SOURCE. + * + * Our macros begin with two underscores to avoid namespace screwage. + */ + +/* Deal with IEEE Std. 1003.1-1990, in which _POSIX_C_SOURCE == 1. */ +#if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE < 199309 +# undef _POSIX_C_SOURCE /* probably illegal, but beyond caring now */ +# define _POSIX_C_SOURCE 199009 +#endif + +/* Deal with various X/Open Portability Guides and Single UNIX Spec. */ +#if defined(_XOPEN_SOURCE) +# if _XOPEN_SOURCE >= 600 +# define __XSI_VISIBLE 600 +# undef _POSIX_C_SOURCE +# define _POSIX_C_SOURCE 200112 +# elif _XOPEN_SOURCE >= 500 +# define __XSI_VISIBLE 500 +# undef _POSIX_C_SOURCE +# define _POSIX_C_SOURCE 199506 +# endif +#endif + +/* + * Deal with all versions of POSIX. The ordering relative to the tests above is + * important. + */ +#if defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE) +# define _POSIX_C_SOURCE 198808 +#endif +#if defined(_POSIX_C_SOURCE) +# if _POSIX_C_SOURCE >= 200112 +# define __POSIX_VISIBLE 200112 +# define __ISO_C_VISIBLE 1999 +# elif _POSIX_C_SOURCE >= 199506 +# define __POSIX_VISIBLE 199506 +# define __ISO_C_VISIBLE 1990 +# elif _POSIX_C_SOURCE >= 199309 +# define __POSIX_VISIBLE 199309 +# define __ISO_C_VISIBLE 1990 +# elif _POSIX_C_SOURCE >= 199009 +# define __POSIX_VISIBLE 199009 +# define __ISO_C_VISIBLE 1990 +# else +# define __POSIX_VISIBLE 198808 +# define __ISO_C_VISIBLE 0 +# endif +#else +/*- + * Deal with _ANSI_SOURCE: + * If it is defined, and no other compilation environment is explicitly + * requested, then define our internal feature-test macros to zero. + * This makes no difference to the preprocessor (undefined symbols in + * preprocessing expressions are defined to have value zero), but makes + * it more convenient for a test program to print out the values. + * + * If a program mistakenly defines _ANSI_SOURCE and some other macro + * such as _POSIX_C_SOURCE, we will assume that it wants the broader + * compilation environment (and in fact we will never get here). + */ +# if defined(_ANSI_SOURCE) /* hide almost everything */ +# define __POSIX_VISIBLE 0 +# define __XSI_VISIBLE 0 +# define __BSD_VISIBLE 0 +# define __ISO_C_VISIBLE 1990 +# else /* default environment: show everything */ +# define __POSIX_VISIBLE 200112 +# define __XSI_VISIBLE 600 +# define __BSD_VISIBLE 1 +# define __ISO_C_VISIBLE 1999 +# endif +#endif + +#if __POSIX_VISIBLE +#define _POSIX_VERSION 200112 +#define _KPOSIX_VERSION 200112 +#endif + #endif /* !_SYS_CDEFS_H_ */ --sdtB3X0nJg68CQEu-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Feb 26 21:45: 9 2002 Delivered-To: freebsd-standards@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id D7B6737B405; Tue, 26 Feb 2002 21:45:04 -0800 (PST) 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 g1R5j3i37487; Tue, 26 Feb 2002 22:45:03 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1R5j2L31312; Tue, 26 Feb 2002 22:45:03 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 26 Feb 2002 22:44:49 -0700 (MST) Message-Id: <20020226.224449.28794535.imp@village.org> To: mike@FreeBSD.ORG Cc: standards@FreeBSD.ORG Subject: Re: Garrett's POSIX versions patch for review From: "M. Warner Losh" In-Reply-To: <20020227003447.O31007@espresso.q9media.com> References: <20020227003447.O31007@espresso.q9media.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 I think that these diffs look good on the surface. I agree that it would be nice to have a prisitine c99 env, but if that's hard to do, then I don't see waiting the rest of the changes. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Feb 26 21:52: 2 2002 Delivered-To: freebsd-standards@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3CC9E37B400 for ; Tue, 26 Feb 2002 21:51:52 -0800 (PST) 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 g1R5poi37525 for ; Tue, 26 Feb 2002 22:51:51 -0700 (MST) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g1R5poL31332 for ; Tue, 26 Feb 2002 22:51:50 -0700 (MST) (envelope-from imp@village.org) Date: Tue, 26 Feb 2002 22:51:37 -0700 (MST) Message-Id: <20020226.225137.13083739.imp@village.org> To: standards@FreeBSD.ORG Subject: Quick review please on chio patch From: "M. Warner Losh" X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Feb_26_22:51:37_2002_344)--" 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 ----Next_Part(Tue_Feb_26_22:51:37_2002_344)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Barcroft asked me to do a u_int*_t -> uint*t sweep of the tree while I was at the __P stuff. I just did chio and thought I'd let people here comment on my patches. Warner ----Next_Part(Tue_Feb_26_22:51:37_2002_344)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=chio-patch Index: chio.c =================================================================== RCS file: /cache/ncvs/src/bin/chio/chio.c,v retrieving revision 1.20 diff -u -r1.20 chio.c --- chio.c 2 Feb 2002 06:15:21 -0000 1.20 +++ chio.c 27 Feb 2002 05:48:45 -0000 @@ -47,6 +47,7 @@ #include #include #include +#include #include #include #include @@ -65,7 +66,7 @@ static int is_special(char *); static const char *bits_to_string(ces_status_flags, const char *); -static void find_element(char *, u_int16_t *, u_int16_t *); +static void find_element(char *, uint16_t *, uint16_t *); static struct changer_element_status *get_element_status (unsigned int, unsigned int); @@ -945,7 +946,7 @@ { struct changer_element_status *ces; struct changer_move cmd; - u_int16_t type, element; + uint16_t type, element; ++argv; --argc; @@ -1017,8 +1018,8 @@ (void)memset(&cesr, 0, sizeof(cesr)); - cesr.cesr_element_type = (u_int16_t)type; - cesr.cesr_element_base = (u_int16_t)element; + cesr.cesr_element_type = (uint16_t)type; + cesr.cesr_element_base = (uint16_t)element; cesr.cesr_element_count = 1; /* Only this one element */ cesr.cesr_flags |= CESR_VOLTAGS; /* Grab voltags as well */ cesr.cesr_element_status = ces; @@ -1041,7 +1042,7 @@ * and iterate until we find a match, or crap out. */ static void -find_element(char *voltag, u_int16_t *et, u_int16_t *eu) +find_element(char *voltag, uint16_t *et, uint16_t *eu) { struct changer_params cp; struct changer_element_status_request cesr; ----Next_Part(Tue_Feb_26_22:51:37_2002_344)---- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Feb 26 22: 2:56 2002 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 C274D37B400 for ; Tue, 26 Feb 2002 22:02:54 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g1R5vn725532; Wed, 27 Feb 2002 00:57:49 -0500 (EST) (envelope-from mike) Date: Wed, 27 Feb 2002 00:57:49 -0500 From: Mike Barcroft To: "M. Warner Losh" Cc: standards@FreeBSD.ORG Subject: Re: Quick review please on chio patch Message-ID: <20020227005748.P31007@espresso.q9media.com> References: <20020226.225137.13083739.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020226.225137.13083739.imp@village.org>; from imp@village.org on Tue, Feb 26, 2002 at 10:51:37PM -0700 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 M. Warner Losh writes: > Mike Barcroft asked me to do a u_int*_t -> uint*t sweep of the tree > while I was at the __P stuff. I just did chio and thought I'd let > people here comment on my patches. Looks good. 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 Tue Feb 26 23:59:36 2002 Delivered-To: freebsd-standards@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 34D0237B400; Tue, 26 Feb 2002 23:59:34 -0800 (PST) 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 SAA12248; Wed, 27 Feb 2002 18:56:58 +1100 Date: Wed, 27 Feb 2002 18:57:27 +1100 (EST) From: Bruce Evans X-X-Sender: To: "M. Warner Losh" Cc: , Subject: Re: Garrett's POSIX versions patch for review In-Reply-To: <20020226.224449.28794535.imp@village.org> Message-ID: <20020227184645.K47808-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, 26 Feb 2002, M. Warner Losh wrote: > I think that these diffs look good on the surface. I agree that it > would be nice to have a prisitine c99 env, but if that's hard to do, > then I don't see waiting the rest of the changes. I think they look bad on the surface :-). E.g., using #if defined (...) instead of #ifdef, and indenting preprocessor code are style bugs. There are superflous underscores. I don't remember any technical problems from when I reviewed the first version of Garrett's patch. The new __FOO_VISIBLE macros are much easier to use than the old _FOO_VISIBLE[_BAR] ones. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Tue Feb 26 23:59:53 2002 Delivered-To: freebsd-standards@freebsd.org Received: from marvin.idsi.net (66-168-58-99.jvl.wi.charter.com [66.168.58.99]) by hub.freebsd.org (Postfix) with ESMTP id 7F97C37B402 for ; Tue, 26 Feb 2002 23:59:48 -0800 (PST) Received: from marvin.idsi.net (localhost [127.0.0.1]) by marvin.idsi.net (8.12.2/8.12.2) with ESMTP id g1R7xdkR087836 for ; Wed, 27 Feb 2002 01:59:42 -0600 (CST) (envelope-from mkm@marvin.idsi.net) Received: (from mkm@localhost) by marvin.idsi.net (8.12.2/8.12.2/Submit) id g1R7xdwq087835 for standards@freebsd.org; Wed, 27 Feb 2002 01:59:39 -0600 (CST) Date: Wed, 27 Feb 2002 01:59:39 -0600 From: Kyle Martin To: standards@freebsd.org Message-ID: <20020227015939.A87827@marvin.idsi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 subscribe freebsd-standards mkm@idsi.net -- Kyle Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Feb 27 11:49:25 2002 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 A1E8037B405 for ; Wed, 27 Feb 2002 11:49:17 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g1RJhxM43573; Wed, 27 Feb 2002 14:43:59 -0500 (EST) (envelope-from mike) Date: Wed, 27 Feb 2002 14:43:59 -0500 From: Mike Barcroft To: Bruce Evans Cc: "M. Warner Losh" , standards@FreeBSD.ORG Subject: Re: Garrett's POSIX versions patch for review Message-ID: <20020227144359.R31007@espresso.q9media.com> References: <20020226.224449.28794535.imp@village.org> <20020227184645.K47808-100000@gamplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: <20020227184645.K47808-100000@gamplex.bde.org>; from bde@zeta.org.au on Wed, Feb 27, 2002 at 06:57:27PM +1100 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 --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Bruce Evans writes: > On Tue, 26 Feb 2002, M. Warner Losh wrote: > > > I think that these diffs look good on the surface. I agree that it > > would be nice to have a prisitine c99 env, but if that's hard to do, > > then I don't see waiting the rest of the changes. > > I think they look bad on the surface :-). E.g., using #if defined (...) > instead of #ifdef, and indenting preprocessor code are style bugs. > There are superflous underscores. One might think I would be able to identify and fix style bugs in my own patches. :) Updated version attached. > I don't remember any technical problems from when I reviewed the first > version of Garrett's patch. The new __FOO_VISIBLE macros are much easier > to use than the old _FOO_VISIBLE[_BAR] ones. When I spoke about the logic bug, I was specifically referring to this part here: %%% +#if defined(_POSIX_C_SOURCE) +# if _POSIX_C_SOURCE >= 200199 +# define __POSIX_VISIBLE 200199 +# endif +# if _POSIX_C_SOURCE >= 199506 +# define __POSIX_VISIBLE 199506 +# endif +# if _POSIX_C_SOURCE >= 199309 +# define __POSIX_VISIBLE 199309 +# endif +# if _POSIX_C_SOURCE >= 199009 +# define __POSIX_VISIBLE 199009 +# endif +# if _POSIX_C_SOURCE < 199009 +# define __POSIX_VISIBLE 198808 +# endif %%% Best regards, Mike Barcroft --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="cdefs2.diff" Index: cdefs.h =================================================================== RCS file: /work/repo/src/sys/sys/cdefs.h,v retrieving revision 1.49 diff -u -r1.49 cdefs.h --- cdefs.h 4 Dec 2001 01:29:54 -0000 1.49 +++ cdefs.h 27 Feb 2002 19:31:10 -0000 @@ -268,4 +268,99 @@ #define __DEQUALIFY(type, var) ((type)(uintptr_t)(const volatile void *)(var)) #endif +/*- + * The following definitions are an extension of the behavior originally + * implemented in , but with a different level of grandularity. + * POSIX.1 requires that the macros we test be defined before any standard + * header file is included. + * + * Here's a quick run-down of the versions: + * defined(_POSIX_SOURCE) 1003.1-1988 + * _POSIX_C_SOURCE == 1 1003.1-1990 + * _POSIX_C_SOURCE == 199309 1003.1b-1993 + * _POSIX_C_SOURCE == 199506 1003.1c-1995, 1003.1i-1995, + * and the omnibus ISO/IEC 9945-1: 1996 + * _POSIX_C_SOURCE == 200112 1003.1-2001 + * + * In addition, the X/Open Portability Guide, which is now the Single UNIX + * Specification, defines a feature-test macro which indicates the version of + * that specification, and which subsumes _POSIX_C_SOURCE. + * + * Our macros begin with two underscores to avoid namespace screwage. + */ + +/* Deal with IEEE Std. 1003.1-1990, in which _POSIX_C_SOURCE == 1. */ +#if defined(_POSIX_C_SOURCE) && _POSIX_C_SOURCE < 199309 +#undef _POSIX_C_SOURCE /* Probably illegal, but beyond caring now. */ +#define _POSIX_C_SOURCE 199009 +#endif + +/* Deal with various X/Open Portability Guides and Single UNIX Spec. */ +#ifdef _XOPEN_SOURCE +#if _XOPEN_SOURCE >= 600 +#define __XSI_VISIBLE 600 +#undef _POSIX_C_SOURCE +#define _POSIX_C_SOURCE 200112 +#elif _XOPEN_SOURCE >= 500 +#define __XSI_VISIBLE 500 +#undef _POSIX_C_SOURCE +#define _POSIX_C_SOURCE 199506 +#endif +#endif + +/* + * Deal with all versions of POSIX. The ordering relative to the tests above is + * important. + */ +#if defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE) +#define _POSIX_C_SOURCE 198808 +#endif +#ifdef _POSIX_C_SOURCE +#if _POSIX_C_SOURCE >= 200112 +#define __POSIX_VISIBLE 200112 +#define __ISO_C_VISIBLE 1999 +#elif _POSIX_C_SOURCE >= 199506 +#define __POSIX_VISIBLE 199506 +#define __ISO_C_VISIBLE 1990 +#elif _POSIX_C_SOURCE >= 199309 +#define __POSIX_VISIBLE 199309 +#define __ISO_C_VISIBLE 1990 +#elif _POSIX_C_SOURCE >= 199009 +#define __POSIX_VISIBLE 199009 +#define __ISO_C_VISIBLE 1990 +#else +#define __POSIX_VISIBLE 198808 +#define __ISO_C_VISIBLE 0 +#endif /* _POSIX_C_SOURCE */ +#else +/*- + * Deal with _ANSI_SOURCE: + * If it is defined, and no other compilation environment is explicitly + * requested, then define our internal feature-test macros to zero. This + * makes no difference to the preprocessor (undefined symbols in preprocessing + * expressions are defined to have value zero), but makes it more convenient for + * a test program to print out the values. + * + * If a program mistakenly defines _ANSI_SOURCE and some other macro such as + * _POSIX_C_SOURCE, we will assume that it wants the broader compilation + * environment (and in fact we will never get here). + */ +#ifdef _ANSI_SOURCE /* Hide almost everything. */ +#define __POSIX_VISIBLE 0 +#define __XSI_VISIBLE 0 +#define __BSD_VISIBLE 0 +#define __ISO_C_VISIBLE 1990 +#else /* Default environment: show everything. */ +#define __POSIX_VISIBLE 200112 +#define __XSI_VISIBLE 600 +#define __BSD_VISIBLE 1 +#define __ISO_C_VISIBLE 1999 +#endif +#endif + +#if __POSIX_VISIBLE +#define _POSIX_VERSION 200112 +#define _KPOSIX_VERSION 200112 +#endif + #endif /* !_SYS_CDEFS_H_ */ --i9LlY+UWpKt15+FH-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Mar 1 0:33:26 2002 Delivered-To: freebsd-standards@freebsd.org Received: from marvin.idsi.net (66-168-58-99.jvl.wi.charter.com [66.168.58.99]) by hub.freebsd.org (Postfix) with ESMTP id 1599B37B402 for ; Fri, 1 Mar 2002 00:33:19 -0800 (PST) Received: from marvin.idsi.net (localhost [127.0.0.1]) by marvin.idsi.net (8.12.2/8.12.2) with ESMTP id g218Wt0M039490 for ; Fri, 1 Mar 2002 02:32:58 -0600 (CST) (envelope-from mkm@marvin.idsi.net) Received: (from mkm@localhost) by marvin.idsi.net (8.12.2/8.12.2/Submit) id g218WtKD039489 for freebsd-standards@freebsd.org; Fri, 1 Mar 2002 02:32:55 -0600 (CST) Date: Fri, 1 Mar 2002 02:32:55 -0600 From: Kyle Martin To: freebsd-standards@freebsd.org Subject: wc(1) patch for review Message-ID: <20020301023255.A39275@marvin.idsi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i 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 heres a patch to take care of wc's -m argument, option, which evedently is the same as -c. i left -c in their but it could easily be taken out diff -U 5 /usr/src/usr.bin/wc/wc.1 wc/wc.1 --- wc/wc.1.old Wed Aug 15 04:09:45 2001 +++ wc/wc.1 Thu Feb 28 05:16:29 2002 @@ -41,11 +41,11 @@ .Sh NAME .Nm wc .Nd word, line, and byte count .Sh SYNOPSIS .Nm -.Op Fl clw +.Op Fl clmw .Op Ar .Sh DESCRIPTION The .Nm utility displays the number of lines, words, and bytes contained in each @@ -68,10 +68,13 @@ .It Fl c The number of bytes in each input file is written to the standard output. .It Fl l The number of lines in each input file +is written to the standard output. +.It Fl m +The number of bytes in each input file is written to the standard output. .It Fl w The number of words in each input file is written to the standard output. .El diff -U 5 /usr/src/usr.bin/wc/wc.c wc/wc.c --- wc/wc.c.old Tue Dec 11 16:23:53 2001 +++ wc/wc.c Thu Feb 28 05:11:05 2002 @@ -70,19 +70,22 @@ { int ch, errors, total; (void) setlocale(LC_CTYPE, ""); - while ((ch = getopt(argc, argv, "lwc")) != -1) + while ((ch = getopt(argc, argv, "lwcm")) != -1) switch((char)ch) { case 'l': doline = 1; break; case 'w': doword = 1; break; case 'c': + dochar = 1; + break; + case 'm': dochar = 1; break; case '?': default: usage(); -- Kyle Martin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Mar 1 0:59:19 2002 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 5225737B417 for ; Fri, 1 Mar 2002 00:59:17 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g218rmd15711; Fri, 1 Mar 2002 03:53:48 -0500 (EST) (envelope-from mike) Date: Fri, 1 Mar 2002 03:53:48 -0500 From: Mike Barcroft To: "Tim J. Robbins" Cc: freebsd-standards@FreeBSD.ORG Subject: Re: wc -m option Message-ID: <20020301035348.B7544@espresso.q9media.com> References: <20020203230758.A19532@descent.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020203230758.A19532@descent.robbins.dropbear.id.au>; from tim@robbins.dropbear.id.au on Sun, Feb 03, 2002 at 11:07:58PM +1100 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 [Late reply, prompted by other wc(1) patch.] Tim J. Robbins writes: > This patch adds the SUSV2 -m option to wc to handle multibyte characters. > Since libc is missing iswspace() from , I've had to use isspace(), > which doesn't detect some wide space characters. For example, the Japanese > locale given in euc(4): I think we should wait on this until we have the proper libc support (which hopefully won't take too long). 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 Fri Mar 1 1: 3:18 2002 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 C19B137B402 for ; Fri, 1 Mar 2002 01:03:16 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g218vu515772; Fri, 1 Mar 2002 03:57:56 -0500 (EST) (envelope-from mike) Date: Fri, 1 Mar 2002 03:57:56 -0500 From: Mike Barcroft To: Kyle Martin Cc: freebsd-standards@freebsd.org Subject: Re: wc(1) patch for review Message-ID: <20020301035756.C7544@espresso.q9media.com> References: <20020301023255.A39275@marvin.idsi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020301023255.A39275@marvin.idsi.net>; from mkm@ieee.org on Fri, Mar 01, 2002 at 02:32:55AM -0600 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 Kyle Martin writes: > heres a patch to take care of wc's -m argument, option, which evedently is the same as -c. i left -c in their but it could easily be taken out No, this isn't quite right. See the rationale in POSIX.1-2001 which describes the difference between these options. Also, this task has already been assigned to Tim Robbins. In future, please check the project status board to reduce duplicate work. http://people.FreeBSD.org/~mike/c99/ 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 Fri Mar 1 1:14:46 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (253.d.010.mel.iprimus.net.au [210.50.203.253]) by hub.freebsd.org (Postfix) with ESMTP id 5F10837B400; Fri, 1 Mar 2002 01:14:41 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g219AhH92115; Fri, 1 Mar 2002 20:10:44 +1100 (EST) (envelope-from tim) Date: Fri, 1 Mar 2002 20:10:43 +1100 From: "Tim J. Robbins" To: Mike Barcroft Cc: freebsd-standards@FreeBSD.ORG Subject: Re: wc -m option Message-ID: <20020301201043.A92102@descent.robbins.dropbear.id.au> References: <20020203230758.A19532@descent.robbins.dropbear.id.au> <20020301035348.B7544@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020301035348.B7544@espresso.q9media.com>; from mike@FreeBSD.ORG on Fri, Mar 01, 2002 at 03:53:48AM -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 Fri, Mar 01, 2002 at 03:53:48AM -0500, Mike Barcroft wrote: > [Late reply, prompted by other wc(1) patch.] > > Tim J. Robbins writes: > > This patch adds the SUSV2 -m option to wc to handle multibyte characters. > > Since libc is missing iswspace() from , I've had to use isspace(), > > which doesn't detect some wide space characters. For example, the Japanese > > locale given in euc(4): > > I think we should wait on this until we have the proper libc support > (which hopefully won't take too long). Agreed. getwchar() will make it much simpler and hopefully faster than the method that patch I made used. The ideal way, which will be possible when we get that function, will be to setlocale(LC_CTYPE, "") if -m is given, otherwise "C". I'll submit a new patch when getwchar() arrives. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Mar 1 11:38:46 2002 Delivered-To: freebsd-standards@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 9174137B400; Fri, 1 Mar 2002 11:38:43 -0800 (PST) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020301193843.FEWZ2951.rwcrmhc53.attbi.com@gateway.posi.net>; Fri, 1 Mar 2002 19:38:43 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g21Jcgt13928; Fri, 1 Mar 2002 11:38:42 -0800 (PST) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Fri, 1 Mar 2002 11:38:41 -0800 (PST) From: Kelly Yancey To: Mike Barcroft Cc: "Tim J. Robbins" , Subject: Re: wc -m option In-Reply-To: <20020301035348.B7544@espresso.q9media.com> Message-ID: <20020301113727.P13868-100000@gateway.posi.net> 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 Fri, 1 Mar 2002, Mike Barcroft wrote: > [Late reply, prompted by other wc(1) patch.] > > Tim J. Robbins writes: > > This patch adds the SUSV2 -m option to wc to handle multibyte characters. > > Since libc is missing iswspace() from , I've had to use isspace(), > > which doesn't detect some wide space characters. For example, the Japanese > > locale given in euc(4): > > I think we should wait on this until we have the proper libc support > (which hopefully won't take too long). > Please wait. I have patches in my local tree that properly implement -m (mostly derived from NetBSD). However, I have not checked them in yet because I'm still working on importing NetBSD's wide character support to match. Thanks, Kelly kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Mar 1 17:27: 6 2002 Delivered-To: freebsd-standards@freebsd.org Received: from sunny.newgold.net (durham-ar1-174-172.durham.dsl.gtei.net [4.40.174.172]) by hub.freebsd.org (Postfix) with ESMTP id B089137B405 for ; Fri, 1 Mar 2002 17:26:48 -0800 (PST) Received: from sunny.newgold.net (freebsd@localhost [IPv6:::1]) by sunny.newgold.net (8.12.1/8.12.1) with ESMTP id g2215PDF012492 for ; Sat, 2 Mar 2002 01:06:46 GMT Received: (from freebsd@localhost) by sunny.newgold.net (8.12.1/8.12.1/Submit) id g2215ON8021952 for freebsd-standards@freebsd.org; Sat, 2 Mar 2002 01:05:24 GMT Date: Sat, 2 Mar 2002 01:04:02 +0000 From: "J. Mallett" To: freebsd-standards@freebsd.org Subject: base64 support for uuencode/uudecode Message-ID: <20020302010401.A18553@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.21i Organisation: FreeBSD 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 Hello, Below is a patch that adds most notably base64 encoding and decoding to uuencode and uudecode respectively. uuencode(1) recieves two new options here, one of which is -m (for MIME) which will cause the output to be encoded in base64 instead of the normal uuencode format, the other is -o, which while not in SUSv3 I believe is probably logical as that behaviour is seen in uudecode and thus may be expected by the user of uuencode, but that is of course something I'm willing to hear arguments for or against. The other notable part of adding base64 support to uuencode is of course the addition of uudecode support for the same encoding format. This is done based on what SUSv3 expects, the "begin-base64" replacement of "begin", and "====" instead of the terminal string in uuencode format. To use the b64_{pton,ntop} functions in libc, I had to include 3 networking related headers, so I could use 's prototype and wrapper from b64_* to _b64_*. Aside from that, I can't think of anything much that is worth mentioning, except that I cleaned up most of the warnings along the way, and that it seems to compile fine with BDECFLAGS, and that I cleaned up the style nits that stood out as unfathombly gross. I look forward to your comments. Thanks, /j. Index: uuencode/uuencode.1 =================================================================== RCS file: /home/ncvs/src/usr.bin/uuencode/uuencode.1,v retrieving revision 1.14 diff -u -r1.14 uuencode.1 --- uuencode/uuencode.1 27 Jan 2002 18:21:23 -0000 1.14 +++ uuencode/uuencode.1 2 Mar 2002 00:30:51 -0000 @@ -41,6 +41,8 @@ .Nd encode/decode a binary file .Sh SYNOPSIS .Nm +.Op Fl m +.Op Fl o Ar output_file .Op Ar file .Ar name .Nm uudecode @@ -63,7 +65,9 @@ reads .Ar file (or by default the standard input) and writes an encoded version -to the standard output. +to the standard output, or +.Ar output_file +if one has been specified. The encoding uses only printing .Tn ASCII characters and includes the @@ -86,7 +90,20 @@ .Nm Uudecode ignores any leading and trailing lines. .Pp -The following options are available for +The following options are available: +.Pp +.Nm uuencode : +.Bl -tag -width ident +.It Fl m +Use the Base64 method of encoding, rather than the traditional +.Nm +algorithm. +.It Fl o Ar output_file +Output to +.Ar output_file +instead of standard output. +.El +.Pp .Nm uudecode : .Bl -tag -width ident .It Fl c Index: uuencode/uuencode.c =================================================================== RCS file: /home/ncvs/src/usr.bin/uuencode/uuencode.c,v retrieving revision 1.7 diff -u -r1.7 uuencode.c --- uuencode/uuencode.c 9 Oct 2001 11:05:27 -0000 1.7 +++ uuencode/uuencode.c 2 Mar 2002 00:30:51 -0000 @@ -50,27 +50,53 @@ * * Encode a file so it can be mailed to a remote system. */ -#include +#include +#include #include +#include + #include +#include #include #include +#include #include void encode __P((void)); +void base64_encode __P((void)); static void usage __P((void)); +FILE *output = stdout; +int mode; +char **av; + int main(argc, argv) int argc; char *argv[]; { struct stat sb; - int mode; - - while (getopt(argc, argv, "") != -1) - usage(); + int base64; + char ch; + char *outfile; + + base64 = 0; + outfile = NULL; + + while ((ch = getopt(argc, argv, "mo:")) != -1) { + switch (ch) { + case 'm': + base64 = 1; + break; + case 'o': + outfile = optarg; + break; + case '?': + default: + usage(); + } + } argv += optind; argc -= optind; @@ -91,9 +117,18 @@ usage(); } - (void)printf("begin %o %s\n", mode, *argv); - encode(); - (void)printf("end\n"); + av = argv; + + if (outfile != NULL) { + output = fopen(outfile, "w+"); + if (output == NULL) + err(1, "Unable to open %s for output!\n", outfile); + chmod(outfile, 0644); + } + if (base64) + base64_encode(); + else + encode(); if (ferror(stdout)) errx(1, "write error"); exit(0); @@ -103,6 +138,34 @@ #define ENC(c) ((c) ? ((c) & 077) + ' ': '`') /* + * copy from in to out, encoding in base64 as you go along. + */ +void +base64_encode(void) +{ +#define GROUPS 8 /* Group output chunks */ + unsigned char buf[6]; + char buf2[16]; + size_t n; + int rv, sequence; + + sequence = 0; + + fprintf(output, "begin-base64 %o %s\n", mode, *av); + while ((n = fread(buf, sizeof(buf[0]), + (sizeof(buf) / sizeof(buf[0])), stdin))) { + ++sequence; + rv = b64_ntop(buf, n, buf2, (sizeof(buf2) / sizeof(buf2[0]))); + if (rv == -1) + errx(1, "b64_ntop: error encoding base64"); + fprintf(output, "%s%s", buf2, (sequence % GROUPS) ? "" : "\n"); + } + if (sequence % GROUPS) + fprintf(output, "\n"); + fprintf(output, "====\n"); +} + +/* * copy from in to out, encoding as you go along. */ void @@ -112,9 +175,10 @@ register char *p; char buf[80]; + (void)fprintf(output, "begin %o %s\n", mode, *av); while ((n = fread(buf, 1, 45, stdin))) { ch = ENC(n); - if (putchar(ch) == EOF) + if (fputc(ch, output) == EOF) break; for (p = buf; n > 0; n -= 3, p += 3) { /* Pad with nulls if not a multiple of 3. */ @@ -125,34 +189,32 @@ } ch = *p >> 2; ch = ENC(ch); - if (putchar(ch) == EOF) + if (fputc(ch, output) == EOF) break; ch = ((*p << 4) & 060) | ((p[1] >> 4) & 017); ch = ENC(ch); - if (putchar(ch) == EOF) + if (fputc(ch, output) == EOF) break; ch = ((p[1] << 2) & 074) | ((p[2] >> 6) & 03); ch = ENC(ch); - if (putchar(ch) == EOF) + if (fputc(ch, output) == EOF) break; ch = p[2] & 077; ch = ENC(ch); - if (putchar(ch) == EOF) + if (fputc(ch, output) == EOF) break; } - if (putchar('\n') == EOF) + if (fputc('\n', output) == EOF) break; } if (ferror(stdin)) errx(1, "read error"); - ch = ENC('\0'); - (void)putchar(ch); - (void)putchar('\n'); + (void)fprintf(output, "%c\nend\n", ENC('\0')); } static void usage() { - (void)fprintf(stderr,"usage: uuencode [infile] remotefile\n"); + (void)fprintf(stderr,"usage: uuencode [-m] [-o outfile] [infile] remotefile\n"); exit(1); } Index: uudecode/uudecode.c =================================================================== RCS file: /home/ncvs/src/usr.bin/uudecode/uudecode.c,v retrieving revision 1.17 diff -u -r1.17 uudecode.c --- uudecode/uudecode.c 27 Jan 2002 18:21:23 -0000 1.17 +++ uudecode/uudecode.c 2 Mar 2002 00:30:51 -0000 @@ -52,11 +52,14 @@ * used with uuencode. */ #include +#include #include +#include + #include -#include #include +#include #include #include #include @@ -69,6 +72,7 @@ static void usage __P((void)); int decode __P((void)); int decode2 __P((int)); +void base64_decode __P((const char *)); int main(argc, argv) @@ -109,8 +113,8 @@ usage(); } } - argc -= optind; - argv += optind; + argc -= optind; + argv += optind; if (*argv) { @@ -131,22 +135,22 @@ } int -decode () +decode(void) { int flag; /* decode only one file per input stream */ if (!cflag) - return(decode2(0)); + return (decode2(0)); /* multiple uudecode'd files */ for (flag = 0; ; flag++) if (decode2(flag)) - return(1); + return (1); else if (feof(stdin)) break; - return(0); + return (0); } int @@ -156,31 +160,40 @@ struct passwd *pw; register int n; register char ch, *p; - int ignore, mode, n1; + int base64, ignore, mode, n1; char buf[MAXPATHLEN]; char buffn[MAXPATHLEN]; /* file name buffer */ - ignore = 0; + base64 = ignore = 0; /* search for header line */ do { if (!fgets(buf, sizeof(buf), stdin)) { if (flag) /* no error */ - return(0); + return (0); warnx("%s: no \"begin\" line", filename); - return(1); + return (1); } - } while (strncmp(buf, "begin ", 6) || - fnmatch("begin [0-7]* *", buf, 0)); + } while (strncmp(buf, "begin", 5) != 0); + + if (strncmp(buf, "begin-base64", 12) == 0) + base64 = 1; if (oflag) { - (void)sscanf(buf, "begin %o ", &mode); + if (base64) + (void)sscanf(buf, "begin-base64 %o ", &mode); + else + (void)sscanf(buf, "begin %o ", &mode); if (strlcpy(buf, outfile, sizeof(buf)) >= sizeof(buf)) { warnx("%s: filename too long", outfile); return (1); } - } else - (void)sscanf(buf, "begin %o %[^\n\r]", &mode, buf); + } else { + if (base64) + (void)sscanf(buf, "begin-base64 %o %[^\n\r]", &mode, buf); + else + (void)sscanf(buf, "begin %o %[^\n\r]", &mode, buf); + } if (!sflag && !pflag) { strncpy(buffn, buf, sizeof(buffn)); @@ -188,7 +201,7 @@ strncpy(buf, strrchr(buffn, '/') + 1, sizeof(buf)); if (buf[0] == '\0') { warnx("%s: illegal filename", buffn); - return(1); + return (1); } } @@ -196,18 +209,18 @@ if (buf[0] == '~') { if (!(p = index(buf, '/'))) { warnx("%s: illegal ~user", filename); - return(1); + return (1); } *p++ = '\0'; if (!(pw = getpwnam(buf + 1))) { warnx("%s: no user %s", filename, buf); - return(1); + return (1); } n = strlen(pw->pw_dir); n1 = strlen(p); if (n + n1 + 2 > MAXPATHLEN) { warnx("%s: path too long", filename); - return(1); + return (1); } bcopy(p, buf + n + 1, n1 + 1); bcopy(pw->pw_dir, buf, n); @@ -225,16 +238,23 @@ } else if (!freopen(buf, "w", stdout) || fchmod(fileno(stdout), mode&0666)) { warn("%s: %s", buf, filename); - return(1); + return (1); } } strcpy(buffn, buf); /* store file name from header line */ /* for each input line */ +next: for (;;) { if (!fgets(p = buf, sizeof(buf), stdin)) { warnx("%s: short file", filename); - return(1); + return (1); + } + if (base64) { + if (strncmp(buf, "====", 4) == 0) + return (0); + base64_decode(buf); + goto next; } #define DEC(c) (((c) - ' ') & 077) /* single character decode */ #define IS_DEC(c) ( (((c) - ' ') >= 0) && (((c) - ' ') <= 077 + 1) ) @@ -245,7 +265,7 @@ warnx( \ "\n\tinput file: %s\n\tencoded file: %s\n\tcharacter out of range: [%d-%d]", \ filename, buffn, 1 + ' ', 077 + ' ' + 1); \ - return(1); \ + return (1); \ } #define PUTCHAR(c) \ if (!ignore) \ @@ -300,9 +320,22 @@ (strcmp(buf, "end") && strcmp(buf, "end\n") && strcmp(buf, "end\r\n"))) { warnx("%s: no \"end\" line", filename); - return(1); + return (1); } - return(0); + + return (0); +} + +void +base64_decode(const char *stream) +{ + unsigned char out[MAXPATHLEN * 4]; + int rv; + + rv = b64_pton(stream, out, (sizeof(out) / sizeof(out[0]))); + if (rv == -1) + errx(1, "b64_pton: error decoding base64 input stream"); + printf("%s", out); } static void To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Mar 1 19: 9:16 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (068.c.001.mel.iprimus.net.au [203.134.131.68]) by hub.freebsd.org (Postfix) with ESMTP id 9CC2237B400; Fri, 1 Mar 2002 19:09:01 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g222uNg96111; Sat, 2 Mar 2002 13:56:23 +1100 (EST) (envelope-from tim) Date: Sat, 2 Mar 2002 13:56:21 +1100 From: "Tim J. Robbins" To: "J. Mallett" Cc: freebsd-standards@FreeBSD.ORG Subject: Re: base64 support for uuencode/uudecode Message-ID: <20020302135621.A96061@descent.robbins.dropbear.id.au> References: <20020302010401.A18553@FreeBSD.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020302010401.A18553@FreeBSD.ORG>; from jmallett@FreeBSD.ORG on Sat, Mar 02, 2002 at 01:04:02AM +0000 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, Mar 02, 2002 at 01:04:02AM +0000, J. Mallett wrote: (in uuencode.c) > +FILE *output = stdout; > + outfile = NULL; > + > + while ((ch = getopt(argc, argv, "mo:")) != -1) { > + switch (ch) { > + case 'o': > + outfile = optarg; > + break; > + > + if (outfile != NULL) { > + output = fopen(outfile, "w+"); > + if (output == NULL) > + err(1, "Unable to open %s for output!\n", outfile); > + chmod(outfile, 0644); > + } freopen(outfile, "w", stdout) would be a cleaner way to approach this. The chmod() seems redundant here; with the default umask, 644 will be used anyway. You could, however, chmod 600 the file here to protect it while it's being decoded and before the original mode is restored. > if (ferror(stdout)) > errx(1, "write error"); I think this should be ferror(outfile) if you don't want to freopen(). > + fprintf(output, "begin-base64 %o %s\n", mode, *av); > + while ((n = fread(buf, sizeof(buf[0]), > + (sizeof(buf) / sizeof(buf[0])), stdin))) { This can be tidied up by knowing that sizeof(char) == 1: fread(buf, 1, sizeof(buf), stdin); (in uudecode.c) > - } while (strncmp(buf, "begin ", 6) || > - fnmatch("begin [0-7]* *", buf, 0)); > + } while (strncmp(buf, "begin", 5) != 0); > + > + if (strncmp(buf, "begin-base64", 12) == 0) > + base64 = 1; > > if (oflag) { > - (void)sscanf(buf, "begin %o ", &mode); > + if (base64) > + (void)sscanf(buf, "begin-base64 %o ", &mode); > + else > + (void)sscanf(buf, "begin %o ", &mode); > if (strlcpy(buf, outfile, sizeof(buf)) >= sizeof(buf)) { > warnx("%s: filename too long", outfile); > return (1); > } > - } else > - (void)sscanf(buf, "begin %o %[^\n\r]", &mode, buf); > + } else { > + if (base64) > + (void)sscanf(buf, "begin-base64 %o %[^\n\r]", &mode, buf); > + else > + (void)sscanf(buf, "begin %o %[^\n\r]", &mode, buf); > + } This code is messy, but was already messy long before you touched it. Also, P1003.1-2001 requires that uudecode must be able to decode the result of uuencode. uuencode may encode the file's mode in octal or symbolically. This means that the scanf()'s with %o are incorrect, and that uudecode should use getmode()/setmode() (like chmod(1) does) instead. I think it'd be cleaner to avoid the use of scanf() here altogether. For example, the following (apparently) should be accepted: begin u=rw,go=r foo.txt as well as: begin u+x foo.txt which uses modes relative to an already existing foo.txt file. In general though, I like the way you've used library functions instead of writing the encoding/decoding code yourself. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Mar 1 20:43:30 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (145.c.002.mel.iprimus.net.au [203.134.135.145]) by hub.freebsd.org (Postfix) with ESMTP id 4FA4D37B405; Fri, 1 Mar 2002 20:43:24 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g224cTs11741; Sat, 2 Mar 2002 15:38:29 +1100 (EST) (envelope-from tim) Date: Sat, 2 Mar 2002 15:38:29 +1100 (EST) Message-Id: <200203020438.g224cTs11741@descent.robbins.dropbear.id.au> To: FreeBSD-gnats-submit@freebsd.org Subject: rm(1) STANDARDS section is incorrect From: "Tim J. Robbins" Reply-To: "Tim J. Robbins" Cc: freebsd-standards@freebsd.org X-send-pr-version: 3.113 X-GNATS-Notify: 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 >Submitter-Id: current-users >Originator: Tim J. Robbins >Organization: >Confidential: no >Synopsis: rm(1) STANDARDS section is incorrect >Severity: non-critical >Priority: low >Category: bin >Class: doc-bug >Release: FreeBSD 4.5-STABLE i386 >Environment: System: FreeBSD descent.robbins.dropbear.id.au 4.5-STABLE FreeBSD 4.5-STABLE #5: Sat Feb 16 18:56:18 EST 2002 tim@descent.robbins.dropbear.id.au:/usr/obj/usr/src/sys/DESCENT i386 >Description: rm(1) says: STANDARDS The rm command is almost IEEE Std 1003.2 (``POSIX.2'') compatible, except that POSIX requires rm to act like rmdir(1) when the file specified is a directory. This implementation requires the -d option if such behavior is desired. This follows the historical behavior of rm with respect to directories. However, this is not correct. P1003.2/D11.2, SUSV2 and P1003.1-2001 say the equivalent of the following (wording is from P1003.1-2001): 2. If file is of type directory, the following steps shall be taken: a. If neither the -R option nor the -r option is specified, rm shall write a diagnostic message to standard error, do nothing more with file, and go on to any remaining files. This change was added in revision 1.13 to src/bin/rm/rm.1. >How-To-Repeat: N/A >Fix: This patch, or reverse rev. 1.13. Index: rm.1 =================================================================== RCS file: /home/ncvs/src/bin/rm/rm.1,v retrieving revision 1.23 diff -u -r1.23 rm.1 --- rm.1 2001/07/15 07:49:05 1.23 +++ rm.1 2002/03/02 04:34:59 @@ -190,22 +190,8 @@ .Sh STANDARDS The .Nm -command is almost -.St -p1003.2 -compatible, except that -.Tn POSIX -requires -.Nm -to act like -.Xr rmdir 1 -when the -.Ar file -specified is a directory. This implementation requires the -.Fl d -option if such behavior is desired. This follows the historical -behavior of -.Nm -with respect to directories. +command conforms to +.St -p1003.2 . .Pp The simplified .Nm unlink To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Mar 2 0:48: 4 2002 Delivered-To: freebsd-standards@freebsd.org Received: from sunny.newgold.net (durham-ar1-174-172.durham.dsl.gtei.net [4.40.174.172]) by hub.freebsd.org (Postfix) with ESMTP id C94DA37B416; Sat, 2 Mar 2002 00:47:55 -0800 (PST) Received: from sunny.newgold.net (freebsd@localhost [IPv6:::1]) by sunny.newgold.net (8.12.1/8.12.1) with ESMTP id g228QXDF027969; Sat, 2 Mar 2002 08:27:55 GMT Received: (from freebsd@localhost) by sunny.newgold.net (8.12.1/8.12.1/Submit) id g228QWZC019055; Sat, 2 Mar 2002 08:26:32 GMT Date: Sat, 2 Mar 2002 08:25:10 +0000 From: "J. Mallett" To: "Tim J. Robbins" Cc: "J. Mallett" , freebsd-standards@FreeBSD.ORG Subject: Re: base64 support for uuencode/uudecode Message-ID: <20020302082509.A16290@FreeBSD.ORG> References: <20020302010401.A18553@FreeBSD.ORG> <20020302135621.A96061@descent.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020302135621.A96061@descent.robbins.dropbear.id.au> User-Agent: Mutt/1.3.21i Organisation: FreeBSD 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, Mar 02, 2002 at 01:56:21PM +1100, Tim J. Robbins wrote: > On Sat, Mar 02, 2002 at 01:04:02AM +0000, J. Mallett wrote: > > (in uuencode.c) > > > +FILE *output = stdout; > > > + outfile = NULL; > > + > > + while ((ch = getopt(argc, argv, "mo:")) != -1) { > > + switch (ch) { > > > + case 'o': > > + outfile = optarg; > > + break; > > + > > + if (outfile != NULL) { > > + output = fopen(outfile, "w+"); > > + if (output == NULL) > > + err(1, "Unable to open %s for output!\n", outfile); > > + chmod(outfile, 0644); > > + } > > freopen(outfile, "w", stdout) > would be a cleaner way to approach this. The chmod() seems redundant here; > with the default umask, 644 will be used anyway. You could, however, chmod > 600 the file here to protect it while it's being decoded and before the > original mode is restored. Sorry, I took the chmod when mindlessly copying from uudecode. > > if (ferror(stdout)) > > errx(1, "write error"); > > I think this should be ferror(outfile) if you don't want to freopen(). Yeah, thanks. > > + fprintf(output, "begin-base64 %o %s\n", mode, *av); > > + while ((n = fread(buf, sizeof(buf[0]), > > + (sizeof(buf) / sizeof(buf[0])), stdin))) { > > This can be tidied up by knowing that sizeof(char) == 1: > fread(buf, 1, sizeof(buf), stdin); You're actually the one who got me used to doing that, heh! But anyway, thanks, fixed. > (in uudecode.c) > > > - } while (strncmp(buf, "begin ", 6) || > > - fnmatch("begin [0-7]* *", buf, 0)); > > + } while (strncmp(buf, "begin", 5) != 0); > > + > > + if (strncmp(buf, "begin-base64", 12) == 0) > > + base64 = 1; > > > > if (oflag) { > > - (void)sscanf(buf, "begin %o ", &mode); > > + if (base64) > > + (void)sscanf(buf, "begin-base64 %o ", &mode); > > + else > > + (void)sscanf(buf, "begin %o ", &mode); > > if (strlcpy(buf, outfile, sizeof(buf)) >= sizeof(buf)) { > > warnx("%s: filename too long", outfile); > > return (1); > > } > > - } else > > - (void)sscanf(buf, "begin %o %[^\n\r]", &mode, buf); > > + } else { > > + if (base64) > > + (void)sscanf(buf, "begin-base64 %o %[^\n\r]", &mode, buf); > > + else > > + (void)sscanf(buf, "begin %o %[^\n\r]", &mode, buf); > > + } > > This code is messy, but was already messy long before you touched it. > > Also, P1003.1-2001 requires that uudecode must be able to decode the result > of uuencode. uuencode may encode the file's mode in octal or symbolically. > This means that the scanf()'s with %o are incorrect, and that uudecode should > use getmode()/setmode() (like chmod(1) does) instead. I think it'd be cleaner > to avoid the use of scanf() here altogether. > > For example, the following (apparently) should be accepted: > begin u=rw,go=r foo.txt > as well as: > begin u+x foo.txt > which uses modes relative to an already existing foo.txt file. For similarity I haven't touched this yet,... I'd like to get base64 in and then concentrate on fixing historically broken parts. > In general though, I like the way you've used library functions instead of > writing the encoding/decoding code yourself. I don't like to duplicate library code, and decoding and encoding base64 should be library code... Eventually we should repo copy to libutil, and possibly move away from the networking namespace, for general purpose use of this, and put protos into , but for now, this is the most approachable way of doing it. Plus it keeps code bloat down, in general. > Tim Always a pleasure. /j. An aside: Am I grouping the output chunks acceptably? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Mar 2 16:30:43 2002 Delivered-To: freebsd-standards@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 17A7237B41B for ; Sat, 2 Mar 2002 16:30:38 -0800 (PST) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020303003037.VEPG1147.rwcrmhc52.attbi.com@blossom.cjclark.org> for ; Sun, 3 Mar 2002 00:30:37 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g230UbH83171 for standards@freebsd.org; Sat, 2 Mar 2002 16:30:37 -0800 (PST) (envelope-from cjc) Date: Sat, 2 Mar 2002 16:30:37 -0800 From: "Crist J. Clark" To: standards@freebsd.org Subject: Fw: Re: bin/11114: make(1) does not work as documented with .POSIX: target Message-ID: <20020302163037.M66092@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-URL: http://people.freebsd.org/~cjc/ 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 Could someone here remark on the accuracy of the submitters claim? Basically, the submitter believes that if one defines the '.POSIX' target in his local makefile, he should get the desired behavior. However, FreeBSD is currently set up such that if '.POSIX' is the first target in sys.mk, one gets the POSIX behavior. ----- Forwarded message from Jens Schweikhardt ----- Date: Sat, 23 Feb 2002 15:29:56 +0100 From: Jens Schweikhardt To: cjclark@alum.mit.edu Cc: bug-followup@freebsd.org Subject: Re: bin/11114: make(1) does not work as documented with .POSIX: target User-Agent: Mutt/1.2.5i In-Reply-To: <20020223000444.C16048@blossom.cjclark.org>; from crist.clark@attbi.com on Sat, Feb 23, 2002 at 12:04:44AM -0800 On Sat, Feb 23, 2002 at 12:04:44AM -0800, Crist J. Clark wrote: # On Fri, Feb 22, 2002 at 08:28:50PM +0100, Jens Schweikhardt wrote: # > Crist, # > # > On Wed, Feb 20, 2002 at 08:23:16AM -0800, Crist J. Clark wrote: # > # The issue here is that the .POSIX target will not have its effect # > # until the makefile containing it is read. /usr/share/mk/sys.mk is the # > # first file read. make(1) doesn't know about anything that you have set # > # in your makefile yet. # > # # > # I have no idea if that is a bug or feature. What do the standards say # > # (if anything)? # > # > The POSIX 2001 Standard defines the behavior of make and mandates that # > the macros have the following values, when .POSIX: is specified as the # > first noncomment line and without prerequisites and commands: # # Right, but what is the exact wording? ".POSIX The application shall ensure that this special target is specified without prerequisites or commands. If it appears as the first non-comment line in the makefile, make shall process the makefile as specified by this section; otherwise, the behavior of make is unspecified." Later on it mentions the list of variables and their values. # All of this does work when the # ".POSIX" target is set in sys.mk. In exactly which makefile is the # ".POSIX" target supposed to work? The application programmer's. See the example in the PR. # If it is in the local one, this is a # real problem. Goes against the whole way makefiles are processed. I'm not sure what you mean with "local makefile". Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) ----- End forwarded message ----- -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Mar 2 21:41:52 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (047.b.003.mel.iprimus.net.au [210.50.32.47]) by hub.freebsd.org (Postfix) with ESMTP id 1D78F37B416 for ; Sat, 2 Mar 2002 21:41:47 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g235cPZ26758; Sun, 3 Mar 2002 16:38:25 +1100 (EST) (envelope-from tim) Date: Sun, 3 Mar 2002 16:38:23 +1100 From: "Tim J. Robbins" To: cjclark@alum.mit.edu Cc: freebsd-standards@FreeBSD.ORG Subject: Re: Fw: Re: bin/11114: make(1) does not work as documented with .POSIX: target Message-ID: <20020303163823.A26386@descent.robbins.dropbear.id.au> References: <20020302163037.M66092@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020302163037.M66092@blossom.cjclark.org>; from crist.clark@attbi.com on Sat, Mar 02, 2002 at 04:30:37PM -0800 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, Mar 02, 2002 at 04:30:37PM -0800, Crist J. Clark wrote: > Could someone here remark on the accuracy of the submitters claim? > Basically, the submitter believes that if one defines the '.POSIX' > target in his local makefile, he should get the desired > behavior. However, FreeBSD is currently set up such that if '.POSIX' > is the first target in sys.mk, one gets the POSIX behavior. Yes, the submitter's claim is correct, and the current behaviour of make is wrong. I can't think of an elegant way to solve this problem, though. It requires scanning the makefile given on the command line for the special .POSIX target before we include sys.mk. Doing this on files you can't seek on is messy (standard input). The workaround is to use: make -f mymakefile %POSIX=1003.2 Tim > ----- Forwarded message from Jens Schweikhardt ----- > > Date: Sat, 23 Feb 2002 15:29:56 +0100 > From: Jens Schweikhardt > To: cjclark@alum.mit.edu > Cc: bug-followup@freebsd.org > Subject: Re: bin/11114: make(1) does not work as documented with .POSIX: target > User-Agent: Mutt/1.2.5i > In-Reply-To: <20020223000444.C16048@blossom.cjclark.org>; from crist.clark@attbi.com on Sat, Feb 23, 2002 at 12:04:44AM -0800 > > On Sat, Feb 23, 2002 at 12:04:44AM -0800, Crist J. Clark wrote: > # On Fri, Feb 22, 2002 at 08:28:50PM +0100, Jens Schweikhardt wrote: > # > Crist, > # > > # > On Wed, Feb 20, 2002 at 08:23:16AM -0800, Crist J. Clark wrote: > # > # The issue here is that the .POSIX target will not have its effect > # > # until the makefile containing it is read. /usr/share/mk/sys.mk is the > # > # first file read. make(1) doesn't know about anything that you have set > # > # in your makefile yet. > # > # > # > # I have no idea if that is a bug or feature. What do the standards say > # > # (if anything)? > # > > # > The POSIX 2001 Standard defines the behavior of make and mandates that > # > the macros have the following values, when .POSIX: is specified as the > # > first noncomment line and without prerequisites and commands: > # > # Right, but what is the exact wording? > > ".POSIX The application shall ensure that this special target is specified > without prerequisites or commands. If it appears as the first > non-comment line in the makefile, make shall process the makefile > as specified by this section; otherwise, the behavior of make is > unspecified." > > Later on it mentions the list of variables and their values. > > # All of this does work when the > # ".POSIX" target is set in sys.mk. In exactly which makefile is the > # ".POSIX" target supposed to work? > > The application programmer's. See the example in the PR. > > # If it is in the local one, this is a > # real problem. Goes against the whole way makefiles are processed. > > I'm not sure what you mean with "local makefile". > > Regards, > > Jens > -- > Jens Schweikhardt http://www.schweikhardt.net/ > SIGSIG -- signature too long (core dumped) > > ----- End forwarded message ----- > > -- > Crist J. Clark | cjclark@alum.mit.edu > | cjclark@jhu.edu > http://people.freebsd.org/~cjc/ | cjc@freebsd.org > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-standards" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message