From owner-freebsd-standards Sun Feb 3 3:11:37 2002 Delivered-To: freebsd-standards@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 7492237B405 for ; Sun, 3 Feb 2002 03:11:28 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id 88B612170; Sun, 3 Feb 2002 12:11:22 +0100 (CET) Date: Sun, 3 Feb 2002 12:11:22 +0100 From: Jeroen Ruigrok/asmodai To: standards@FreeBSD.ORG Subject: Possible math problems Message-ID: <20020203111121.GF52378@daemon.ninth-circle.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.24i 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 While adding support for unix98 and ansi99 to TenDRA I passed the complex.h definitions in the spec and started hunting for the IEEE specs on mathematical support. I came to this page: http://win-www.uia.ac.be/u/cant/ieeecc754.html Which is a math testsuite, and linked to from the IEEE 754 page. In the basic operations I noticed the following: Testrun: ./IeeeCC754 -c -s BasicOp/testsets/divide Error Line 655: exponent different Error Line 655: mantissa different Operation: div Round to nearest Operand 1: 00bfffff Operand 2: 3fc00000 Flags expected: x u Flags returned: x u Correct result: 007fffff Returned result: 00800000 Error Line 658: exponent different Error Line 658: mantissa different Operation: div Round to nearest Operand 1: 80bfffff Operand 2: 3fc00000 Flags expected: x u Flags returned: x u Correct result: 807fffff Returned result: 80800000 Summary: -------- Warning: no special 'w' underflow cases in the testset Errors: 2/2153 Warnings: 0/2153 Skipped: 0/2153 Testrun: ./IeeeCC754 -c -s BasicOp/testsets/multiply Error Line 709: mantissa different Operation: mul Round to nearest Operand 1: 33000001 Operand 2: 00ffffff Flags expected: x u Flags returned: x u Correct result: 00000001 Returned result: 00000000 Error Line 709: mantissa different Operation: mul Round to nearest Operand 1: 00ffffff Operand 2: 33000001 Flags expected: x u Flags returned: x u Correct result: 00000001 Returned result: 00000000 [14 others] Summary: -------- Implementation signals underflow in case the result (1) is tiny after rounding and (2) suffers denormalization loss ('u' - underflow) Errors: 16/5408 Warnings: 0/5408 Skipped: 0/5408 Only problems happened with the multiply/division operations. But it becomes more interesting when doing long precision. The error rate increases a lot: Testrun: ./IeeeCC754 -c -d BasicOp/testsets/add Errors: 0/3152 Testrun: ./IeeeCC754 -c -l BasicOp/testsets/add Errors: 1788/3152 This was on 4.5-PRERELEASE with an AMD Athlon. Anyone else like testing this? The Conversions do not work, since it seems to require glibc's bits/mathinline.h header. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ Laat ons drinken op ons grote ongelijk... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Feb 3 4: 9:31 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (060.a.011.mel.iprimus.net.au [210.50.216.60]) by hub.freebsd.org (Postfix) with ESMTP id A2BBB37B402 for ; Sun, 3 Feb 2002 04:08:30 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g13C82I19702 for freebsd-standards@FreeBSD.ORG; Sun, 3 Feb 2002 23:08:02 +1100 (EST) (envelope-from tim) Date: Sun, 3 Feb 2002 23:07:58 +1100 From: "Tim J. Robbins" To: freebsd-standards@FreeBSD.ORG Subject: wc -m option Message-ID: <20020203230758.A19532@descent.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="envbJBWh7q8WU6mo" 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 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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): /* * Code Set 1 */ [snip] SPACE 0x09 - 0x0d 0x20 [snip] /* * Code Set 2 */ SPACE 0xa1a1 [snip] The space characters in Code Set 1 can be used to separate words, but the one in Code Set 2 will not be detected. Tim --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="wc.diff" Index: wc/wc.1 =================================================================== RCS file: /home/ncvs/src/usr.bin/wc/wc.1,v retrieving revision 1.10 diff -u -r1.10 wc.1 --- wc/wc.1 2001/08/15 09:09:45 1.10 +++ wc/wc.1 2002/02/03 11:40:21 @@ -43,7 +43,8 @@ .Nd word, line, and byte count .Sh SYNOPSIS .Nm -.Op Fl clw +.Op Fl c | m +.Op Fl lw .Op Ar .Sh DESCRIPTION The @@ -71,6 +72,9 @@ .It Fl l The number of lines in each input file is written to the standard output. +.It Fl m +The number of characters 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. @@ -79,7 +83,12 @@ When an option is specified, .Nm only reports the information requested by that option. -The default action is equivalent to specifying all of the flags. +The default action is equivalent to specifying the +.Fl c , +.Fl l +and +.Fl w +flags. .Pp If no files are specified, the standard input is used and no file name is displayed. @@ -108,9 +117,11 @@ The .Nm function conforms to -.St -p1003.2 . +.St -susv2 . .Sh HISTORY A .Nm command appeared in .At v1 . +.Sh BUGS +Some multibyte space characters are not detected correctly. Index: wc/wc.c =================================================================== RCS file: /home/ncvs/src/usr.bin/wc/wc.c,v retrieving revision 1.12 diff -u -r1.12 wc.c --- wc/wc.c 2001/12/11 22:23:53 1.12 +++ wc/wc.c 2002/02/03 11:40:22 @@ -51,14 +51,22 @@ #include #include #include +#include #include #include #include #include #include +#include +#include +/* XXX iswspace() is not yet implemented by the C library. */ +#ifndef _WCTYPE_H_ +#define iswspace(c) ((c) <= UCHAR_MAX && isspace(c)) +#endif + u_quad_t tlinect, twordct, tcharct; -int doline, doword, dochar; +int doline, doword, dochar, multi; int cnt __P((const char *)); void usage __P((void)); @@ -72,17 +80,20 @@ (void) setlocale(LC_CTYPE, ""); - while ((ch = getopt(argc, argv, "lwc")) != -1) - switch((char)ch) { + while ((ch = getopt(argc, argv, "clmw")) != -1) + switch(ch) { + case 'm': + multi = 1; + /*FALLTHROUGH*/ + case 'c': + dochar = 1; + break; case 'l': doline = 1; break; case 'w': doword = 1; break; - case 'c': - dochar = 1; - break; case '?': default: usage(); @@ -128,10 +139,11 @@ { struct stat sb; u_quad_t linect, wordct, charct; - int fd, len; + int fd, len, mbpos, n; short gotsp; u_char *p; - u_char buf[MAXBSIZE], ch; + u_char buf[MAXBSIZE], mbbuf[MB_LEN_MAX+1]; + wchar_t ch; linect = wordct = charct = 0; if (file == NULL) { @@ -149,7 +161,7 @@ * lines than to get words, since the word count requires some * logic. */ - if (doline) { + if (doline && !multi) { while ((len = read(fd, buf, MAXBSIZE))) { if (len == -1) { warn("%s: read", file); @@ -174,7 +186,7 @@ * If all we need is the number of characters and it's a * regular or linked file, just stat the puppy. */ - if (dochar) { + if (dochar && !multi) { if (fstat(fd, &sb)) { warn("%s: fstat", file); (void)close(fd); @@ -190,23 +202,34 @@ } /* Do it the hard way... */ -word: for (gotsp = 1; (len = read(fd, buf, MAXBSIZE));) { +word: mbpos = 0; + mbtowc(NULL, NULL, 0); + for (gotsp = 1; (len = read(fd, buf, MAXBSIZE));) { if (len == -1) { warn("%s: read", file); (void)close(fd); return (1); } - /* - * This loses in the presence of multi-byte characters. - * To do it right would require a function to return a - * character while knowing how many bytes it consumed. - */ - charct += len; for (p = buf; len--;) { - ch = *p++; - if (ch == '\n') + if (!multi) + ch = (wchar_t)*p++; + else { + mbbuf[mbpos++] = *p++; + if (mbpos > MB_LEN_MAX) { + /* Multibyte sequence too long. */ + mbtowc(NULL, NULL, 0); + mbpos = 0; + continue; + } + if ((n = mbtowc(&ch, mbbuf, mbpos)) <= 0) + /* Multibyte sequence not done yet. */ + continue; + mbpos = 0; + } + charct++; + if (ch == (wchar_t)'\n') ++linect; - if (isspace(ch)) + if (iswspace(ch)) gotsp = 1; else if (gotsp) { gotsp = 0; @@ -233,6 +256,6 @@ void usage() { - (void)fprintf(stderr, "usage: wc [-clw] [file ...]\n"); + (void)fprintf(stderr, "usage: wc [-c|-m] [-lw] [file ...]\n"); exit(1); } --envbJBWh7q8WU6mo-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Feb 3 4:22:25 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (060.a.011.mel.iprimus.net.au [210.50.216.60]) by hub.freebsd.org (Postfix) with ESMTP id 50D8937B400 for ; Sun, 3 Feb 2002 04:22:05 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g13CLp619770; Sun, 3 Feb 2002 23:21:51 +1100 (EST) (envelope-from tim) Date: Sun, 3 Feb 2002 23:21:51 +1100 From: "Tim J. Robbins" To: Jeroen Ruigrok/asmodai Cc: freebsd-standards@FreeBSD.ORG Subject: Re: Possible math problems Message-ID: <20020203232151.B19532@descent.robbins.dropbear.id.au> References: <20020203111121.GF52378@daemon.ninth-circle.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: <20020203111121.GF52378@daemon.ninth-circle.org>; from asmodai@wxs.nl on Sun, Feb 03, 2002 at 12:11:22PM +0100 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 Sun, Feb 03, 2002 at 12:11:22PM +0100, Jeroen Ruigrok/asmodai wrote: > Testrun: ./IeeeCC754 -c -s BasicOp/testsets/divide > Testrun: ./IeeeCC754 -c -s BasicOp/testsets/multiply > This was on 4.5-PRERELEASE with an AMD Athlon. Anyone else like > testing this? The Conversions do not work, since it seems to require > glibc's bits/mathinline.h header. I get exactly the same results as you for the divide and multiply tests. This machine is 4.5-STABLE, Intel Pentium III. I don't know enough about IEEE FP math to know whether this could be a bug in the test program. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Feb 3 4:43: 4 2002 Delivered-To: freebsd-standards@freebsd.org Received: from a96180.upc-a.chello.nl (a96180.upc-a.chello.nl [62.163.96.180]) by hub.freebsd.org (Postfix) with ESMTP id 0367337B421 for ; Sun, 3 Feb 2002 04:43:00 -0800 (PST) Received: by a96180.upc-a.chello.nl (Postfix, from userid 1001) id 9625D216F; Sun, 3 Feb 2002 13:42:58 +0100 (CET) Date: Sun, 3 Feb 2002 13:42:58 +0100 From: Jeroen Ruigrok/asmodai To: "Tim J. Robbins" Cc: freebsd-standards@FreeBSD.ORG Subject: Re: Possible math problems Message-ID: <20020203124258.GH52378@daemon.ninth-circle.org> References: <20020203111121.GF52378@daemon.ninth-circle.org> <20020203232151.B19532@descent.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020203232151.B19532@descent.robbins.dropbear.id.au> User-Agent: Mutt/1.3.24i 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 [20020203 13:30], Tim J. Robbins (tim@robbins.dropbear.id.au) wrote: >I get exactly the same results as you for the divide and multiply tests. >This machine is 4.5-STABLE, Intel Pentium III. I don't know enough about >IEEE FP math to know whether this could be a bug in the test program. OK, cool. Now I know I need to look a bit more if the other test suites report the same sort problems. -- Jeroen Ruigrok van der Werven / asmodai / Kita no Mono / xMach coreteam asmodai@[wxs.nl|xmach.org], finger asmodai@ninth-circle.org http://www.softweyr.com/asmodai/ He travels the fastest, he who travels alone... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Feb 3 5:37: 2 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 E81EA37B402 for ; Sun, 3 Feb 2002 05:36:53 -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 AAA22656; Mon, 4 Feb 2002 00:36:48 +1100 Date: Mon, 4 Feb 2002 00:39:07 +1100 (EST) From: Bruce Evans X-X-Sender: To: Jeroen Ruigrok/asmodai Cc: Subject: Re: Possible math problems In-Reply-To: <20020203111121.GF52378@daemon.ninth-circle.org> Message-ID: <20020204001700.A19228-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 Sun, 3 Feb 2002, Jeroen Ruigrok/asmodai wrote: > http://win-www.uia.ac.be/u/cant/ieeecc754.html > > Which is a math testsuite, and linked to from the IEEE 754 page. > > In the basic operations I noticed the following: > > Testrun: ./IeeeCC754 -c -s BasicOp/testsets/divide > > Error Line 655: exponent different > Error Line 655: mantissa different > Operation: div > Round to nearest > Operand 1: 00bfffff > Operand 2: 3fc00000 > Flags expected: x u > Flags returned: x u > Correct result: 007fffff > Returned result: 00800000 ucbtest reports similar things. > Summary: > -------- > Implementation signals underflow in case the result > (1) is tiny after rounding and > (2) suffers denormalization loss > ('u' - underflow) > Errors: 16/5408 > Warnings: 0/5408 > Skipped: 0/5408 > > Only problems happened with the multiply/division operations. But it IIRC, the problems for division are caused by double rounding. IIRC, on i387's results are first rounded to extended precision and then rounded to the default precision. The Athlon needs to be bug for bug compatibile with Intel. > becomes more interesting when doing long precision. The error rate > increases a lot: > > Testrun: ./IeeeCC754 -c -d BasicOp/testsets/add > Errors: 0/3152 > > Testrun: ./IeeeCC754 -c -l BasicOp/testsets/add > Errors: 1788/3152 This is probably because the test neglects to set the precision so that long doubles sort of work. gcc doesn't support long doubles properly because it is too hard and slow to do it right. FreeBSD defaults to doing almost all calculations in double precision to limit the damage from the long double support so that it mostly doesn't affect double precision. Perhaps gcc-3 is better. C99 clearly doesn't permit the gcc-2 implementation; C90 was not so clear. ucbtest is aware of this problem but doesn't test long double precision IIRC. It sets the precision to double so that its tests have some chance of working if the default precision and/or compiler support is broken. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Feb 3 6: 2:13 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 BB97F37B405 for ; Sun, 3 Feb 2002 06:02:06 -0800 (PST) Received: from attbi.com ([12.237.33.57]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020203140201.QBHX3578.rwcrmhc52.attbi.com@attbi.com> for ; Sun, 3 Feb 2002 14:02:01 +0000 Message-ID: <3C5D42D8.86517811@attbi.com> Date: Sun, 03 Feb 2002 08:02:00 -0600 From: Joe Halpin X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 Cc: standards@FreeBSD.ORG Subject: Re: Possible math problems References: <20020203111121.GF52378@daemon.ninth-circle.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 I tried it on a PIII 400Mhz running Linux, as well as a PII 300Mhz running -STABLE and got the same results you did. When I tried it on a SPARC Ultra-2 I got the following ./IeeeCC754 -c -s BasicOp/testsets/divide Summary: -------- Warning: no special 'w' underflow cases in the testset Implementation signals underflow in case the result (1) is tiny after rounding and (2) raises the inexact exception ('v' - underflow) Errors: 0/2153 Warnings: 0/2153 Skipped: 0/2153 ./IeeeCC754 -c -s BasicOp/testsets/multiply Summary: -------- Implementation signals underflow in case the result (1) is tiny before rounding and (2) raises the inexact exception ('w' - underflow) Errors: 0/5408 Warnings: 0/5408 Skipped: 0/5408 Joe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Feb 3 7:21:46 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (060.a.011.mel.iprimus.net.au [210.50.216.60]) by hub.freebsd.org (Postfix) with ESMTP id 37F6537B400 for ; Sun, 3 Feb 2002 07:21:33 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g13FLPb20636 for freebsd-standards@FreeBSD.ORG; Mon, 4 Feb 2002 02:21:25 +1100 (EST) (envelope-from tim) Date: Mon, 4 Feb 2002 02:21:24 +1100 From: "Tim J. Robbins" To: freebsd-standards@FreeBSD.ORG Subject: m4 -s option patch Message-ID: <20020204022124.A20605@descent.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" 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 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline This patch adds the -s option to m4 which causes it to emit #line preprocessor directives, removes the bogus -o and -t options which exist in the option parsing code but do nothing and are not required by any standard. File name and line number information is stored on a stack in the same way the FILE*'s are for input, line numbers are incremented in the `gpbc' macro which all input goes through. #line directives are emitted when the file changes. While cleaning up the manual page I noticed we're missing the traceon and traceoff macros required by SUSV2. I haven't had time to implement these yet. Tim --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="m4.diff" Index: m4/eval.c =================================================================== RCS file: /home/ncvs/src/usr.bin/m4/eval.c,v retrieving revision 1.14 diff -u -r1.14 eval.c --- m4/eval.c 2001/07/24 14:09:47 1.14 +++ m4/eval.c 2002/02/03 15:05:03 @@ -584,7 +584,11 @@ errx(1, "too many include files"); if ((infile[ilevel + 1] = fopen(ifile, "r")) != NULL) { ilevel++; + if ((inname[ilevel] = strdup(ifile)) == NULL) + err(1, NULL); + inlineno[ilevel] = 1; bbase[ilevel] = bufbase = bp; + emitline(); return (1); } else @@ -604,9 +608,11 @@ register int c; if ((pf = fopen(pfile, "r")) != NULL) { + fprintf(active, "#line 1 \"%s\"\n", pfile); while ((c = getc(pf)) != EOF) putc(c, active); (void) fclose(pf); + emitline(); return (1); } else Index: m4/extern.h =================================================================== RCS file: /home/ncvs/src/usr.bin/m4/extern.h,v retrieving revision 1.5 diff -u -r1.5 extern.h --- m4/extern.h 2001/07/24 14:09:47 1.5 +++ m4/extern.h 2002/02/03 15:05:04 @@ -53,6 +53,7 @@ void dopushdef __P((char *, char *)); void dosub __P((char *[], int)); void doundiv __P((char *[], int)); +void emitline __P((void)); void eval __P((char *[], int, int)); void expand __P((char *[], int)); void getdiv __P((int)); @@ -72,6 +73,8 @@ extern stae mstack[]; /* stack of m4 machine */ extern FILE *active; /* active output file pointer */ extern FILE *infile[]; /* input file stack (0=stdin) */ +extern char *inname[]; /* names of these input files */ +extern int inlineno[]; /* current number in each input*/ extern FILE *outfile[]; /* diversion array(0=bitbucket) */ extern int fp; /* m4 call frame pointer */ extern int ilevel; /* input file stack pointer */ @@ -92,3 +95,5 @@ extern char *null; /* as it says.. just a null. */ extern char rquote; /* right quote character (') */ extern char scommt; /* start character for comment */ +extern int synccpp; /* Line synchronisation for C preprocessor */ +extern int chscratch; /* Scratch space for gpbc() macro */ Index: m4/m4.1 =================================================================== RCS file: /home/ncvs/src/usr.bin/m4/m4.1,v retrieving revision 1.12 diff -u -r1.12 m4.1 --- m4/m4.1 2001/07/15 08:01:24 1.12 +++ m4/m4.1 2002/02/03 15:05:05 @@ -10,9 +10,9 @@ .Sh SYNOPSIS .Nm .Oo -.Fl D Ns Ar name Ns Op Ar =value +.Fl D Ar name Ns Op Ar =value .Oc -.Op Fl U Ns Ar name +.Op Fl U Ar name .Op Ar filename \|.\|.\|. .Sh DESCRIPTION @@ -41,13 +41,18 @@ .Pp The options are as follows: .Bl -tag -width "-Dname[=value]xxx" -.It Fl D Ns Ar name Ns Oo +.It Fl s +Emit +.Em #line +directives for +.Xr cpp 1 . +.It Fl D Ar name Ns Oo .Ar =value .Oc Define the symbol .Ar name to have some value (or NULL). -.It Fl "U" Ns Ar "name" +.It Fl "U" Ar "name" Undefine the symbol .Ar name . .El @@ -177,7 +182,34 @@ .It unix A pre-defined macro for testing the OS platform. .El +.Sh DIAGNOSTICS +.Ex -std +.Pp +The exit status can be specified by the input file using the +.Em m4exit +macro. +.Sh STANDARDS +The +.Nm +utility is compatible with the +.St -susv2 +specification with the exception of the +.Em traceon +and +.Em traceoff +built-in macros, which are not implemented. +.Pp +The +.Em expr , +.Em paste , +.Em spaste +and +.Em unix +built-in macros are extensions to the standard. +.Sh "SEE ALSO" +.Xr cpp 1 .Sh AUTHORS .An Ozan Yigit Aq oz@sis.yorku.ca -and .An Richard A. O'Keefe Aq ok@goanna.cs.rmit.OZ.AU +.Sh BUGS +The tracing macros are not implemented. Index: m4/main.c =================================================================== RCS file: /home/ncvs/src/usr.bin/m4/main.c,v retrieving revision 1.11 diff -u -r1.11 main.c --- m4/main.c 2001/07/24 14:09:47 1.11 +++ m4/main.c 2002/02/03 15:05:07 @@ -80,6 +80,8 @@ int sp; /* current m4 stack pointer */ int fp; /* m4 call frame pointer */ FILE *infile[MAXINP]; /* input file stack (0=stdin) */ +char *inname[MAXINP]; /* names of these input files */ +int inlineno[MAXINP]; /* current number in each input*/ FILE *outfile[MAXOUT]; /* diversion array(0=bitbucket)*/ FILE *active; /* active output file pointer */ char *m4temp; /* filename for diversions */ @@ -92,6 +94,8 @@ char rquote = RQUOTE; /* right quote character (') */ char scommt = SCOMMT; /* start character for comment */ char ecommt = ECOMMT; /* end character for comment */ +int synccpp = 0; /* Line synchronisation for C preprocessor */ +int chscratch = 0; /* Scratch space for gpbc() macro */ struct keyblk keywrds[] = { /* m4 keywords to be installed */ "include", INCLTYPE, @@ -159,7 +163,7 @@ initkwds(); - while ((c = getopt(argc, argv, "tD:U:o:")) != -1) + while ((c = getopt(argc, argv, "D:U:s")) != -1) switch(c) { case 'D': /* define something..*/ @@ -173,7 +177,9 @@ case 'U': /* undefine... */ remhash(optarg, TOP); break; - case 'o': /* specific output */ + case 's': + synccpp = 1; + break; case '?': usage(); } @@ -195,6 +201,10 @@ sp = -1; /* stack pointer initialized */ fp = 0; /* frame pointer initialized */ infile[0] = stdin; /* default input (naturally) */ + if ((inname[0] = strdup("-")) == NULL) + err(1, NULL); + inlineno[0] = 1; + emitline(); macro(); } else for (; argc--; ++argv) { @@ -206,6 +216,10 @@ sp = -1; fp = 0; infile[0] = ifp; + if ((inname[0] = strdup(p)) == NULL) + err(1, NULL); + inlineno[0] = 1; + emitline(); macro(); if (ifp != stdin) (void)fclose(ifp); @@ -282,7 +296,9 @@ break; /* all done thanks.. */ --ilevel; (void) fclose(infile[ilevel+1]); + free(inname[ilevel+1]); bufbase = bbase[ilevel]; + emitline(); continue; } /* @@ -418,4 +434,13 @@ p->defn = null; p->type = keywrds[i].ktyp | STATIC; } +} + +/* Emit preprocessor #line directive if -s option used. */ +void +emitline() +{ + if (synccpp) + fprintf(active, "#line %d \"%s\"\n", inlineno[ilevel], + inname[ilevel]); } Index: m4/mdef.h =================================================================== RCS file: /home/ncvs/src/usr.bin/m4/mdef.h,v retrieving revision 1.3 diff -u -r1.3 mdef.h --- m4/mdef.h 1995/05/30 06:31:35 1.3 +++ m4/mdef.h 2002/02/03 15:05:08 @@ -142,7 +142,9 @@ * pushf() - push a call frame entry onto stack * pushs() - push a string pointer onto stack */ -#define gpbc() (bp > bufbase) ? (*--bp ? *bp : EOF) : getc(infile[ilevel]) +#define gpbc() (bp > bufbase) ? (*--bp ? *bp : EOF) : \ + ((chscratch = getc(infile[ilevel])) == '\n' && ++inlineno[ilevel], \ + chscratch) #define pushf(x) if (sp < STACKMAX) mstack[++sp].sfra = (x) #define pushs(x) if (sp < STACKMAX) mstack[++sp].sstr = (x) Index: m4/misc.c =================================================================== RCS file: /home/ncvs/src/usr.bin/m4/misc.c,v retrieving revision 1.8 diff -u -r1.8 misc.c --- m4/misc.c 2001/07/24 14:09:47 1.8 +++ m4/misc.c 2002/02/03 15:05:08 @@ -219,6 +219,7 @@ void usage() { - fprintf(stderr, "usage: m4 [-Dname[=val]] [-Uname]\n"); + fprintf(stderr, +"usage: m4 [-s] [-D name[=val]]... [-U name]... file...\n"); exit(1); } --CE+1k2dSO48ffgeK-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Feb 3 14:49:14 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 64DC737B41A for ; Sun, 3 Feb 2002 14:49:04 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g13MjBV08164; Sun, 3 Feb 2002 17:45:11 -0500 (EST) (envelope-from mike) Date: Sun, 3 Feb 2002 17:45:11 -0500 From: Mike Barcroft To: "Tim J. Robbins" Cc: freebsd-standards@FreeBSD.ORG Subject: Re: pwd -L option Message-ID: <20020203174511.A6496@espresso.q9media.com> References: <20020130181638.A8510@descent.robbins.dropbear.id.au> <20020202032917.K10222@espresso.q9media.com> <20020202210237.A2326@descent.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020202210237.A2326@descent.robbins.dropbear.id.au>; from tim@robbins.dropbear.id.au on Sat, Feb 02, 2002 at 09:02:37PM +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 Tim J. Robbins writes: > Here's a new patch that I hope solves the problems you found with my > previous one. I have just a few comments, though... Almost... :) > On Sat, Feb 02, 2002 at 03:29:17AM -0500, Mike Barcroft wrote: > > > Style bug: ANSI-style prototypes. This is a problem because the rest > > of the file uses K&R-style. > > usage()'s prototype is also incorrect, then. It is: > void usage(void); > > It used to have a __P() around its argument list in 4.4BSD. Even then, > the 1st ed. K&R book says nothing about "void", which is usage()'s return > type. Is the so-called K&R style that is supposed to be maintained > documented anywhere? Oops, sorry. As Garance pointed out, Warner has apparently already "fixed" pwd(1) to use ANSI-style prototypes. > Index: pwd/pwd.1 > =================================================================== > RCS file: /home/ncvs/src/bin/pwd/pwd.1,v > retrieving revision 1.15 > diff -u -r1.15 pwd.1 > --- pwd/pwd.1 2001/08/15 09:09:36 1.15 > +++ pwd/pwd.1 2002/02/02 10:02:31 > @@ -43,6 +43,7 @@ > .Nd return working directory name > .Sh SYNOPSIS > .Nm > +.Op Fl LP This should be `L | P'. Similarly, usage() requires this. > .Sh DESCRIPTION > .Nm Pwd > writes the absolute pathname of the current working directory to > @@ -54,17 +55,35 @@ > Consult the > .Xr builtin 1 > manual page. > +.Pp > +The options are as follows: > +.Bl -tag -width indent > +.It Fl L > +Display the logical current working directory. > +.It Fl P > +Display the physical current working directory (all symbolic links resolved). > +This is the default. > +.Pp > +.El > +Only one of > +.Fl L > +and > +.Fl P > +may be specified. This is redundant; the usage will now explain this. > +.Sh ENVIRONMENT > +Environment variables used by > +.Nm : > +.Bl -tag -width PWD > +.It Ev PWD > +Logical current working directory. Missing `.El'. It looks like it accidentally ended up above. > .Sh DIAGNOSTICS > .Ex -std > .Sh STANDARDS > The > .Nm > utility is expected to be > -.St -p1003.2 > +.St -p1003.1-2001 > compatible. Let's be assertive here and say that this utility does conform. > -The > -.Fl L > -flag is not supported. > .Sh SEE ALSO > .Xr builtin 1 , > .Xr cd 1 , > @@ -80,3 +99,9 @@ > However, it can give a different answer in the rare case > that the current directory or a containing directory was moved after > the shell descended into it. > +.Pp > +The > +.Fl L > +option does not work unless the > +.Ev PWD > +variable is exported by the shell. > Index: pwd/pwd.c > =================================================================== > RCS file: /home/ncvs/src/bin/pwd/pwd.c,v > retrieving revision 1.14 > diff -u -r1.14 pwd.c > --- pwd/pwd.c 2002/02/02 06:48:10 1.14 > +++ pwd/pwd.c 2002/02/02 10:02:31 > @@ -45,31 +45,38 @@ > "$FreeBSD: src/bin/pwd/pwd.c,v 1.14 2002/02/02 06:48:10 imp Exp $"; > #endif /* not lint */ > > +#include > +#include > + > #include > +#include > #include > #include > #include > #include > #include > > +extern char *__progname; > + > +static char *getcwd_logical(void); > void usage(void); > > int > main(int argc, char *argv[]) > { > + int Lflag, Pflag; > int ch; > char *p; > char buf[PATH_MAX]; > > - /* > - * Flags for pwd are a bit strange. The POSIX 1003.2B/D9 document > - * has an optional -P flag for physical, which is what this program > - * will produce by default. The logical flag, -L, should fail, as > - * there's no way to display a logical path after forking. > - */ > - while ((ch = getopt(argc, argv, "P")) != -1) > + Lflag = Pflag = 0; > + while ((ch = getopt(argc, argv, "LP")) != -1) This isn't quite right yet. realpath(1) should never call getopt(). It expects no options, so `realpath -L' should return a valid path ending with `/-L'. > switch (ch) { > + case 'L': > + ++Lflag; I prefer `Lflag = 1;'. > + break; > case 'P': > + ++Pflag; Similarly, here. > break; > case '?': > default: > @@ -78,27 +85,52 @@ > argc -= optind; > argv += optind; > > - if (argc == 1) { > + if (strcmp(__progname, "realpath") == 0) { > + if (argc != 1 || Lflag || Pflag) > + usage(); See above. > p = realpath(argv[0], buf); > if (p == NULL) > err(1, "%s", argv[0]); > (void)printf("%s\n", p); > - } else if (argc == 0) { > - p = getcwd(NULL, (size_t)0); > + } else { > + if (argc != 0 || (Lflag && Pflag)) > + usage(); > + p = Lflag ? getcwd_logical() : getcwd(NULL, 0); > if (p == NULL) > err(1, "."); > (void)printf("%s\n", p); > - } else { > - usage(); > } > > exit(0); > } > > void > -usage(void) > +usage() Undo this. See comment above. (Sorry for the confusion.) > +{ Style bug: additional vertical space needed here. > + if (strcmp (__progname, "realpath") == 0) ^^^ Style bug: unneeded space. > + (void)fprintf(stderr, "usage: realpath [file ...]\n"); > + else > + (void)fprintf(stderr, "usage: pwd [-LP]\n"); See above. > + exit(1); > +} > + > +static char * > +getcwd_logical() > { > + struct stat log, phy; > + char *pwd; > + > + /* > + * Check that $PWD is an absolute logical pathname referring to > + * the current working directory. > + */ > + if ((pwd = getenv("PWD")) != NULL && *pwd == '/') { > + if (stat(pwd, &log) == -1 || stat(".", &phy) == -1) > + return (NULL); > + if (log.st_dev == phy.st_dev && log.st_ino == phy.st_ino) > + return (pwd); > + } Much better. > > - (void)fprintf(stderr, "usage: pwd\n"); > - exit(1); > + errno = ENOENT; > + return (NULL); > } I should be able to commit this after you get these problems fixed. 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 Sun Feb 3 16:10: 6 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (110.c.010.mel.iprimus.net.au [210.50.202.110]) by hub.freebsd.org (Postfix) with ESMTP id 5D51137B41E; Sun, 3 Feb 2002 16:09:49 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g1409ku21105; Mon, 4 Feb 2002 11:09:46 +1100 (EST) (envelope-from tim) Date: Mon, 4 Feb 2002 11:09:44 +1100 From: "Tim J. Robbins" To: Mike Barcroft Cc: freebsd-standards@FreeBSD.ORG Subject: Re: pwd -L option Message-ID: <20020204110944.A20748@descent.robbins.dropbear.id.au> References: <20020130181638.A8510@descent.robbins.dropbear.id.au> <20020202032917.K10222@espresso.q9media.com> <20020202210237.A2326@descent.robbins.dropbear.id.au> <20020203174511.A6496@espresso.q9media.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ZPt4rx8FFjLCG7dd" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020203174511.A6496@espresso.q9media.com>; from mike@FreeBSD.ORG on Sun, Feb 03, 2002 at 05:45:11PM -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 --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 03, 2002 at 05:45:11PM -0500, Mike Barcroft wrote: > > -.St -p1003.2 > > +.St -p1003.1-2001 > > compatible. > > Let's be assertive here and say that this utility does conform. I think this should be -p1003.2-2001, but we don't have a macro for that. > This isn't quite right yet. realpath(1) should never call getopt(). > It expects no options, so `realpath -L' should return a valid path > ending with `/-L'. Conceptually pwd and realpath have something in common, but their implementations don't. I don't agree with having realpath built in to pwd. There's probably not much I can do about that, though. Here's another attempt at a patch. Tim --ZPt4rx8FFjLCG7dd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pwd.diff" Index: pwd/pwd.1 =================================================================== RCS file: /home/ncvs/src/bin/pwd/pwd.1,v retrieving revision 1.15 diff -u -r1.15 pwd.1 --- pwd/pwd.1 2001/08/15 09:09:36 1.15 +++ pwd/pwd.1 2002/02/03 23:49:52 @@ -43,6 +43,7 @@ .Nd return working directory name .Sh SYNOPSIS .Nm +.Op Fl L | P .Sh DESCRIPTION .Nm Pwd writes the absolute pathname of the current working directory to @@ -54,17 +55,29 @@ Consult the .Xr builtin 1 manual page. +.Pp +The options are as follows: +.Bl -tag -width indent +.It Fl L +Display the logical current working directory. +.It Fl P +Display the physical current working directory (all symbolic links resolved). +This is the default. +.El +.Sh ENVIRONMENT +Environment variables used by +.Nm : +.Bl -tag -width PWD +.It Ev PWD +Logical current working directory. .Sh DIAGNOSTICS .Ex -std .Sh STANDARDS The .Nm -utility is expected to be -.St -p1003.2 -compatible. -The -.Fl L -flag is not supported. +utility is compliant with the +.St -p1003.1-2001 +specification. .Sh SEE ALSO .Xr builtin 1 , .Xr cd 1 , @@ -80,3 +93,9 @@ However, it can give a different answer in the rare case that the current directory or a containing directory was moved after the shell descended into it. +.Pp +The +.Fl L +option does not work unless the +.Ev PWD +variable is exported by the shell. Index: pwd/pwd.c =================================================================== RCS file: /home/ncvs/src/bin/pwd/pwd.c,v retrieving revision 1.14 diff -u -r1.14 pwd.c --- pwd/pwd.c 2002/02/02 06:48:10 1.14 +++ pwd/pwd.c 2002/02/03 23:49:53 @@ -45,31 +45,47 @@ "$FreeBSD: src/bin/pwd/pwd.c,v 1.14 2002/02/02 06:48:10 imp Exp $"; #endif /* not lint */ +#include +#include + #include +#include #include #include #include #include #include +extern char *__progname; + +static char *getcwd_logical(void); void usage(void); int main(int argc, char *argv[]) { + int Lflag, Pflag; int ch; char *p; char buf[PATH_MAX]; - /* - * Flags for pwd are a bit strange. The POSIX 1003.2B/D9 document - * has an optional -P flag for physical, which is what this program - * will produce by default. The logical flag, -L, should fail, as - * there's no way to display a logical path after forking. - */ - while ((ch = getopt(argc, argv, "P")) != -1) + if (strcmp(__progname, "realpath") == 0) { + if (argc != 2) + usage(); + if ((p = realpath(argv[1], buf)) == NULL) + err(1, "%s", argv[1]); + (void)printf("%s\n", p); + exit(0); + } + + Lflag = Pflag = 0; + while ((ch = getopt(argc, argv, "LP")) != -1) switch (ch) { + case 'L': + Lflag = 1; + break; case 'P': + Pflag = 1; break; case '?': default: @@ -78,19 +94,13 @@ argc -= optind; argv += optind; - if (argc == 1) { - p = realpath(argv[0], buf); - if (p == NULL) - err(1, "%s", argv[0]); - (void)printf("%s\n", p); - } else if (argc == 0) { - p = getcwd(NULL, (size_t)0); - if (p == NULL) - err(1, "."); - (void)printf("%s\n", p); - } else { + if (argc != 0 || (Lflag && Pflag)) usage(); - } + + p = Lflag ? getcwd_logical() : getcwd(NULL, 0); + if (p == NULL) + err(1, "."); + (void)printf("%s\n", p); exit(0); } @@ -98,7 +108,32 @@ void usage(void) { + + if (strcmp(__progname, "realpath") == 0) + (void)fprintf(stderr, "usage: realpath [file ...]\n"); + else + (void)fprintf(stderr, "usage: pwd [-LP]\n"); + + exit(1); +} + +static char * +getcwd_logical(void) +{ + struct stat log, phy; + char *pwd; + + /* + * Check that $PWD is an absolute logical pathname referring to + * the current working directory. + */ + if ((pwd = getenv("PWD")) != NULL && *pwd == '/') { + if (stat(pwd, &log) == -1 || stat(".", &phy) == -1) + return (NULL); + if (log.st_dev == phy.st_dev && log.st_ino == phy.st_ino) + return (pwd); + } - (void)fprintf(stderr, "usage: pwd\n"); - exit(1); + errno = ENOENT; + return (NULL); } --ZPt4rx8FFjLCG7dd-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Feb 3 18:38: 4 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 7E66737B420 for ; Sun, 3 Feb 2002 18:37:55 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g142bmQ20454; Sun, 3 Feb 2002 21:37:48 -0500 (EST) (envelope-from wollman) Date: Sun, 3 Feb 2002 21:37:48 -0500 (EST) From: Garrett Wollman Message-Id: <200202040237.g142bmQ20454@khavrinen.lcs.mit.edu> To: "Tim J. Robbins" Cc: freebsd-standards@FreeBSD.ORG Subject: Re: pwd -L option In-Reply-To: <20020204110944.A20748@descent.robbins.dropbear.id.au> References: <20020130181638.A8510@descent.robbins.dropbear.id.au> <20020202032917.K10222@espresso.q9media.com> <20020202210237.A2326@descent.robbins.dropbear.id.au> <20020203174511.A6496@espresso.q9media.com> <20020204110944.A20748@descent.robbins.dropbear.id.au> 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 < said: > I think this should be -p1003.2-2001, but we don't have a macro for that. No. There is no such thing as 1003.2-2001, and will never be. The entire POSIX 2001 standard is 1003.1-2001. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sun Feb 3 23:31: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 CF4DB37B417 for ; Sun, 3 Feb 2002 23:31:17 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g147RUm33504; Mon, 4 Feb 2002 02:27:30 -0500 (EST) (envelope-from mike) Date: Mon, 4 Feb 2002 02:27:29 -0500 From: Mike Barcroft To: "Tim J. Robbins" Cc: freebsd-standards@FreeBSD.ORG Subject: Re: pwd -L option Message-ID: <20020204022729.D6496@espresso.q9media.com> References: <20020130181638.A8510@descent.robbins.dropbear.id.au> <20020202032917.K10222@espresso.q9media.com> <20020202210237.A2326@descent.robbins.dropbear.id.au> <20020203174511.A6496@espresso.q9media.com> <20020204110944.A20748@descent.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020204110944.A20748@descent.robbins.dropbear.id.au>; from tim@robbins.dropbear.id.au on Mon, Feb 04, 2002 at 11:09:44AM +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 Tim J. Robbins writes: > > This isn't quite right yet. realpath(1) should never call getopt(). > > It expects no options, so `realpath -L' should return a valid path > > ending with `/-L'. > > Conceptually pwd and realpath have something in common, but their > implementations don't. I don't agree with having realpath built in to > pwd. There's probably not much I can do about that, though. Agreed; realpath(1) should be broken out into its own source file. I'll add it to my TODO list. > Here's another attempt at a patch. Committed (with a few minor modifications), thanks! 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 5 17: 7:11 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 4503637B42A; Tue, 5 Feb 2002 17:07:04 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g1613Fn38428; Tue, 5 Feb 2002 20:03:15 -0500 (EST) (envelope-from mike) Date: Tue, 5 Feb 2002 20:03:15 -0500 From: Mike Barcroft To: standards@FreeBSD.org, developers@FreeBSD.org Subject: C99 & POSIX Conformance Job Positions Message-ID: <20020205200315.J6496@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 The FreeBSD C99 & POSIX Conformance Project seeks two persons to fill the following two job positions. Please e-mail mike@FreeBSD.org to apply. ---------------------------------------------------------------------- Position: Wide String Support Integrator Job Description: FreeBSD is currently lacking in its support for wide strings. In particular, C99 and POSIX.1-2001 require some 75 functions not currently found in FreeBSD. NetBSD and the Citrus project have gone to significant efforts to develop a number of these functions. Your job will be to integrate these functions into FreeBSD. Job applicants should already have a commit bit since the job mainly involves testing and committing already completed code. If you are accepted for this position, you will be expected to have your work reviewed by the -standards mailing list before committing. Pay: The satisfaction of a job well done. :) ---------------------------------------------------------------------- Position: Complex Numbers and Arithmetic Developer Job Description: C99 requires approximately 65 functions related to complex number arithmetic. These functions are mainly variants of the math(3) functions. Your job will be to develop these functions (most likely using libm sources as a starting point). Being a committer is not required for this position, but is helpful. As with the other job position, if you are accepted for this position, you will be expected to have your work reviewed by the -standards mailing list before committing. Pay: Free, lifetime use of an OS with complex number support. :) ---------------------------------------------------------------------- For more information on the FreeBSD C99 & POSIX Conformance Project see: 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 Tue Feb 5 23:50:22 2002 Delivered-To: freebsd-standards@freebsd.org Received: from opus.sandiegoca.ncr.com (tan7.ncr.com [192.127.94.7]) by hub.freebsd.org (Postfix) with ESMTP id 6806437B405 for ; Tue, 5 Feb 2002 23:50:04 -0800 (PST) Received: from localhost (chuckr@localhost) by opus.sandiegoca.ncr.com (8.11.6/8.11.6) with ESMTP id g167sQ807880; Tue, 5 Feb 2002 23:54:26 -0800 (PST) (envelope-from chuckr@opus.sandiegoca.ncr.com) Date: Tue, 5 Feb 2002 23:54:26 -0800 (PST) From: Chuck Rouillard To: FreeBSD-Standards Cc: Chuck Rouillard Subject: pathchk - review In-Reply-To: <20020129210829.GC50337@madman.nectar.cc> Message-ID: <20020205232519.N7805-101000@opus.sandiegoca.ncr.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-683405800-1012982066=:7805" 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-683405800-1012982066=:7805 Content-Type: TEXT/PLAIN; charset=US-ASCII A revised `pathchk' is being submitted for review. -- Jacques Vidrine suggested a number of changes to the first submission. All of his suggestions have been folded in. Thanks, .cr --0-683405800-1012982066=:7805 Content-Type: APPLICATION/octet-stream; name="pathchk.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: <20020205235426.N7805@opus.sandiegoca.ncr.com> Content-Description: Content-Disposition: attachment; filename="pathchk.tar.gz" H4sICCDgYDwAA3BhdGhjaGsudGFyAO1a+1PbSBLOr/ZfMcfVLYbIBhNIbpMl W8aIoF1js34kYW+vElkeYx2ypNUDwt7yv9/XPSNZNhBCQXb3qjxVCXr09PT0 8+uRQzuZOJOzjSP7TI5dTz75CqO+ufl8e1s8EaL+Ymez+FeP7edCvNjeelF/ Xn/+oo7Xz+o720/E5tcQZnGkcWJHQjxxJqlzFt1Od9f7/9Nx3O282S2FygvK 5ZrrO146kuK7YTyqhVFwWpuevS7/2VIux9ca2vIb+m+t/hXWuCP+n+/sbFH8 P9us79S3t7co/rd2dpbx/0eM2i8rohmEl5F7OklExVkTW5ubdYP+3xJN2rPo BqnreXY0KhNxw/MEE8cikrGMzuWoRi/4ZVeO3DiJ3GGauIEvbH8k0lgK1xdx kEaO5CdD17ejSzEOomlsiAs3mYgg4r9BmjCbaTByx65jExND2JEUoYymbpLI kUBOOndHuEgmdoL/JBh5XnDh+qfCCfyRS5NiZkMTpzJ5yTf12oJ0sQjGmVhO gJQ3hStgT4kNcYmvPQzO6ZVWDnPB8IPEdaQBEjcWHhgSn9nKvMV5sbCq49nu VEasKbF1XRQsWVBLJgr2Okoh3leSRqiNZqxGgZNOpZ/Yme02YJYABJGY2omM XNuLZ+pnuxHn4kbU/p7VRB8vfHsqSRqWPoV1ic8lSSyGkvwCkgVC+qMggo/g LXhPgySXR+0efjbC2nAzMcZ7tdE4GCcXZF7tNSIOpUMug0kuOVNEzuLnnMh7 4jgTkB/3D62e6HUO+u8aXVPgGpXwrbVv7ou9E7w0RWPQP+x0xcePjR5er66K Rnsf/06E+f64a/Z6zAUE1tFxy8I08Ok22n3L7BnCajdbg32r/cYQe4O+aHf6 omUdWX2Q9TsGs9fTmMtsqugciCOz2zzEbWPPaln9E173wOq3saY4wIINcdzo 9q3moNXoiuNB97jTM1VoYiP7Vq/ZalhH5n5NQAwsLcy3ZrsveoeNVqu4sT0T MjX2WqZi2j5hHvtW12z2aQezqybUAnFahugdm02LLsz3JuRvdE8MUkGz0+6Z Pw1AhJeKTeOo8QbbqdyhCSi9OeiaRyQhtt4b7PX6Vn/QN8WbTmc/13HP7L61 mmbvlWh1eqykQc80sEq/wQKADTSE17SvQc9iXVntvtntDo77Vqe9xpwOO++g DMjbwPR9VmynzTaFXjrdE2JMOmG9G+LdoYnnXVIjdtjvNkgdvX7XavaZXYEU 6/Y73X5hv6JtvmlZb8x206S3HeL0zuqZazCT1SMCSy39rqE03xmwCshCkE5d FlzUYDsK60A09t9aJL4mhvl7lnaVzgGz6g2ah9oEucOrf/sj8YPtp5RotlSS x7MEDtU/bB7+KOrlWge5szcR7cYRnKo9FRk0rLVHwplI5yzmRxTcirJ30u4c 96zePHUnFAeeCMu1RpTT802tVuNp+2av2bXYOOU+JaHCbOQSz00uxTkCf+zK WFxMJOchOwt0OZrnTImlkFRsx5FxTDnFiSRyFyZSc5OnCxlFQVQTe5fILWM7 9RKjTFkKGTayUd+IrcGpU9rOZH4lJ5iGgY80aQgkItYI1rRPUTViVY9SHwnL u6RcS4vGl3EipzXR8C91NizPkjELgv25VFVlDEkoKdsoW3Fsn0JuLwBVnmuD 8Rj5EhPnZYohDm07TrAyFZljKH7PE9Vh6nkStcJKlI6Lk6hegDm0ikqqKt7U /uRO0ykpxfWxq+Ele8aHo8Z7qksLuysXdnfzEqhDVE1RhfiZyHX3JSuTB9LK 5esri8WVGwXWWsdzglxMXGdC9qLiE0s7cib20OOig6rLzsL3WJbmfmalZr4l mBNcIttBaazEa0KtQUXJ9c9tzx3lKtNqUMU3kk4SRJfgZnpsKPjFjVojchsC +1X5CSWWtragRL0f0McoyRG5oa88SrjjMmbm5TeSU80xn01zlXhFrxee9E/x R35yJGMsCi02TVy0zefMgS1R9Q9CDUCgEDvW+CN+qfwysU9F9cIdYSUXbHx2 UZUw3lLMX94QeGlMS4VBlNhDlR50OqLAk/Yo2+st4deVNLVs51FYgESQTwci gojUGXjy4VH0AZnZev8hi6BHixHwfQ++WXzcyRecpE3AEP6Qe6yYCwmNeGPJ 4dOo/ozsV/3NEJvVb43yx9pqBQjKDUZrhvhYXa1MLsOJ9HEDB/r4YbXCGo+d IJJrCvkViAqQr8zZGbpm5bsRRJqJg2XJNPMq0EGiA6VYIRAS8OBN7EnEKcev Ierw+lkEBI6TRhE3J1SkTOCeVq9Trr2PkCahky1h8A1zDPyx2FKEfaCCRhfQ 47aiBJXJT6hCiSo1NJcgexJgfiKqcRqfb8HNRuo2RPP7rLYlan/RM5TF/t/5 Cmt8vv8HCHn2Qvf/zzep7UT//2y7vuz//4ixsS7KYv3LjwBAe+MJgFinV4/Q /4PLI7T/4JJ3/7h+ePMPJg/u/cHjUVr/h8uSdf6K06M0/mD10L5fSfMIbb9m VOj6lXs+vOcHk4e3/GDyCB0/ReIDG36weIR+n7g8Uruv1PsI3T4YPWKzD26P 1+vTHh+n1QenuU5frG+U/55/wAHw3SCkU5u8XniaXIYypseF5wBNfjBP6rnI ufHCs8CxgY3nWSYjN7j2yHOHi88iJKH5Z6mPHDJiUQh2K0Ao1lFr5Knt8c2u WNHY5KWw1PMZbFx5NTdvKqdorRT+K85rB0K94rMBjzaRyIW5lLWSIOB+uzj3 eB6Ug4SB+cJsTT6RXkizU2reX2bQUfyrGv5bQdtarfaLf8Pc21bmXHrbmkHs fvpA1zHN26xvPdveef7in9/WPlRXyqVSaaWx19w3D94cWj/82Dpqd45/6vb6 g7fv3p/8rN7bQwdN3enE/c+ZN/WD8Fdg8vT84tPlb1hqg1NmiwwuxqnvcHFA ck4C5T/sbi51pSQHSV1Rcq29Uo9lpSitgZqT6FeqJ5ufch64BBagtwpd4omW QDeErL5i9zfUDSBVNperzUuV+KtsLnRsUk2iQkidIOvyu93FvszIZlHLea0H U+3wbFbWdeWzVJkFFrlpet6E+YEuSlQ1yQMv5GjmxqxMAIMkjXw0NXRugD6G ziVCxjx8HFVXJfnCjWWu+/Ki7rP2b63833KJVE032ITBTPgiOre9V+XSzOsN NS1/dqHWw98kghVKeiZ8DCGMi0q+CKZA85WM4PWiatcEpCgpe45Rov1kXFFn VIZY+Uf8i0//VpRsOgIMUeReipRO6ri+gijwiBKhVXWoF4e2w+BS9bKI7SFg KlpMwecvIBkxOXGsiUHI4OZS9YcaN7G9CFlMgguficGOWktuHslVkUGh7xIp nDfLu4UuppxH8r0/FfW1NbG7K9qDVuvOfWPPhVzFO6WOtlJf442W1vUixAwm yH4nQQGRDeR+pFH02jBKLMNVCOSfelJ11yrXYlv6YNBNjOLM/FD0IojOFHIO +VgknKUchLoC98WJfFwEEAq86gFgnzJsJG2nsoYsm0gVCrZfnGSPFCTFlGy9 MIBOCIbGfOZADg9cWJzEKPPjOJJytVZ4vpFfsy0utJ6w31EazhxzzhJiYdzH LotzcytlD67yKwoXiHKhYin31T0JbSk/015JebSYvPLEwfSz5KHSwKU+i0Me 0MmIMg6eM/VN2aQSr2UOS7EOmTbhVYgRT0JlbF7WGLym8o0O9pWNFSjtb0X3 ZQXr9DGLfa1eUG4qMu3meI2iWlHc8vBlJhmP14s5VDO4O0EwValUKNEqTag1 sl3W1d0Qzn3Gl1eZBOtq07titboqfv+dyUgBodqPIQqllPemRb6vgAXc8sUC XmlVK1fOLHCLYslMKkNQZFTI5eieb7L1dMpUaf4qq6KNOEawEvjR52NcxFVz TQvr80/ytTAptIeOjR7tAnVH6gPKDf6QMgqkOjnks+lCPZov+kpqqkO0HBel GJENf6/wA9Ivr2C2O+gJXs4yPrms/jZDT0OWr5KBI9bCHQk213+m76tyoZzk imlSGKpjep3y8yR480cdmjQ7WFZRqk8gbzhJ589IZV2ErgGLrDG1VLd8/Xzf nn0x4Lh34xzk0ASPznVnE16KTHsZEZnoBsJhOvcZ5Pq8eXqDJyx8O8kn1e/e BPvMnfJ/sfg3LX3t+LxC65Ezyl9x66mPFrhytcuzHdXRgp2oirRG0o6D1OcT ity9CSsgfwW+YkIT5yydfShclICCK/tACDeheRRfceyey4IDqMi5honnoByy QOooNML/DdPxqwWARxdT+5N+nMM9uig81hu6NwjU1Ww/IGTq+ijo3Idx7ARi BLAdTV1fqs9iEV6jbeAZOrGQjhCoU/6MoRBDnFUpJZROkLqi59vntL2xKr6n 5AfLr9TQm5T0ZkGYnd8rXGagxjRnBUbzu50yR6oayuZ8d0W1jlIh8un0oFAY c5lDmcMOQ3AXrdBHnXP4Xwu/3onk/wxwmynlnnC2dG8cW7oXgC3dC7mWFiFr oWH4IpD6II1+FehZCNyI6JDEsk/B/GOGWXSLioYNNC3/YM3aAmv6NE4/b5C+ 8uZxGvHRciIVDWdP7CY/ZPhLgVcV5xkQpCcUUZr0G52K14rpAYP0TyP3as7b YxubGBk6a3KqYHCQkZIiKI4zgJZ/ihZVpd9qTuoWSi1BMX9VlypRUUiKOgBF u6EubkxaCwlLib/Y8mRjHsQWYaxG2qUrIT1guetKaKiP5Nm33zxpJeQX7JpG Tnuujnv44wF1Now1CoBqTl0LBTf/qQJV24yuCO2KP1SY188tBeV6PaFxS025 XlIyzX9JWblmJf2s9DljXe8uFiyjTZNZqLxoJm2lBfg251OGyppAPxkp+NMH J9fJfoJBSCeZBOA6tOn7TuBnpAoozf225LrhMmKNicRRZkfim3FkEJhR6o/+ 4xQghHAY5Xltilq5aNj5BlTbIVfelzZ2t7aei8ovqP4qX392PqbNfv/1r52Q feH6f0iHSVzKhaNbAqx392b6uJwY5sUMzAgL04+VKi4j6FPH0L3kOm7O83PN yvqYRKusaWALsnDs2aca2go6t6R76OaGOuLg/hQGDZOKWoJ4Q7xQF5IsJrNm 1VG33KquhqvUkebslepzxSua75mm0MCWlH7YbFesX1pYVHf5h1L+6BU/OBdP Cw/IaEy1SwWrXOQxVhW/ooXggvZ94VwdQDk/Gp7tm5hVq8SJdfI7GCgtsm6f Ps1tQa/ZHH/2zxOWYzmWYzmWYzmWYzmWYzmWYzmWYzmWYzmWYzmWYzmWYzmW YzmW457jf03uOWYAUAAA --0-683405800-1012982066=:7805-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Feb 6 0:59:34 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (158.b.006.mel.iprimus.net.au [210.50.45.158]) by hub.freebsd.org (Postfix) with ESMTP id D64BC37B436 for ; Wed, 6 Feb 2002 00:59:29 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g168uUJ37860; Wed, 6 Feb 2002 19:56:30 +1100 (EST) (envelope-from tim) Date: Wed, 6 Feb 2002 19:56:29 +1100 From: "Tim J. Robbins" To: Chuck Rouillard Cc: freebsd-standards@FreeBSD.ORG Subject: Re: pathchk - review Message-ID: <20020206195629.A37672@descent.robbins.dropbear.id.au> References: <20020129210829.GC50337@madman.nectar.cc> <20020205232519.N7805-101000@opus.sandiegoca.ncr.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: <20020205232519.N7805-101000@opus.sandiegoca.ncr.com>; from chuckr@opus.sandiegoca.ncr.com on Tue, Feb 05, 2002 at 11:54:26PM -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 Tue, Feb 05, 2002 at 11:54:26PM -0800, Chuck Rouillard wrote: > A revised `pathchk' is being submitted for review. In pathchk.1, it'd be good to change .Pp .Nm pathchk exits 0 on success, 1 if an error occurred. to: .Sh DIAGNOSTICS .Ex -std There is a typo here, should be _POSIX_NAME_MAX: The .Ar pathname contains a path component longer than the maximum _POXIX_NAME_MAX. mdoc(7) recommends the SEE ALSO section be alphabetised. In pathchk.c, I think it'd be better to use the warn and err family of functions instead of fprintf and perror ("Use err(3) or warn(3), do not roll your own.") The \n should probably be removed here, since it is later added by fprintf in usage(): const char *pathchkhelp = "usage: pathchk [-p] path ...\n"; The lines that say *path = NULL; should be *path = '\0'; Other than those few nits, it looks fine. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Feb 6 10: 6:57 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 2A6AC37B400 for ; Wed, 6 Feb 2002 10:06:55 -0800 (PST) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.11.4/8.11.4) id g16I6s653991; Wed, 6 Feb 2002 13:06:54 -0500 (EST) (envelope-from wollman) Date: Wed, 6 Feb 2002 13:06:54 -0500 (EST) From: Garrett Wollman Message-Id: <200202061806.g16I6s653991@khavrinen.lcs.mit.edu> To: freebsd-standards@FreeBSD.ORG Subject: Re: pathchk - review In-Reply-To: <20020206195629.A37672@descent.robbins.dropbear.id.au> References: <20020129210829.GC50337@madman.nectar.cc> <20020205232519.N7805-101000@opus.sandiegoca.ncr.com> <20020206195629.A37672@descent.robbins.dropbear.id.au> 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 < said: > There is a typo here, should be _POSIX_NAME_MAX: > The > .Ar pathname > contains a path component longer than the maximum _POXIX_NAME_MAX. I asked ru for a macro that would represent the names of POSIX parameters; I don't recall what the ultimate upshot was, but in any case that should probably be spelled {_POSIX_NAME_MAX}. (.Brq Dv WHATEVER should do it, but I wanted to see a macro other than generic Dv.) -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Feb 6 10:43: 7 2002 Delivered-To: freebsd-standards@freebsd.org Received: from stanhope.uia.ac.be (stanhope.uia.ac.be [143.169.32.57]) by hub.freebsd.org (Postfix) with ESMTP id 8B9AA37B41B for ; Wed, 6 Feb 2002 10:43:03 -0800 (PST) Received: from verdonk (helo=localhost) by stanhope.uia.ac.be with local-esmtp (Exim 3.33 #1 (Debian)) id 16YX24-0000mR-00 for ; Wed, 06 Feb 2002 19:43:00 +0100 Date: Wed, 6 Feb 2002 19:42:57 +0100 (CET) From: Brigitte Verdonk X-X-Sender: verdonk@stanhope.uia.ac.be Reply-To: verdonk@uia.ua.ac.be To: standards@FreeBSD.org Subject: Re: Possible math problems Message-ID: 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 The following may take away some of the confusion about the errors reported in multiplication and division on the IeeeCC754 website. As already reported, the errors only occur on extended-based platforms such as Intel, Athlon, ... and not on single-double based architectures (such as SUN). As you may also have noticed, the reported errors are always underflow cases. The cause for the errors can be traced back to a 'hole' in the IEEE 754 standard, where it is stated that extended-based architectures shall be able to mimick single or double precision, EXCEPT in the absence of underflow/overflow. What happens is that on extended based architectures, when mimicking double precision, only the precision is mimicked and not the exponent range (15 bits are allocated for the exponent, rather than 11 as in double precision). Usually this is not a problem, except in some cases of underflow where double rounding can cause "erroneous" results. Indeed, what happens on an extended-based architecture mimicking double (or single) precision, is that 1. the exact result of an operation is first rounded to 53 bits precision and exponent range represented in 15 bits 2. then this rounded result is stored in true double precision format (53 bits precision, 11 bits exponent). This entails no double rounding (53 bits precision in both cases), except when the final result needs to be denormalized due to underflow. In such cases, the extended based architectures should denormalize the 'exact' result of the operation, but instead denormalize the intermediate result (computed in 53 bits precision and extended exponent range). More details on this issue and on underflow in general can be found in ftp://wins.uia.ac.be/u/preprints/99/underflow.ps By the way, any further feedback on the testing tool IeeeCC754 is very much appreciated. Please let me know about any problems, requests for additional features, etc. Also, I would be very happy to include logfiles for additional platforms/architectures to our website. All contributions will be greatly appreciated. Best regards, Brigitte Verdonk ----------------------------Brigitte Verdonk---------------------------------- Dept. of Math. and Comp. Sc. Tel. +32 3 820.24.03 University of Antwerp (UIA) Fax. +32 3 820.24.21 Universiteitsplein 1 URL: http://www.uia.ac.be/u/verdonk B2610 Wilrijk-Antwerp (Belgium) Email: verdonk@uia.ua.ac.be ------------------------------------------------------------------------------ "Alice laughed: "There's no use trying," she said; "one can't believe impossible things." "I daresay you haven't had much practice," said the Queen. "When I was younger, I always did it for half an hour a day. Why, sometimes I've believed as many as six impossible things before breakfast." Lewis Carroll To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Wed Feb 6 11:31:15 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 0312237B404; Wed, 6 Feb 2002 11:31:11 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g16JROw83819; Wed, 6 Feb 2002 14:27:24 -0500 (EST) (envelope-from mike) Date: Wed, 6 Feb 2002 14:27:24 -0500 From: Mike Barcroft To: standards@FreeBSD.org, developers@FreeBSD.org Subject: Re: C99 & POSIX Conformance Job Positions Message-ID: <20020206142724.O6496@espresso.q9media.com> References: <20020205200315.J6496@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020205200315.J6496@espresso.q9media.com>; from mike@FreeBSD.org on Tue, Feb 05, 2002 at 08:03:15PM -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 Mike Barcroft writes: > The FreeBSD C99 & POSIX Conformance Project seeks two persons to fill > the following two job positions. Please e-mail mike@FreeBSD.org to > apply. Thanks for all the replies. I'm happy to say that we have filled these two positions. But if you are interested in working on this project, don't let this discourage you. There are still many more tasks to be completed. Feel free to contact me privately for details. 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 Wed Feb 6 11:48: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 4FE6737B404 for ; Wed, 6 Feb 2002 11:48:52 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g16Jj5Q84768; Wed, 6 Feb 2002 14:45:05 -0500 (EST) (envelope-from mike) Date: Wed, 6 Feb 2002 14:45:05 -0500 From: Mike Barcroft To: standards@FreeBSD.org Cc: "David E. Cross" , Kelly Yancey , Mark Murray Subject: Re: C99 & POSIX Conformance Job Positions Message-ID: <20020206144505.P6496@espresso.q9media.com> References: <20020205200315.J6496@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020205200315.J6496@espresso.q9media.com>; from mike@FreeBSD.org on Tue, Feb 05, 2002 at 08:03:15PM -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 Mike Barcroft writes: > The FreeBSD C99 & POSIX Conformance Project seeks two persons to fill > the following two job positions. Please e-mail mike@FreeBSD.org to > apply. Please help me show our appreciation in welcoming the three people that will be working on these tasks. > Position: Wide String Support Integrator David E. Cross and Kelly Yancey will be sharing this position. I understand David has some past experience with wide strings, which will no doubt come in handy. :) If I'm not mistaken, I think we require a few functions in order to complete some other tasks, in particular printf(3). Perhaps we can persuade them to complete those functions first. > Position: Complex Numbers and Arithmetic Developer Mark Murray has volunteered for this post. Here's hoping Mark really like math. :) 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 Wed Feb 6 14:31:50 2002 Delivered-To: freebsd-standards@freebsd.org Received: from opus.sandiegoca.ncr.com (tan7.ncr.com [192.127.94.7]) by hub.freebsd.org (Postfix) with ESMTP id D0D9737B422 for ; Wed, 6 Feb 2002 14:31:47 -0800 (PST) Received: from localhost (chuckr@localhost) by opus.sandiegoca.ncr.com (8.11.6/8.11.6) with ESMTP id g16MZfZ09176; Wed, 6 Feb 2002 14:35:41 -0800 (PST) (envelope-from chuckr@opus.sandiegoca.ncr.com) Date: Wed, 6 Feb 2002 14:35:41 -0800 (PST) From: Chuck Rouillard To: "Tim J. Robbins" Cc: , Chuck Rouillard Subject: Re: pathchk - review In-Reply-To: <20020206195629.A37672@descent.robbins.dropbear.id.au> Message-ID: <20020206142317.S9114-100000@opus.sandiegoca.ncr.com> 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 Wed, 6 Feb 2002, Tim J. Robbins wrote: > On Tue, Feb 05, 2002 at 11:54:26PM -0800, Chuck Rouillard wrote: > > > A revised `pathchk' is being submitted for review. [snip] > In pathchk.c, I think it'd be better to use the warn and err family of > functions instead of fprintf and perror ("Use err(3) or warn(3), do not roll > your own.") Well, I chose fprintf and perror for appearance reasons. The SUS spec. says we must indicate the error detected and the offending pathname. The appearance issue arises when _long_ pathnames are encountered and, by design, the err/warn family of functions -appends- the error string. Thus, the error string seems lost when appended to such _long_ pathnames. Use of fprintf elsewhere is solely for consistency. Thoughts? > Other than those few nits, it looks fine. Thanks! > Tim > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Feb 8 4:36:29 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (087.c.003.mel.iprimus.net.au [210.50.33.87]) by hub.freebsd.org (Postfix) with ESMTP id 54C0637B421 for ; Fri, 8 Feb 2002 04:36:14 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g18CbmM41490 for freebsd-standards@FreeBSD.ORG; Fri, 8 Feb 2002 23:37:48 +1100 (EST) (envelope-from tim) Date: Fri, 8 Feb 2002 23:37:47 +1100 From: Tim Robbins To: freebsd-standards@FreeBSD.ORG Subject: tr -C option patch Message-ID: <20020208233747.A41428@descent.robbins.dropbear.id.au> 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 This patch adds the -C option to tr, as well as fixing PR bin/34663, tr -c "" causing bogus results. Unless I'm mistaken, the "in ascending collation sequence, as defined by the current setting of LC_COLLATE" procedure isn't necessary. Although the standard says "An empty string used for string1 or string2 produces undefined results", the current behaviour with -c and an empty string1 is clearly not what was intended. 4.3BSD's tr behaviour is evidence of this. Equivalence classes are not correctly implemented by tr yet. From str.c: * English doesn't have any equivalence classes, so for now * we just syntax check and grab the character. ... this patch doesn't address this problem. Index: tr/tr.1 =================================================================== RCS file: /home/ncvs/src/usr.bin/tr/tr.1,v retrieving revision 1.14 diff -u -r1.14 tr.1 --- tr/tr.1 2001/08/15 09:09:44 1.14 +++ tr/tr.1 2002/02/08 12:09:48 @@ -43,19 +43,23 @@ .Nd translate characters .Sh SYNOPSIS .Nm -.Op Fl csu +.Op Fl C | c +.Op Fl su .Ar string1 string2 .Nm -.Op Fl cu .Fl d +.Op Fl C | c +.Op Fl u .Ar string1 .Nm -.Op Fl cu .Fl s +.Op Fl C | c +.Op Fl u .Ar string1 .Nm -.Op Fl cu .Fl ds +.Op Fl C | c +.Op Fl u .Ar string1 string2 .Sh DESCRIPTION The @@ -65,18 +69,20 @@ .Pp The following options are available: .Bl -tag -width Ds +.It Fl C +Complement the set of characters in +.Ar string1 +according to the current locale. .It Fl c -Complements the set of characters in +Complement the set of values in .Ar string1 , -that is ``-c ab'' includes every character except for ``a'' and ``b''. +that is ``-c ab'' includes every value except for ``a'' and ``b''. .It Fl d -The -.Fl d -option causes characters to be deleted from the input. +Delete characters in +.Ar string1 +from the input. .It Fl s -The -.Fl s -option squeezes multiple occurrences of the characters listed in the last +Squeeze multiple occurrences of the characters listed in the last operand (either .Ar string1 or @@ -84,9 +90,7 @@ in the input into a single instance of the character. This occurs after all deletion and translation is completed. .It Fl u -The -.Fl u -option guarantees that any output is unbuffered. +Guarantee that any output is unbuffered. .El .Pp In the first synopsis form, the characters in @@ -283,20 +287,22 @@ .Sh STANDARDS The .Nm -utility is expected to be -.St -p1003.2 -compatible. -It should be noted that the feature wherein the last character of +utility is expected to be compliant with the +.St -p1003.1-2001 +specification. +.Pp +The feature wherein the last character of .Ar string2 is duplicated if .Ar string2 has less characters than .Ar string1 -is permitted by POSIX but is not required. -Shell scripts attempting to be portable to other POSIX systems should use +is permitted by +but is not required. +Shell scripts attempting to be portable to other +systems should use the ``[#*]'' convention instead of relying on this behavior. +.Pp The .Fl u -option is an extension to the -.St -p1003.2 -standard. +option is an extension to the standard. Index: tr/tr.c =================================================================== RCS file: /home/ncvs/src/usr.bin/tr/tr.c,v retrieving revision 1.9 diff -u -r1.9 tr.c --- tr/tr.c 2001/12/11 23:36:25 1.9 +++ tr/tr.c 2002/02/08 12:09:53 @@ -47,6 +47,7 @@ #include +#include #include #include #include @@ -56,6 +57,12 @@ #include "extern.h" +/* + * For -C option: determine whether a byte is a valid character in the + * current character set as defined by LC_CTYPE. + */ +#define ISCHAR(c) (iscntrl(c) || isprint(c)) + static int string1[NCHARS] = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, /* ASCII */ 0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, @@ -94,7 +101,7 @@ STR s1 = { STRING1, NORMAL, 0, OOBCH, { 0, OOBCH }, NULL, NULL }; STR s2 = { STRING2, NORMAL, 0, OOBCH, { 0, OOBCH }, NULL, NULL }; -static void setup __P((int *, char *, STR *, int)); +static void setup __P((int *, char *, STR *, int, int)); static void usage __P((void)); int @@ -103,13 +110,16 @@ char **argv; { int ch, cnt, lastch, *p; - int cflag, dflag, sflag, isstring2; + int Cflag, cflag, dflag, sflag, isstring2; (void) setlocale(LC_CTYPE, ""); - cflag = dflag = sflag = 0; - while ((ch = getopt(argc, argv, "cdsu")) != -1) + Cflag = cflag = dflag = sflag = 0; + while ((ch = getopt(argc, argv, "Ccdsu")) != -1) switch((char)ch) { + case 'C': + Cflag = 1; + break; case 'c': cflag = 1; break; @@ -143,7 +153,7 @@ } /* - * tr -ds [-c] string1 string2 + * tr -ds [-C|-c] string1 string2 * Delete all characters (or complemented characters) in string1. * Squeeze all characters in string2. */ @@ -151,8 +161,8 @@ if (!isstring2) usage(); - setup(string1, argv[0], &s1, cflag); - setup(string2, argv[1], &s2, 0); + setup(string1, argv[0], &s1, cflag, Cflag); + setup(string2, argv[1], &s2, 0, 0); for (lastch = OOBCH; (ch = getchar()) != EOF;) if (!string1[ch] && (!string2[ch] || lastch != ch)) { @@ -163,14 +173,14 @@ } /* - * tr -d [-c] string1 + * tr -d [-C|-c] string1 * Delete all characters (or complemented characters) in string1. */ if (dflag) { if (isstring2) usage(); - setup(string1, argv[0], &s1, cflag); + setup(string1, argv[0], &s1, cflag, Cflag); while ((ch = getchar()) != EOF) if (!string1[ch]) @@ -179,11 +189,11 @@ } /* - * tr -s [-c] string1 + * tr -s [-C|-c] string1 * Squeeze all characters (or complemented characters) in string1. */ if (sflag && !isstring2) { - setup(string1, argv[0], &s1, cflag); + setup(string1, argv[0], &s1, cflag, Cflag); for (lastch = OOBCH; (ch = getchar()) != EOF;) if (!string1[ch] || lastch != ch) { @@ -194,7 +204,7 @@ } /* - * tr [-cs] string1 string2 + * tr [-C|-c] [-s] string1 string2 * Replace all characters (or complemented characters) in string1 with * the character in the same position in string2. If the -s option is * specified, squeeze all the characters in string2. @@ -205,7 +215,7 @@ s1.str = argv[0]; s2.str = argv[1]; - if (cflag) + if (cflag || Cflag) for (cnt = NCHARS, p = string1; cnt--;) *p++ = OOBCH; @@ -213,6 +223,7 @@ errx(1, "empty string2"); /* If string2 runs out of characters, use the last one specified. */ + ch = s2.lastch; if (sflag) while (next(&s1)) { string1[s1.lastch] = ch = s2.lastch; @@ -225,9 +236,10 @@ (void)next(&s2); } - if (cflag) + if (cflag || Cflag) for (cnt = 0, p = string1; cnt < NCHARS; ++p, ++cnt) - *p = *p == OOBCH ? ch : cnt; + *p = (*p == OOBCH && (!Cflag || ISCHAR(cnt))) ? + ch : cnt; if (sflag) for (lastch = OOBCH; (ch = getchar()) != EOF;) { @@ -244,30 +256,31 @@ } static void -setup(string, arg, str, cflag) +setup(string, arg, str, cflag, Cflag) int *string; char *arg; STR *str; int cflag; + int Cflag; { - int cnt, *p; + int cnt; str->str = arg; bzero(string, NCHARS * sizeof(int)); while (next(str)) string[str->lastch] = 1; - if (cflag) - for (p = string, cnt = NCHARS; cnt--; ++p) - *p = !*p; + if (cflag || Cflag) + for (cnt = 0; cnt < NCHARS; cnt++) + string[cnt] = !string[cnt] && (!Cflag || ISCHAR(cnt)); } static void usage() { (void)fprintf(stderr, "%s\n%s\n%s\n%s\n", - "usage: tr [-csu] string1 string2", - " tr [-cu] -d string1", - " tr [-cu] -s string1", - " tr [-cu] -ds string1 string2"); + "usage: tr [-C|-c] [-su] string1 string2", + " tr -d [-C|-c] [-u] string1", + " tr -s [-C|-c] [-u] string1", + " tr -ds [-C|-c] [-u] string1 string2"); exit(1); } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Feb 8 7:44:21 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (092.a.005.mel.iprimus.net.au [210.50.40.92]) by hub.freebsd.org (Postfix) with ESMTP id DA1B337B41B for ; Fri, 8 Feb 2002 07:44:09 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g18FhK042820 for freebsd-standards@FreeBSD.ORG; Sat, 9 Feb 2002 02:43:20 +1100 (EST) (envelope-from tim) Date: Sat, 9 Feb 2002 02:43:19 +1100 From: Tim Robbins To: freebsd-standards@FreeBSD.ORG Subject: tr equivalence class support Message-ID: <20020209024319.A42708@descent.robbins.dropbear.id.au> 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 This patch adds equivalence class support to tr, and an example to the manual page to show what it can be used for. It could be better implemented if some of the data structures or functions from libc/locale/collate.c were exported; right now it relies on the fact that strxfrm() writes the primary collation value to the output string, which may not be true forever. Index: tr/extern.h =================================================================== RCS file: /home/ncvs/src/usr.bin/tr/extern.h,v retrieving revision 1.2 diff -u -r1.2 extern.h --- tr/extern.h 1997/08/18 07:24:54 1.2 +++ tr/extern.h 2002/02/08 15:39:15 @@ -33,18 +33,18 @@ * @(#)extern.h 8.1 (Berkeley) 6/6/93 */ +#include +#define NCHARS (UCHAR_MAX + 1) /* Number of possible characters. */ +#define OOBCH (UCHAR_MAX + 1) /* Out of band character value. */ + typedef struct { enum { STRING1, STRING2 } which; enum { EOS, INFINITE, NORMAL, RANGE, SEQUENCE, SET } state; int cnt; /* character count */ int lastch; /* last character */ - int equiv[2]; /* equivalence set */ + int equiv[NCHARS]; /* equivalence set */ int *set; /* set of characters */ char *str; /* user's string */ } STR; - -#include -#define NCHARS (UCHAR_MAX + 1) /* Number of possible characters. */ -#define OOBCH (UCHAR_MAX + 1) /* Out of band character value. */ int next __P((STR *)); Index: tr/str.c =================================================================== RCS file: /home/ncvs/src/usr.bin/tr/str.c,v retrieving revision 1.11 diff -u -r1.11 str.c --- tr/str.c 2001/12/11 23:36:25 1.11 +++ tr/str.c 2002/02/08 15:39:15 @@ -54,6 +54,7 @@ static int backslash __P((STR *)); static int bracket __P((STR *)); static int c_class __P((const void *, const void *)); +static u_long collval __P((char)); static void genclass __P((STR *)); static void genequiv __P((STR *)); static int genrange __P((STR *)); @@ -217,19 +218,43 @@ } /* - * English doesn't have any equivalence classes, so for now - * we just syntax check and grab the character. + * Get the primary collation value for a character. This is a hack, + * needed until libc can do this for us. */ +static u_long +collval(c) + char c; +{ + char buf[2], xbuf[32]; + u_long v; + int i, n; + + buf[0] = c; + buf[1] = '\0'; + if ((n = strxfrm(xbuf, buf, sizeof(xbuf))) >= (int)sizeof(xbuf)) + n = sizeof(xbuf); + for (v = 0, i = 0; i < n; i++) { + v <<= 8; + v |= (unsigned char)xbuf[i]; + } + + return v; +} + static void genequiv(s) STR *s; { + u_long cvc; + int i, *p; + char c; + if (*s->str == '\\') { - s->equiv[0] = backslash(s); + c = backslash(s); if (*s->str != '=') errx(1, "misplaced equivalence equals sign"); } else { - s->equiv[0] = s->str[0]; + c = s->str[0]; if (s->str[1] != '=') errx(1, "misplaced equivalence equals sign"); } @@ -237,6 +262,12 @@ s->cnt = 0; s->state = SET; s->set = s->equiv; + + cvc = collval(c); + for (p = s->equiv, i = 1; i < NCHARS; i++) + if (collval((char)i) == cvc) + *p++ = i; + *p = OOBCH; } static int Index: tr/tr.1 =================================================================== RCS file: /home/ncvs/src/usr.bin/tr/tr.1,v retrieving revision 1.14 diff -u -r1.14 tr.1 --- tr/tr.1 2001/08/15 09:09:44 1.14 +++ tr/tr.1 2002/02/08 15:39:16 @@ -203,10 +203,6 @@ Represents all characters or collating (sorting) elements belonging to the same equivalence class as .Ar equiv . -If -there is a secondary ordering within the equivalence class, the characters -are ordered in ascending sequence. -Otherwise, they are ordered after their encoded values. An example of an equivalence class might be ``c'' and ``ch'' in Spanish; English has no equivalence classes. .It [#*n] @@ -245,6 +241,10 @@ Strip out non-printable characters from file1. .Pp .D1 Li "tr -cd \*q[:print:]\*q < file1" +.Pp +Strip diacritical marks from accented variants of the ``e'' character. +.Pp +.D1 Li "tr \*q[=e=]\*q \*qe\*q < file1" .Sh COMPATIBILITY System V has historically implemented character ranges using the syntax ``[c-c]'' instead of the ``c-c'' used by historic Index: tr/tr.c =================================================================== RCS file: /home/ncvs/src/usr.bin/tr/tr.c,v retrieving revision 1.9 diff -u -r1.9 tr.c --- tr/tr.c 2001/12/11 23:36:25 1.9 +++ tr/tr.c 2002/02/08 15:39:17 @@ -105,6 +105,7 @@ int ch, cnt, lastch, *p; int cflag, dflag, sflag, isstring2; + (void) setlocale(LC_COLLATE, ""); (void) setlocale(LC_CTYPE, ""); cflag = dflag = sflag = 0; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Feb 8 17:36:52 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 03B4137B420 for ; Fri, 8 Feb 2002 17:36:49 -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 g191ali30336 for ; Fri, 8 Feb 2002 18:36:47 -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 g191akL55599 for ; Fri, 8 Feb 2002 18:36:47 -0700 (MST) (envelope-from imp@village.org) Date: Fri, 08 Feb 2002 18:36:40 -0700 (MST) Message-Id: <20020208.183640.89249665.imp@village.org> To: standards@FreeBSD.ORG Subject: diff problem From: "M. Warner Losh" 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 We have a problem with out diff. Given file foo1 and foo2. foo1 has a newline at the end, while foo2 doesn't. Diff produces: % diff -c ~/foo[12] *** /dell/imp/foo1 Fri Feb 8 18:05:26 2002 --- /dell/imp/foo2 Fri Feb 8 18:05:31 2002 *************** *** 1 **** ! this is a test --- 1 ---- ! this is a test % It should produce a warning about no newline at the end of the file, but doesn't. At least that's my take. What do standards have to say? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Feb 8 18:29:26 2002 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 9B7E337B41C for ; Fri, 8 Feb 2002 18:29:23 -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 g192T8p09704; Fri, 8 Feb 2002 21:29:08 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020208.183640.89249665.imp@village.org> References: <20020208.183640.89249665.imp@village.org> Date: Fri, 8 Feb 2002 21:29:07 -0500 To: "M. Warner Losh" , standards@FreeBSD.ORG From: Garance A Drosihn Subject: Re: diff problem Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) 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 6:36 PM -0700 2/8/02, M. Warner Losh wrote: >We have a problem with out diff. Given file foo1 and foo2. foo1 has >a newline at the end, while foo2 doesn't. Diff produces: > >% diff -c ~/foo[12] >*** /dell/imp/foo1 Fri Feb 8 18:05:26 2002 >--- /dell/imp/foo2 Fri Feb 8 18:05:31 2002 >*************** >*** 1 **** >! this is a test >--- 1 ---- >! this is a test >% > >It should produce a warning about no newline at the end of the file, >but doesn't. At least that's my take. What do standards have to say? Well, I wouldn't call it a warning so much as a information/marker line (since it's part of the diff output, and not going to stderr). The SingleUnixSpec v3 does not mention this issue, but I know the gnu version of diff would treat this as: (20) diff gadtest1 gadtest2 1c1 < This is a test --- > This is a test \ No newline at end of file I also know that the fact that our diff does not do *something* useful in this situation is rather irritating to developers of source-code management programs, such as the 'subversion' folks. Now you might say "But isn't that our diff?". Well, yes, but if you check the change log at http://www.FreeBSD.org/cgi/cvsweb.cgi/src/contrib/diff/util.c you'll see that the freebsd project (in 1997) explicitly removed the code which printed out that helpful marker line. You can imagine that this *really* annoys the people who are looking for that informational marker-line to exist... http://cvsweb.netbsd.org/bsdweb.cgi/gnusrc/gnu/dist/diffutils/util.c implies that netbsd's diff does include the marker line. http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/diff/util.c implies that openbsd's diff also includes the marker line. Offhand, I'd say we're the weird one out, and that I don't see any benefit in having a less informative output from diff... -- 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 Fri Feb 8 18:36: 3 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 EC7D137B419 for ; Fri, 8 Feb 2002 18:36:01 -0800 (PST) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g192VwW48852; Fri, 8 Feb 2002 21:31:58 -0500 (EST) (envelope-from mike) Date: Fri, 8 Feb 2002 21:31:58 -0500 From: Mike Barcroft To: "M. Warner Losh" Cc: standards@FreeBSD.ORG Subject: Re: diff problem Message-ID: <20020208213158.D73757@espresso.q9media.com> References: <20020208.183640.89249665.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020208.183640.89249665.imp@village.org>; from imp@village.org on Fri, Feb 08, 2002 at 06:36:40PM -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: > We have a problem with out diff. Given file foo1 and foo2. foo1 has > a newline at the end, while foo2 doesn't. Diff produces: > > % diff -c ~/foo[12] > *** /dell/imp/foo1 Fri Feb 8 18:05:26 2002 > --- /dell/imp/foo2 Fri Feb 8 18:05:31 2002 > *************** > *** 1 **** > ! this is a test > --- 1 ---- > ! this is a test > % > > It should produce a warning about no newline at the end of the file, > but doesn't. At least that's my take. What do standards have to say? SUSv3 doesn't specificly mention this case. Since text files always end with a newline, I think we should treat these types of files the same way we do binary files. 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 Feb 8 19:10: 4 2002 Delivered-To: freebsd-standards@freebsd.org Received: from descent.robbins.dropbear.id.au (028.b.006.mel.iprimus.net.au [210.50.45.28]) by hub.freebsd.org (Postfix) with ESMTP id 65BED37B417 for ; Fri, 8 Feb 2002 19:09:56 -0800 (PST) Received: (from tim@localhost) by descent.robbins.dropbear.id.au (8.11.6/8.11.6) id g19330H54285; Sat, 9 Feb 2002 14:03:00 +1100 (EST) (envelope-from tim) Date: Sat, 9 Feb 2002 14:02:59 +1100 From: Tim Robbins To: "M. Warner Losh" Cc: freebsd-standards@FreeBSD.ORG, fyre@orbital.wiretapped.net Subject: Re: diff problem Message-ID: <20020209140259.A51448@descent.robbins.dropbear.id.au> Reply-To: fyre@orbital.wiretapped.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 GNU diff, from diffutils 2.7 did give a warning before it was locally hacked to pieces. This is the relevant change: diff --show-c-function -ru diffutils-2.7/util.c /usr/src/contrib/diff/util.c --- diffutils-2.7/util.c Sat Oct 1 15:14:15 1994 +++ /usr/src/contrib/diff/util.c Wed Sep 20 13:24:32 2000 @@ -480,7 +485,7 @@ print_1_line (line_flag, line) output_1_line (text, limit, flag_format, line_flag); if ((!line_flag || line_flag[0]) && limit[-1] != '\n') - fprintf (out, "\n\\ No newline at end of file\n"); + fputc ('\n', out); } /* Output a line from TEXT up to LIMIT. Without -t, output verbatim. Commit message for the reverse of this: == revision 1.3 date: 2000/07/24 07:40:02; author: green; state: Exp; lines: +2 -3 Get rid of the stupid bug where diff sticks trash in your generated diff output; there being no trailing newline caused it to bitch and moan and ruin diffs. That's dumb, if I may say so myself. Yes, this file is coming off the vendor branch. It hasn't been updated in 6 years. Approved by: peter == When a file is missing the final newline, GNU diff 2.7 and GNU patch 2.5.4 can reconstruct the file correctly. I have absolutely no idea why we have both version 2.5 and version 2.1 of patch in the tree. 2.5 lives in /usr/src/contrib/patch, 2.1 lives in /usr/src/gnu/usr.bin/patch. Version 2.1 ends up in /usr/bin, version 2.5 is not installed anywhere I can find. IMO patch 2.1 should be installed as 'patch21' or similar, patch 2.5 should be actually installed(!!) and the "stupid bug" patch to GNU diff should be rolled back. I will submit a problem report on this. The standards don't specify what should be done when the file is missing a trailing newline so this isn't really a standards matter. Tim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Fri Feb 8 22:24:16 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 A9C4037B416 for ; Fri, 8 Feb 2002 22:24:11 -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 g196O9i30918; Fri, 8 Feb 2002 23:24:10 -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 g196O8L56350; Fri, 8 Feb 2002 23:24:09 -0700 (MST) (envelope-from imp@village.org) Date: Fri, 08 Feb 2002 23:23:56 -0700 (MST) Message-Id: <20020208.232356.28086539.imp@village.org> To: fyre@orbital.wiretapped.net, tim@robbins.dropbear.id.au Cc: freebsd-standards@FreeBSD.ORG Subject: Re: diff problem From: "M. Warner Losh" In-Reply-To: <20020209140259.A51448@descent.robbins.dropbear.id.au> References: <20020209140259.A51448@descent.robbins.dropbear.id.au> 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 In message: <20020209140259.A51448@descent.robbins.dropbear.id.au> Tim Robbins writes: : GNU diff, from diffutils 2.7 did give a warning before it was locally : hacked to pieces. This is the relevant change: : : diff --show-c-function -ru diffutils-2.7/util.c /usr/src/contrib/diff/util.c : --- diffutils-2.7/util.c Sat Oct 1 15:14:15 1994 : +++ /usr/src/contrib/diff/util.c Wed Sep 20 13:24:32 2000 : @@ -480,7 +485,7 @@ print_1_line (line_flag, line) : output_1_line (text, limit, flag_format, line_flag); : : if ((!line_flag || line_flag[0]) && limit[-1] != '\n') : - fprintf (out, "\n\\ No newline at end of file\n"); : + fputc ('\n', out); : } : : /* Output a line from TEXT up to LIMIT. Without -t, output verbatim. : : Commit message for the reverse of this: : == : revision 1.3 : date: 2000/07/24 07:40:02; author: green; state: Exp; lines: +2 -3 : Get rid of the stupid bug where diff sticks trash in your generated : diff output; there being no trailing newline caused it to bitch and : moan and ruin diffs. That's dumb, if I may say so myself. : : Yes, this file is coming off the vendor branch. It hasn't been : updated in 6 years. : : Approved by: peter : == : : When a file is missing the final newline, GNU diff 2.7 and GNU patch 2.5.4 : can reconstruct the file correctly. : : I have absolutely no idea why we have both version 2.5 and version 2.1 of : patch in the tree. 2.5 lives in /usr/src/contrib/patch, 2.1 lives in : /usr/src/gnu/usr.bin/patch. Version 2.1 ends up in /usr/bin, version 2.5 : is not installed anywhere I can find. : : IMO patch 2.1 should be installed as 'patch21' or similar, patch 2.5 should : be actually installed(!!) and the "stupid bug" patch to GNU diff should be : rolled back. I will submit a problem report on this. : : The standards don't specify what should be done when the file is missing : a trailing newline so this isn't really a standards matter. I'd like to revert this change. The main reason is that gnupatch can reconstruct files that have missing stuff at the end, and subversion whines that FreeBSD's diff is bogus. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Feb 9 9:52:20 2002 Delivered-To: freebsd-standards@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id EF94337B419; Sat, 9 Feb 2002 09:52:16 -0800 (PST) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g19HqFP11551; Sat, 9 Feb 2002 12:52:15 -0500 (EST) (envelope-from green@green.bikeshed.org) Message-Id: <200202091752.g19HqFP11551@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "M. Warner Losh" Cc: fyre@orbital.wiretapped.net, tim@robbins.dropbear.id.au, freebsd-standards@FreeBSD.ORG Subject: Re: diff problem In-Reply-To: Message from "M. Warner Losh" of "Fri, 08 Feb 2002 23:23:56 MST." <20020208.232356.28086539.imp@village.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Feb 2002 12:52:15 -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 "M. Warner Losh" wrote: > In message: <20020209140259.A51448@descent.robbins.dropbear.id.au> > Tim Robbins writes: > : GNU diff, from diffutils 2.7 did give a warning before it was locally > : hacked to pieces. This is the relevant change: > : > : diff --show-c-function -ru diffutils-2.7/util.c /usr/src/contrib/diff/util.c > : --- diffutils-2.7/util.c Sat Oct 1 15:14:15 1994 > : +++ /usr/src/contrib/diff/util.c Wed Sep 20 13:24:32 2000 > : @@ -480,7 +485,7 @@ print_1_line (line_flag, line) > : output_1_line (text, limit, flag_format, line_flag); > : > : if ((!line_flag || line_flag[0]) && limit[-1] != '\n') > : - fprintf (out, "\n\\ No newline at end of file\n"); > : + fputc ('\n', out); > : } > : > : /* Output a line from TEXT up to LIMIT. Without -t, output verbatim. > : > : Commit message for the reverse of this: > : == > : revision 1.3 > : date: 2000/07/24 07:40:02; author: green; state: Exp; lines: +2 -3 > : Get rid of the stupid bug where diff sticks trash in your generated > : diff output; there being no trailing newline caused it to bitch and > : moan and ruin diffs. That's dumb, if I may say so myself. > : > : Yes, this file is coming off the vendor branch. It hasn't been > : updated in 6 years. > : > : Approved by: peter > : == > : > : When a file is missing the final newline, GNU diff 2.7 and GNU patch 2.5.4 > : can reconstruct the file correctly. > : > : I have absolutely no idea why we have both version 2.5 and version 2.1 of > : patch in the tree. 2.5 lives in /usr/src/contrib/patch, 2.1 lives in > : /usr/src/gnu/usr.bin/patch. Version 2.1 ends up in /usr/bin, version 2.5 > : is not installed anywhere I can find. > : > : IMO patch 2.1 should be installed as 'patch21' or similar, patch 2.5 should > : be actually installed(!!) and the "stupid bug" patch to GNU diff should be > : rolled back. I will submit a problem report on this. > : > : The standards don't specify what should be done when the file is missing > : a trailing newline so this isn't really a standards matter. > > I'd like to revert this change. The main reason is that gnupatch can > reconstruct files that have missing stuff at the end, and subversion > whines that FreeBSD's diff is bogus. Do I get to whine that subversion's non-standard use of pseudo-diff lines is bogus, then? All told, I'd actually rather our diff would refuse to act upon files that have no end-line. Encourage people to use non-stupid editing tools that conform to the way things have been done for decades. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Feb 9 10:35:25 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 51B5137B405; Sat, 9 Feb 2002 10:35:23 -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 g19IZLi35706; Sat, 9 Feb 2002 11:35:22 -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 g19IZKL61939; Sat, 9 Feb 2002 11:35:20 -0700 (MST) (envelope-from imp@village.org) Date: Sat, 09 Feb 2002 11:35:01 -0700 (MST) Message-Id: <20020209.113501.106622753.imp@village.org> To: green@FreeBSD.ORG Cc: fyre@orbital.wiretapped.net, tim@robbins.dropbear.id.au, freebsd-standards@FreeBSD.ORG Subject: Re: diff problem From: "M. Warner Losh" In-Reply-To: <200202091752.g19HqFP11551@green.bikeshed.org> References: <200202091752.g19HqFP11551@green.bikeshed.org> 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 In message: <200202091752.g19HqFP11551@green.bikeshed.org> "Brian F. Feldman" writes: : Do I get to whine that subversion's non-standard use of pseudo-diff lines is : bogus, then? All told, I'd actually rather our diff would refuse to act : upon files that have no end-line. Encourage people to use non-stupid : editing tools that conform to the way things have been done for decades. Subversions use is not non-standard. Of all the diffs that I looked at, FreeBSD's is the odd man out. It is non-standard from how the rest of the world. the use of "non-standard" tools happens and our diff shouldn't be stupid when people do that. Diff has spit out the warning for decades and should continue to do so. It isn't diff's job to judge the user when they do a diff that doesn't end in a newline. Gnu patch deals with this. Our patch does not. Our patch is broken and diff shouldn't pander to it when there are legitimate other users of diff's legitimate output. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Feb 9 11:46:50 2002 Delivered-To: freebsd-standards@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.22.195.2]) by hub.freebsd.org (Postfix) with ESMTP id 79B6F37B419 for ; Sat, 9 Feb 2002 11:46:45 -0800 (PST) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #2) id 16ZdS9-0003qo-00 (Debian); Sat, 09 Feb 2002 19:46:29 +0000 Date: Sat, 9 Feb 2002 19:46:29 +0000 From: Tony Finch To: fyre@orbital.wiretapped.net Cc: "M. Warner Losh" , freebsd-standards@FreeBSD.ORG Subject: Re: diff problem Message-ID: <20020209194629.A11392@chiark.greenend.org.uk> References: <20020209140259.A51448@descent.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20020209140259.A51448@descent.robbins.dropbear.id.au>; from tim@robbins.dropbear.id.au on Sat, Feb 09, 2002 at 02:02:59PM +1100 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, Feb 09, 2002 at 02:02:59PM +1100, Tim Robbins wrote: > > I have absolutely no idea why we have both version 2.5 and version 2.1 of > patch in the tree. 2.5 lives in /usr/src/contrib/patch, 2.1 lives in > /usr/src/gnu/usr.bin/patch. Version 2.1 ends up in /usr/bin, version 2.5 > is not installed anywhere I can find. The reason for this is that versions of `patch` after 2.1 do not correctly handle the output of `cvs diff`. For example, on FreeBSD-4.5-STABLE, first using `patch` 2.5 then using `patch` 2.1: fanf@hand.dotat.at:/FreeBSD/releng4/bin/sh : 0; cvs diff > patch cvs diff: Diffing . cvs diff: Diffing bltin cvs diff: Diffing funcs fanf@hand.dotat.at:/FreeBSD/releng4/bin/sh : 1; cat patch Index: bltin/echo.c =================================================================== RCS file: /home/ncvs/src/bin/sh/bltin/echo.c,v retrieving revision 1.9.2.1 diff -u -r1.9.2.1 echo.c --- bltin/echo.c 29 Jun 2000 20:51:59 -0000 1.9.2.1 +++ bltin/echo.c 9 Feb 2002 19:41:00 -0000 @@ -37,6 +37,8 @@ * $FreeBSD: src/bin/sh/bltin/echo.c,v 1.9.2.1 2000/06/29 20:51:59 mph Exp $ */ +/* example change */ + /* * Echo command. */ fanf@hand.dotat.at:/FreeBSD/releng4/bin/sh : 0; rm -r bltin fanf@hand.dotat.at:/FreeBSD/releng4/bin/sh : 0; cvs up cvs update: Updating . ? patch ? tmp cvs update: Updating bltin U bltin/bltin.h U bltin/echo.1 U bltin/echo.c cvs update: Updating funcs fanf@hand.dotat.at:/FreeBSD/releng4/bin/sh : 0; /FreeBSD/releng4/contrib/patch/patch < patch can't find file to patch at input line 8 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |Index: bltin/echo.c |=================================================================== |RCS file: /home/ncvs/src/bin/sh/bltin/echo.c,v |retrieving revision 1.9.2.1 |diff -u -r1.9.2.1 echo.c |--- bltin/echo.c 29 Jun 2000 20:51:59 -0000 1.9.2.1 |+++ bltin/echo.c 9 Feb 2002 19:41:00 -0000 -------------------------- File to patch: ^C fanf@hand.dotat.at:/FreeBSD/releng4/bin/sh : 130; patch < patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |Index: bltin/echo.c |=================================================================== |RCS file: /home/ncvs/src/bin/sh/bltin/echo.c,v |retrieving revision 1.9.2.1 |diff -u -r1.9.2.1 echo.c |--- bltin/echo.c 29 Jun 2000 20:51:59 -0000 1.9.2.1 |+++ bltin/echo.c 9 Feb 2002 19:41:00 -0000 -------------------------- Patching file bltin/echo.c using Plan A... Hunk #1 succeeded at 37. done fanf@hand.dotat.at:/FreeBSD/releng4/bin/sh : 0; Tony. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Feb 9 18:19: 7 2002 Delivered-To: freebsd-standards@freebsd.org Received: from opus.sandiegoca.ncr.com (tan7.ncr.com [192.127.94.7]) by hub.freebsd.org (Postfix) with ESMTP id AAFB737B416 for ; Sat, 9 Feb 2002 18:19:02 -0800 (PST) Received: from localhost (chuckr@localhost) by opus.sandiegoca.ncr.com (8.11.6/8.11.6) with ESMTP id g1A2NgM17711 for ; Sat, 9 Feb 2002 18:23:43 -0800 (PST) (envelope-from chuckr@opus.sandiegoca.ncr.com) Date: Sat, 9 Feb 2002 18:23:42 -0800 (PST) From: Chuck Rouillard X-X-Sender: To: Subject: pathchk - review In-Reply-To: <20020206142317.S9114-100000@opus.sandiegoca.ncr.com> Message-ID: <20020209175757.Y17660-101000@localhost> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-745142398-1013306469=:17660" Content-ID: <20020209180136.E17660@localhost> 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-745142398-1013306469=:17660 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20020209180136.W17660@localhost> This revised `pathchk' is being submitted for review. All the suggestions (to date) by Jacques Vidrine and Tim Robbins have been applied. thanks, .cr --0-745142398-1013306469=:17660 Content-Type: APPLICATION/OCTET-STREAM; NAME="pathchk.tar.gz" Content-Transfer-Encoding: BASE64 Content-ID: <20020209180109.C17660@localhost> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="pathchk.tar.gz" H4sICHHTZTwAA3BhdGhjaGsudGFyAO1ae1fbRhbPv/anmLKnxSaywUDINinp MUaAWmNTP5LQ7Z5ElsdYiyypksyj23z3/d07I1k2EJKF9HGO5xxAGt25c9+P GUI7GTvj8/Vj+1yOXE8++QKjtrGxs70tnghRe/5sI/9Xj+0dIZ5vbz6v7dR2 ntfweav2bPuJ2PgSxCyOaZzYkRBPnPHUOY/uhrvv+990nHTah7uFUFlBsVh1 fcebDqX4bhAPq2EUnFUn56+KfzaVy/Glhtb8uv5brX2BPe7x/51nm9vk/1u1 rW2EgG3y/82dZ0v//yNG9ZcV0QjC68g9Gyei5JTF5sZGzaDfm6JBPItOMHU9 z46GRQKue55g4FhEMpbRhRxW6QN/7MihGyeRO5gmbuAL2x+KaSyF64s4mEaO 5JmB69vRtRgF0SQ2xKWbjEUQ8d9gmjCaSTB0R65jExJD2JEUoYwmbpLIoUBM unCHeEjGdoJfEog8L7h0/TPhBP7QpUUxo6GFE5m84JdadYG6WASjlCwnQMib wBTAU2KDXMJrD4IL+qSFw1gw/CBxHWkAxI2FB4SEZ7YzszhPFnZ1PNudyIgl JTZvkoItc2JJSQGvwynI+0LUCMVoimoYONOJ9BM71d061BIAIBITO5GRa3vx TPysN8KcZ0Txt1UVPXzw7Ykkapj6KbRLeK6JYjGQZBegLBDSHwYRbARfgXsS JBk9invY2RB7w8zECN8Vo3EwSi5JvdpqRBxKh0wGi1wypoiMxc8wkfXEcUog T/eOrK7otg96b+odU+AZmfC1tW/ui71TfDRFvd87anfE+/f1Lj6vrop6ax8/ p8J8e9Ixu13GAgDr+KRpYRnwdOqtnmV2DWG1Gs3+vtU6NMRevyda7Z5oWsdW D2C9tsHo9TLGMlsq2gfi2Ow0jvBa37OaVu+U9z2wei3sKQ6wYV2c1Ds9q9Fv 1jvipN85aXdN5ZpgZN/qNpp169jcrwqQga2F+dps9UT3qN5s5hnbM0FTfa9p KqStU8axb3XMRo84mD01IBaQ0zRE98RsWPRgvjVBf71zapAIGu1W1/ypDyB8 VGjqx/VDsFO6RxIQeqPfMY+JQrDe7e91e1av3zPFYbu9n8m4a3ZeWw2z+1I0 210WUr9rGtilV2cCgAYSwmfiq9+1WFZWq2d2Ov2TntVulRnTUfsNhAF661i+ z4Jtt1inkEu7c0qISSYsd0O8OTIx3yExgsNep07i6PY6VqPH6HKg2LfX7vRy /IqWedi0Ds1Ww6SvbcL0xuqaZajJ6hKApbZ+U1eSb/dZBKQhUKcecyZqsB6F dSDq+68tIl8DQ/1dS5tK+4BRdfuNI62CzODVz/5Q/GD7Uwo0myrIYy6BQfWO Gkc/ilqx2kbs7I5Fq34Mo2pNRFoaVltD4Yylcx7zFDm3guyettonXas7D90O xYEnwmK1HmXw/FKtVnnZvtltdCxWTrFHQSi3GrHEc5NrcQHHH7kyFpdjyXHI Th1dDucxU2DJBRXbcWQcU0xxIonYhYXU3GThQkZREFXF3jViy8ieeolRpCiF CBvZyG+E1uDQKW1nPL+TE0zCwEeYNAQCEUsEe9pnyBqxykdTHwHLu6ZYS5vG 13EiJ1VR9691NCzOgjETAv5cyqoyBiUUlG2krTi2z0C3FwAqi7XBaIR4iYXz NMUgh9iOE+xMSeYEgt/zRGUw9TyJXGElSsb5RZQvgBxSRSZVGW9iX7mT6YSE 4vrganDNlvHuuP6W8tICd8Ucd7dvgTxE2RRZiOdEJrtP2ZkskHYu3txZLO5c z6HWMp4j5HLsOmPSFyWfWNqRM7YHHicdZF02Fn7HtrT2Izs1MpagTmCJbAep sRSXhdqDkpLrX9ieO8xEpsWgkm8knSSIroHN9FhRsItbpUbgNgj2K/IKKZZY WxCi5gfwMVJyRGboK4sS7qiIlVn6jeREY8xW01pFXt7qhSf9M/yRV47kGotc i1UT53XzMXWAJcr+QagLEAjEjnX9Eb9QdpnYZ6Jy6Q6xkws0PpuoChivyeev b3G8aUxbhUGU2AMVHnQ4IseT9jDl9Q7360haWrQzL8yVRKBPOyKciMQZePLh XvQOkdl6+y71oEfzEY039Y978QKTtKkwhD1kFivmXEJXvLFk96lXfkb0q/xm iI3Kt0bxfXW1hArKDYZlQ7yvrJbG1+FY+niBAb1/t1piicdOEMmyqvxyQLmS r8jRGbJm4bsRSJqRg21JNfMi0E5CP5QxrPphq436oIFcY16JCsKdykAmippm t12svoW4JPDWhMEvnFACfyQ29QSavURsqlU95P96B0XGXekHwpFXyDeJSiqE iIrzJMD6BNtP44tNGNRQvYZoc7eqm6L6tzotWez/nS+wx8f7/9rzWm0z7f+3 anQWWNvaeraz7P//iLG+Jopi7dOPAAB76wmAWKNPj9D/A8sjtP/AknX/eH54 8w8kD+79geNRWv+H05J2/grTozT+QPXQvl9R8whtv0aU6/qVeT685weSh7f8 QPIIHT954gMbfqB4hH6fsDxSu6/E+wjdPhA9YrMPbI/X6xOPj9PqA9Ncpy/W 1ov/yC5wUPiuU7lTHb9amE2uQxnTdG6e+sY5QEz4wfyU5yIIxwtzgWOjWJ7f Ixm6wY0pzx0szkWISvNzUx9BZci0UR2uKkSxhuQjz2yPX3bFiqVeZ+Xjyss5 cIpASRBw7wzwk/m6Gl+4tl5YpCugsfRCWjSl/vtFWhOKf1XCf6vqtFqt3rJy YTuOgXdtFMTu1Tt6jgl8o7a5tf1s5/k/v62+q6wUC4XCSn2vsW8eHB5ZP/zY PG61T37qdHv912/env6svtsDB83Y2dj9z7k38YPwV9TS04vLq+vfsNU6h7om 6UWMpr7DQR1BNQmU3tlMXOomiQ6ivaToKr9U07KUp9ZArkj0J9VLzS+5CFxK 8hBWiR4xoynQjRzLLN+1DXTjBt2/UJG6gnZVN8qTEJ2WVIuecv/Gkvxud7Gb MnJLqVe80TypPna2MG2XsoUqP6KIuG151j35AeU5m1KoHOrEMrM7liYyejKN fLHBDT+aNTpQCLlY4XOkmsqll24sM+EXF4Wf9m3l4n+LBZI1vYAJg5HwQ3Rh ey+LhZmJG2pZNnep9sPfJIIaCnoljAyuhodStgmWQG6lFODVonTLAlQUkGr9 q9LK17H4Ol4xstZSPWmDJ1SFSAmghucP2Bf6L1BNqY7e4tB2uARUHSdS/wDF JBpBwackABkyOCGtin7IJci1ash1dcPKofw/Di59BgY6hCLhTKOI1EVxDsIt kHSZM2YNjE9Ic07G6FNRK5fF7q5o9ZvNMijHLiWUuvwK6tf0stVfNlYhwfT/ E8ig04GYi2iFHhcyjWW4ii38M0+qrlaFNBCqD+TcxMivzA4jL4PoXFWsIR9H hLOQAVdVRXV+IR/ToPhDneihsD3jco3kN5VV0ULtpCzZ9vOL7KEqBbEk3S8M YFpU/sXc65O9oh7LL+Lq7v0oknK1mptfz55ZupdaTuB3OA1ndvUR2abryTix 8lJZbmYsexLMKUVrs6CwlYsVMzdl+JmraqdTJ1ZwuvSYBNM5z+U1qdumlkIe BVo2oHkYpyfBGWuBGYNyS99ol1pZXwFvX2ne2DlYDtpJZx6mpQDIDQVWUFER n9HPlBS21AUVkhTHq8VIpRHc5oYKR94FCykzNfU2gKmd8+OHdKM1xRusu7Iq fv+dwYjPUJFtiFxiYhY0ZR+lI5eZP4GOD1pwyn6+mtnKbWIioXNEKZA5lshw 6J1fCIJedORRofFDmnrqcQwPEXSoqY5DOfOpTpI21od9ZDJhkuuFHBsNySVi tdSncet8azAMpDom44PYXAyfz5RaIOT52I4DeQx3gtWWeILEyDuYrTYK4Bez wEkGqC8iXui4S3LWQr4ZYjNGG+QcKnXqSJhFkttvJGjR7FRU+Q4ffxu3HQPz HUhRx+YbyTXtqiyVvG8eTtuz427Otm6cJXxa4NGh5GzBC5FKIwUikd8COJjO neHfXDcPb/CChYP/bFHtfibYBu6l/5PJv23rG2e/JdqPjEv+ildPnbjjydUm zHpUfbGdqLBeJmpHwdTn9jozV0qhiC6Br5DQwjlNp7dcixSQs6S3WzATWkf+ gn76QuYMQHnCjcJwrpyBV6OhV2ev9GswHb1cKHLoAYFbT2clDz3kpjVDn10I 6RyzH1CicH1kRW4e2HdQ36HijCauL9WdToTPqJ15hQ4UJKMwcid8Bq/Sbpzm EEWUDng6LWbsc7RdXxXfUzCD5leodShoZgGYnk+rcsVABmjMwr/GdzdkVq3p ci7DuysqNUR4kS2niVzaymgOZZa7DcEdn0rhNY7Jf62y7t5q9nFqvpTNz6zy Cp9d3hU+q64rfFZBV1is5HKV8f9RuxW+SNGWc66I4Ga1W8y35TMPFCWdqmlZ diPK/AM13b3S/bn0lcWNphGfXdJNEN/uUYS7cpOsG/5LlX/KF9Mai2bI6jXo NzpclvMujEHyp5HZKcfWkQ0mhoaObOzOnMBTUBIE+VpaFGV3naKi5FvJQN1c OqTyx1/V6USUVPVSrqaw6+rh1sCyEFQU+eKOMV845ktHXcQWPgjpoX66KYS6 uoVNLxezwJKQXbBpGhnshTqX4NNpag64HsgVPXPiWkiK2V04ZcQULl9+5W/C 5+VzR9C/GfNp3BH3b4b9VPKfEvpvaEnPFT6mrJsV/YJmtGpSDRUX1aS1RKfv txqUIeJAxUFUKCko8NONhuukd/xUjSTjAFgHNl0gBH4KqoqZuX9euKm4FFjX LeI41SPhTTFyeZQCUs0WT7k0Hk1RLFC9RNFbq6NazCt3vo3TusgE+In926KY c0L+kO0yO7HRCv74LosHNffv8od0aYSlmDszpCJxhALLT0Yl9T9MwPt1/Iuv GdHHsoSKAnmpVmY0VHnS/7WUXK5XzxxDd2JreLnITtJKayMiqlTWZSTAwpFn n+lCUtBJGb1DKrdkBAfvZ1BVmJTUFoQb5IU6JaTelbZ6jnrlRm81XKV+LkOv hJ6JXMF8zzC59q+gJMMK+8CSpY1FZZf/p8YfvuSJC/E0N0HqYqhdSj3FPI6R yt0lTQSnpu9zR7koS7PDyBnfhKxSIUwsk9+BQEmRZfv0aaYL+szq+LNvspdj OZZjOZZjOZZjOZZjOZZjOZZjOZZjOZZjOZZjOZZjOZZjOZZjOZbjf8oz5bEA UAAA --0-745142398-1013306469=:17660-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Feb 9 18:46: 8 2002 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 1762137B417; Sat, 9 Feb 2002 18:46:04 -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 g1A2k1c73612; Sat, 9 Feb 2002 21:46:02 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200202091752.g19HqFP11551@green.bikeshed.org> References: <200202091752.g19HqFP11551@green.bikeshed.org> Date: Sat, 9 Feb 2002 21:46:00 -0500 To: "Brian F. Feldman" , "M. Warner Losh" From: Garance A Drosihn Subject: Re: diff problem Cc: fyre@orbital.wiretapped.net, tim@robbins.dropbear.id.au, freebsd-standards@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) 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 12:52 PM -0500 2/9/02, Brian F. Feldman wrote: >"M. Warner Losh" wrote: > > I'd like to revert this change. The main reason is that gnupatch can >> reconstruct files that have missing stuff at the end, and subversion >> whines that FreeBSD's diff is bogus. > >Do I get to whine that subversion's non-standard use of pseudo-diff lines >is bogus, then? All told, I'd actually rather our diff would refuse to >act upon files that have no end-line. Encourage people to use non-stupid >editing tools that conform to the way things have been done for decades. I think it would be impossible to convince anyone that a file should be called "binary" simply because it is missing the final newline character. You are suggesting that we penalize the person who is running 'diff', but that person may not be the same person as the one who generated the problematic file. Even if I agreed with the stated objective, this behavior hassles the wrong person. The official standards do not say anything on this issue, one way or another. In the absence of such standards, the only standards we can refer to are de facto standards. You blithely invoked the phrase 'non-standard behavior'. Here is a list of behaviors that I find on the OS's I can get to: The behavior of 'diff' where the first file has the final newline and the second file is missing it: 1) diff stupidly thinks the second file is missing the entire last *line*, not just the newline character. It generates a change to delete the entire last line from the first file. Applying the patch to the first file gives you a file which matches neither the first file nor the second file. [NeXTSTEP 3.3 - a 9-year old system...] 2) diff does not realize there is any difference in the two files. no change is generated. [irix] 3) diff realizes the last line of the two files are different, so it prints out a "change", but the change is such that it is impossible to tell what the difference is. It deletes the line and adds it back in, and there is no difference between the old and new lines (in the output). [freebsd] 4) diff realizes the last lines are different, prints out the change-lines to stdout. It still deletes and adds the exact same text for the final line, but it also writes a warning message to stderr: Warning: missing newline at end of file gadtest2 So, the patch generated by 'diff' can not reconstruct the second file from the first file, but at least the user gets some kind of warning message. [aix, solaris] 5) diff realizes the last line is missing the newline, and writes out a specific marker-line to stdout. This makes it possible to construct the second file from the first file and the diff. [linux, netbsd, openbsd, darwin, and of course gnu-diff when it is installed anywhere] I think that the last behavior is the most useful and thus the most desirable one, from a purely practical point of view. The point of 'diff' is to tell the person the difference between two files, it is not there to slap the wrists of someone for using the "wrong tool" to work on some file. When it comes to following standards, freebsd can't claim to be following anyone that I can see. We've invented our own behavior, and that behavior is the least useful behavior of any system which could be called "standard" (I assume that none of us refer to 'irix' when we think of 'standard unix behavior'). If we have to fix our patch to understand the extra line, then let's do that. I think if it does come time to address this issue in a written standard, then I doubt anyone who is already in group-5 will ever ever agree to making their diff less useful. Even if people hate text files which are missing the final newline character, the freebsd version of 'diff' does nothing useful for them. It merely irritates them by saying "there is a difference between these two lines, and I am not going to tell you what it is". It isn't just slapping their wrists, it's slapping their wrists and not letting them know why. While this is a fun exercise in user-hostility, I fail to see any practical benefit from it. -- 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 Sat Feb 9 20: 4:41 2002 Delivered-To: freebsd-standards@freebsd.org Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [212.22.195.2]) by hub.freebsd.org (Postfix) with ESMTP id 6F27537B404; Sat, 9 Feb 2002 20:04:38 -0800 (PST) Received: from fanf by chiark.greenend.org.uk with local (Exim 3.12 #2) id 16ZlBe-0007C8-00 (Debian); Sun, 10 Feb 2002 04:01:58 +0000 Date: Sun, 10 Feb 2002 04:01:58 +0000 From: Tony Finch To: Garance A Drosihn Cc: "Brian F. Feldman" , "M. Warner Losh" , fyre@orbital.wiretapped.net, tim@robbins.dropbear.id.au, freebsd-standards@FreeBSD.ORG Subject: Re: diff problem Message-ID: <20020210040158.A26957@chiark.greenend.org.uk> References: <200202091752.g19HqFP11551@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from drosih@rpi.edu on Sat, Feb 09, 2002 at 09:46:00PM -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, Feb 09, 2002 at 09:46:00PM -0500, Garance A Drosihn wrote: > > I think that the [GNUish] behavior is the most useful and thus the most > desirable one, from a purely practical point of view. The point of > 'diff' is to tell the person the difference between two files, it is > not there to slap the wrists of someone for using the "wrong tool" > to work on some file. When it comes to following standards, freebsd > can't claim to be following anyone that I can see. FreeBSD is following a pedantic reading of SUS. It is also useful to refer to `patch` when we talk about `diff`, since the former is defined (in SUS) in terms of the latter. And you also must consider how these tools interact with the revision management systems that the project uses. Tony. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message From owner-freebsd-standards Sat Feb 9 20:21: 5 2002 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 6851037B417; Sat, 9 Feb 2002 20:21:00 -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 g1A4Krc127566; Sat, 9 Feb 2002 23:20:54 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020210040158.A26957@chiark.greenend.org.uk> References: <200202091752.g19HqFP11551@green.bikeshed.org> <20020210040158.A26957@chiark.greenend.org.uk> Date: Sat, 9 Feb 2002 23:20:52 -0500 To: Tony Finch From: Garance A Drosihn Subject: Re: diff problem Cc: "Brian F. Feldman" , "M. Warner Losh" , fyre@orbital.wiretapped.net, tim@robbins.dropbear.id.au, freebsd-standards@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) 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 4:01 AM +0000 2/10/02, Tony Finch wrote: >On Sat, Feb 09, 2002 at 09:46:00PM -0500, Garance A Drosihn wrote: >> >> I think that the [GNUish] behavior is the most useful and thus the most >> desirable one, from a purely practical point of view. The point of >> 'diff' is to tell the person the difference between two files, it is >> not there to slap the wrists of someone for using the "wrong tool" >> to work on some file. When it comes to following standards, freebsd >> can't claim to be following anyone that I can see. > >FreeBSD is following a pedantic reading of SUS. I meant, the behavior of any current operating system. You could argue that AIX and Solaris are following that pedantic reading too, but at least they tell the user (via stderr) about that missing newline. It should also be acknowledged that the pedantic reading of diff does not acknowledge this issue at all. Ie, if you follow the exact output formats as specified, then there *is* no way to indicate the situation where the last line is missing a newline character. That's what I meant by the 'group 5' behavior being the most useful. It's the only one which allows someone to recreate the second file by using the first file and the output from 'diff'. That should count for something. That marker line isn't a change for the sake of change, it was done to address an oversight and a shortcoming in the standard as written. >It is also useful to refer to `patch` when we talk about `diff`, since >the former is defined (in SUS) in terms of the latter. And you also >must consider how these tools interact with the revision management >systems that the project uses. This is true. As I mentioned, if we need to fix patch to understand the extra line, then we should do that. Chances are we should do that anyway, in case someone sends us a patch generated from the diff on the list of operating systems I listed as 'group 5'. If no other operating system had this extra marker line, then I would be reluctant to have FreeBSD add it. However, given how much of the unix world considers that extra line as "standard", including the two other BSD's, then I think it's a good idea for us to also support it. -- 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 Sat Feb 9 20:27:48 2002 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 9B6C537B400 for ; Sat, 9 Feb 2002 20:27:46 -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 g1A4Pac96004; Sat, 9 Feb 2002 23:25:36 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020209194629.A11392@chiark.greenend.org.uk> References: <20020209140259.A51448@descent.robbins.dropbear.id.au> <20020209194629.A11392@chiark.greenend.org.uk> Date: Sat, 9 Feb 2002 23:25:35 -0500 To: Tony Finch , fyre@orbital.wiretapped.net From: Garance A Drosihn Subject: Re: diff problem Cc: "M. Warner Losh" , freebsd-standards@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) 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 7:46 PM +0000 2/9/02, Tony Finch wrote: >On Sat, Feb 09, 2002 at 02:02:59PM +1100, Tim Robbins wrote: >> >> I have absolutely no idea why we have both version 2.5 and version 2.1 of >> patch in the tree. 2.5 lives in /usr/src/contrib/patch, 2.1 lives in >> /usr/src/gnu/usr.bin/patch. Version 2.1 ends up in /usr/bin, version 2.5 >> is not installed anywhere I can find. > >The reason for this is that versions of `patch` after 2.1 do not correctly >handle the output of `cvs diff`. For example, on FreeBSD-4.5-STABLE, first >using `patch` 2.5 then using `patch` 2.1: The problem you demonstrate here is separate from the newline issue, and based on that example I do agree that would be much too disruptive for us to just drop in patch 2.5. But we could have our patch understand that one "\ missing newline" option in a patch. Adding that support should not break any patches which currently work. -- 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 Sat Feb 9 20:42:23 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 D2E9F37B405 for ; Sat, 9 Feb 2002 20:42:20 -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 g1A4gJi37466; Sat, 9 Feb 2002 21:42:19 -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 g1A4gIL64185; Sat, 9 Feb 2002 21:42:18 -0700 (MST) (envelope-from imp@village.org) Date: Sat, 09 Feb 2002 21:42:13 -0700 (MST) Message-Id: <20020209.214213.48530914.imp@village.org> To: drosih@rpi.edu Cc: dot@dotat.at, fyre@orbital.wiretapped.net, freebsd-standards@FreeBSD.ORG Subject: Re: diff problem From: "M. Warner Losh" In-Reply-To: References: <20020209140259.A51448@descent.robbins.dropbear.id.au> <20020209194629.A11392@chiark.greenend.org.uk> 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 In message: Garance A Drosihn writes: : The problem you demonstrate here is separate from the newline issue, and : based on that example I do agree that would be much too disruptive for us : to just drop in patch 2.5. But we could have our patch understand that : one "\ missing newline" option in a patch. Adding that support should : not break any patches which currently work. I'm planning on doing that before I back out the changes. gnupatch groks it correctly, and so should our patch :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-standards" in the body of the message