forrest@sybase.com (12/23/90)
Let's say your company just decided on a coding standard and let's
say you were able to come up with a specification file for the
'indent' program that would allow 'indent' to change all your
1000's of source files to meet the standard. Do you trust 'indent'
enough to run it on all your source file without making any mistakes?
By mistakes I mean changes that actually change your code so that it
does something different than what it did before you ran it through
'indent'.
----
Anything you read here is my opinion and in no way represents Sybase, Inc.
Jon Forrest WB6EDM
forrest@sybase.com
{pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest
415-596-3422rick@ptcburp.ptcbu.oz.au (Rick Stevenson) (12/24/90)
forrest@sybase.com writes: >Let's say your company just decided on a coding standard and let's >say you were able to come up with a specification file for the >'indent' program that would allow 'indent' to change all your >1000's of source files to meet the standard. Do you trust 'indent' >enough to run it on all your source file without making any mistakes? >By mistakes I mean changes that actually change your code so that it >does something different than what it did before you ran it through >'indent'. Why don't you run a copy of your src files through indent, recompile, and compare new object files with the old versions? The proof of the pudding... Rick. -- -m------- Rick Stevenson ---mmm----- Pyramid Technology +61 75 522475 FAX -----mmmmm--- Research Park, Bond University +61 75 950249 VOICE -------mmmmmmm- Gold Coast, Q 4229, AUSTRALIA rick@ptcburp.ptcbu.oz.au
dkeisen@Gang-of-Four.Stanford.EDU (Dave Eisen) (12/25/90)
In article <12184@sybase.sybase.com> forrest@sybase.com writes: >Do you trust 'indent' >enough to run it on all your source file without making any mistakes? I don't trust indent to go through my source files without making any indenting mistakes; I find that any source file that was typed with anywhere near what I consider to be reasonable indenting gets made worse by indent. But, I have been using indent for some time now and I've never seen any changes in anything other than whitespace. Well, there was that bug where it would change >>= to >> = . -- Dave Eisen dkeisen@Gang-of-Four.Stanford.EDU 1447 N. Shoreline Blvd. Mountain View, CA 94043 Anybody have an extra New Year's ticket? (415) 967-5644 (I can hope, can't I?)
ark@alice.att.com (Andrew Koenig) (12/25/90)
In article <12184@sybase.sybase.com> forrest@sybase.com writes: > Do you trust 'indent' > enough to run it on all your source file without making any mistakes? I don't need to -- I can compile my programs before and after and compare the object files. If they're not identical, something's broken. -- --Andrew Koenig ark@europa.att.com
arnold@audiofax.com (Arnold Robbins) (12/27/90)
>In article <12184@sybase.sybase.com> forrest@sybase.com writes: >> Do you trust 'indent' >> enough to run it on all your source file without making any mistakes? Personally, no. See below for what I'd do if I had thousands of lines of code to massage. In article <11742@alice.att.com> ark@alice.UUCP () writes: >I don't need to -- I can compile my programs before and after >and compare the object files. If they're not identical, >something's broken. Andrew is fortunate enough to be running on a Unix system that doesn't use COFF for it's object files --- COFF files have a timestamp in them. If you know where it is (I don't), you can arrange to strip off the COFF header and then compare the objects, but it is not as simple an operation as it used to be. A better, more useful technique would be to use lex/flex to write a C scanner that produced a stream of tokens, one per line. Run it against the before and after versions, and then use diff on the two outputs. main() { printf("hello, world\n"); } and main ( ) { printf ( "hello, world\n" ) ; } should both produce (collapsed to save space) ident open-p close-p open-brace ident open-p string-const close-p semi-colon close-brace as their token streams. Comments should be noted, as should preprocessor lines and such. It's about a day's job to do well. Some versions of indent were notorious for turning i =-1; /* XXX --- could be old style assign op */ into i -= 1; which of course is wrong. Comparing the tokenized version of the code would make catching this sort of change much easier. Even if there were a few errors of this sort, using indent and then cleaning up after it would still be a win over reformatting code by hand. -- Arnold Robbins AudioFAX, Inc. | Laundry increases 2000 Powers Ferry Road, #200 / Marietta, GA. 30067 | exponentially in the INTERNET: arnold@audiofax.com Phone: +1 404 933 7612 | number of children. UUCP: emory!audfax!arnold Fax-box: +1 404 618 4581 | -- Miriam Robbins
kdq@demott.com (Kevin D. Quitt) (12/27/90)
In article <12184@sybase.sybase.com> forrest@sybase.com writes: >Let's say your company just decided on a coding standard and let's >say you were able to come up with a specification file for the >'indent' program that would allow 'indent' to change all your >1000's of source files to meet the standard. Do you trust 'indent' >enough to run it on all your source file without making any mistakes? Certainly. Just as soon as I'd proven that the executables were bit-for-bit indentical. 8-{)} -- _ Kevin D. Quitt demott!kdq kdq@demott.com DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266 VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last
ronald@robobar.co.uk (Ronald S H Khoo) (12/27/90)
kdq@demott.COM (Kevin D. Quitt) writes: > In article <12184@sybase.sybase.com> forrest@sybase.com writes: > > Do you trust 'indent' > > enough to run it on all your source file without making any mistakes? > Certainly. Just as soon as I'd proven that the executables were > bit-for-bit indentical. 8-{)} And you gotta repeat this process for each and every possible combination of compile-time #ifdef options. Ugh. It's not a small job. My feeling is that if the original code were *that* badly indented, it's indicative of poor quality anyway, and its probably time to rewrite the whole damn lot. only 1/2 :-) -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
oz@yunexus.yorku.ca (Ozan Yigit) (12/27/90)
In article <12184@sybase.sybase.com> forrest@sybase.com writes: >Do you trust 'indent' >enough to run it on all your source file without making any mistakes? Yes. Ever since the famous assignment bug was fixed, I ran literally hundreds of thousands of lines of code through indent [the one that was posted] and on randomly paranoid occasions, I compared binaries. [at this point, I stopped, went to a system running SunOS 4.0.3, and ran /bin/indent on a recently arrived 63 files containing 110,000 lines of awful C code, compiled the result, and diffed against the first binary I had created earlier. No differences were found.] Nowadays, almost any piece of foreign code actually goes through indent before I ever look at it. [Almost all such code looks better afterwards :-)] I think there exists versions of indent, including the one included in the latest Berkeley distributions, and the one posted to comp.sources.unix, and probably the one hacked for GNU, that are basically reliable in terms of one-to-one translation. Any unreliable versions should be flushed. oz --- Good design means less design. Design | Internet: oz@nexus.yorku.ca must serve users, not try to fool them. | UUCP: utzoo/utai!yunexus!oz -- Dieter Rams, Chief Designer, Braun. | phonet: 1+ 416 736 5257
hagins@gamecock.rtp.dg.com (Jody Hagins) (12/27/90)
In article <310@audfax.audiofax.com>, arnold@audiofax.com (Arnold Robbins) writes: |> >In article <12184@sybase.sybase.com> forrest@sybase.com writes: |> >> Do you trust 'indent' |> >> enough to run it on all your source file without making any mistakes? |> |> Personally, no. See below for what I'd do if I had thousands of lines of |> code to massage. |> |> In article <11742@alice.att.com> ark@alice.UUCP () writes: |> >I don't need to -- I can compile my programs before and after |> >and compare the object files. If they're not identical, |> >something's broken. |> |> Andrew is fortunate enough to be running on a Unix system that doesn't |> use COFF for it's object files --- COFF files have a timestamp in them. |> If you know where it is (I don't), you can arrange to strip off the |> COFF header and then compare the objects, but it is not as simple an |> operation as it used to be. The COFF header layout follows, for those interested, but without the references. COFF object file format specifies that the header is first, then the optional (aout) header, followed by section headers, etc. The file header is a <struct filehdr>, declared in filehdr.h. The optional header is <struct aouthdr>, declared in aouthdr.h. struct filehdr { unsigned short f_magic; unsigned short f_nscns; long f_timdat; long f_symptr; long f_nsyms; unsigned short f_othdr; unsigned short f_flags; }; By looking at <struct filehdr>, we see that the time stamp is at bytes 4-7. All this can be (and was) found in the UNIX programmers guide. -- Jody Hagins hagins@gamecock.rtp.dg.com Data General Corp. 62 Alexander Dr. RTP, N.C. 27709 (919) 248-6035
chip@tct.uucp (Chip Salzenberg) (12/27/90)
According to arnold@audiofax.com (Arnold Robbins): >A better, more useful technique would be to use lex/flex to write a >C scanner that produced a stream of tokens, one per line. Run it against >the before and after versions, and then use diff on the two outputs. No need. There is already a utility in the c.s.u archives called "spiff" (for Spaceman Spiff). Spiff is a token-based diff program. Just run indent and "spiff -C"; if indent worked properly, spiff should produce no output. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "Please don't send me any more of yer scandalous email, Mr. Salzenberg..." -- Bruce Becker
mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) (12/29/90)
In article <11742@alice.att.com> ark@alice.UUCP () writes: :In article <12184@sybase.sybase.com> forrest@sybase.com writes: : :> Do you trust 'indent' :> enough to run it on all your source file without making any mistakes? : :I don't need to -- I can compile my programs before and after :and compare the object files. If they're not identical, :something's broken. :-- : --Andrew Koenig : ark@europa.att.com There are differences - just tried it. They're minor - byte 8 differs, and so does a byte 18000 bytes in - haven't checked the significance. Time stamps? I'd look it up, but I'm too lazy. Edification anyone? -- Dan Mercer NCR Network Products Division - Network Integration Services Reply-To: mercer@npdiss1.StPaul.NCR.COM (Dan Mercer) "MAN - the only one word oxymoron in the English Language"
asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) (12/29/90)
In article <277A1970.3AFB@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > According to arnold@audiofax.com (Arnold Robbins): > >A better, more useful technique would be to use lex/flex to write a > >C scanner that produced a stream of tokens, one per line. Run it against > >the before and after versions, and then use diff on the two outputs. > > No need. There is already a utility in the c.s.u archives called > "spiff" (for Spaceman Spiff). Spiff is a token-based diff program. > Just run indent and "spiff -C"; if indent worked properly, spiff > should produce no output. You would be better off, or at least more accurate, to compile both before and after versions and 'diff' the object code. What you're suggesting is that we take a piece of relatively new soft- ware (with s/w, new == buggy) and validate it using a piece of relatively new sofware (probably just as buggy). The only thing that'll save you is the low probability that the bugs line up such that they both make the same mistake. 'diff' at least is old enough to have most of the bugs removed. -- asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) ========================= Opinions are Mine, Typos belong to /usr/ucb/vi "We're sorry, but the reality you have dialed is no longer in service. Please check the value of pi, or see your SysOp for assistance." UUCP: hplabs!felix!asylvain ============================================
flaps@dgp.toronto.edu (Alan J Rosenthal) (12/29/90)
arnold@audiofax.com (Arnold Robbins) writes: >Andrew is fortunate enough to be running on a Unix system that doesn't >use COFF for it's object files --- COFF files have a timestamp in them. >If you know where it is (I don't) ... sigh.. just cmp -l the files. if more than a few bytes are different, they're different, otherwise it's the timestamps. I've done this, works fine. of course just compiling a program twice & "cmp -l" ing it will show you where the bytes are. and there's always /usr/include/a.out.h. no problem.
balkwill@ncs.dnd.ca (Bob Balkwill) (12/30/90)
Why would anyone want to indent code that alreay compiles, thereby permitting a diff of the object code? Indent is invaluable (IMO) in porting code that looks yucky but the code is nowhere near compilable at that stage. -- ---- Bob Balkwill Operations Research and Analysis Establishment balkwill@ncs.dnd.ca DND, Canada ----
dave@cs.arizona.edu (Dave P. Schaumann) (12/30/90)
In article <1990Dec30.054537.17537@ncs.dnd.ca> balkwill@ncs.dnd.ca (Bob Balkwill) writes: >Why would anyone want to indent code that alreay compiles, thereby >permitting a diff of the object code? Indent is invaluable (IMO) in >porting code that looks yucky but the code is nowhere near compilable >at that stage. Imagine you have just inherited some working code, on the machine it was intended for. (The author won the lottery...). Imagine that the author used the Code Style From Hell. Here you have a situation where you want to re-indent functioning code. (Masochists excepted, of course...) >Bob Balkwill Operations Research and Analysis Establishment >balkwill@ncs.dnd.ca DND, Canada >---- Dave Schaumann | You are in a twisty maze of little dave@cs.arizona.edu | C statements, all different.
dbrooks@penge.osf.org (David Brooks) (12/31/90)
Re suggestions that you compile the before and after code, and compare the .o files... and complaints that the assembler plunks the date and time into the .o file... Why not compile both sources with -S and diff the assembly source? That way, you stand a chance of finding out not only that there is a difference, but where it is. -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks In Memoriam: Chris Naughton, aged 16, killed by a drunk driver Dec 22, 1990
lerman@stpstn.UUCP (Ken Lerman) (12/31/90)
In article <12184@sybase.sybase.com> forrest@sybase.com writes: >Let's say your company just decided on a coding standard and let's >say you were able to come up with a specification file for the >'indent' program that would allow 'indent' to change all your >1000's of source files to meet the standard. Do you trust 'indent' >enough to run it on all your source file without making any mistakes? >By mistakes I mean changes that actually change your code so that it >does something different than what it did before you ran it through >'indent'. > >---- >Anything you read here is my opinion and in no way represents Sybase, Inc. > >Jon Forrest WB6EDM >forrest@sybase.com >{pacbell,sun,{uunet,ucbvax}!mtxinu}!sybase!forrest >415-596-3422 NO, I would not trust indent. Alternative 1: You could write a program (call it undent) which replaces each contiguous string of white space with a single blank character. You could run it on my code before and after running indent and diff the results. If they are the same, you are probably OK. The one area of concern I'd have left is what is done with comments. In particular, some CPPs treat the zero length comment /**/ as a concatenation operator. Make sure that the undent program does NOT treat this as white space. (Or grep your input and output code looking for this.) Alternative 2: The purpose of this standard is to make code easier to maintain. Before doing any maintenance, the programmer should run regression tests on the application he is working on. Then run indent on the module(s) he will be changing. Then run the regression tests again. Now you can start modifying code. If some module is never worked on, there is no need to "indent" it. What, you don't have regression tests? Then your problem is far worse than the lack of a standard coding format. Ken
lerman@stpstn.UUCP (Ken Lerman) (12/31/90)
In article <256@ptcburp.ptcbu.oz.au> rick@ptcburp.ptcbu.oz.au (Rick Stevenson) writes:
.....
.Why don't you run a copy of your src files through indent, recompile,
.and compare new object files with the old versions? The proof of the
.pudding...
.
.Rick.
.--
. -m------- Rick Stevenson
. ---mmm----- Pyramid Technology +61 75 522475 FAX
. -----mmmmm--- Research Park, Bond University +61 75 950249 VOICE
.-------mmmmmmm- Gold Coast, Q 4229, AUSTRALIA rick@ptcburp.ptcbu.oz.au
I've never been able to compare object successfully. Object files
tend to have imbedded line numbers, version numbers, etc. which cause
them to compare differently. Is there a utility out there which will
enable me to determine if the code and data parts of an executable or
object file are the same?
Kenmat@mole-end.UUCP (Mark A Terribile) (01/01/91)
> In article <11742@alice.att.com> ark@alice.UUCP () writes: > >I don't need to -- I can compile my programs before and after > >and compare the object files. If they're not identical, > >something's broken. > Andrew is fortunate enough to be running on a Unix system that doesn't > use COFF for it's object files --- COFF files have a timestamp in them. > If you know where it is (I don't), you can arrange to strip off the > COFF header and then compare the objects, but it is not as simple an > operation as it used to be. If you are on a System V family UNIX (or even a System III or System IV, when they introduced the frotzenglarken timestamp into the COFF) you should have the -l on your cmp; this will report differences in the two or three bytes of timestamp and go running merrily onward. It does make it harder to do shell scripts that must stop if a problem arises, but if you are using a shell with enough magic (like ksh) it's surely possible. -- (This man's opinions are his own.) From mole-end Mark Terribile
anlhille@rose.ucs.indiana.edu (Joseph Hillenburg) (01/01/91)
In article <5970@stpstn.UUCP>, lerman@stpstn.UUCP (Ken Lerman) writes... |In article <12184@sybase.sybase.com> forrest@sybase.com writes: I fiddled with Intent on a pure BSD4.3/MicroVAX II, and compiled a single C file with the options: % gcc -O -S test.c % mv test.s test_noindent.s % indent test.c % gcc -O -S test.c % mv test.s test_indent.s I won't show diffs, but there was less than 10 lines difference in the two files. The test.c file was the source to a mutant version of ctar. Of course, you may get different results. +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | // Joseph Hillenburg, Secretary, Bloomington Amiga Users Group | | \X/ anlhille@ucs.indiana.edu anlhille@iurose.BITNET | | "Have fun folks. It's the last time you'll be seeing this place" | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
mcdonald@aries.scs.uiuc.edu (Doug McDonald) (01/01/91)
*************************************************************************** I would have used e-mail, but I know that it is hopeless: the poster of the following gave no "real" address, only the bogus one "lerman@stpstn.UUCP" He should edit his sendmail program to use a real address, either UUCP- style complete with !'s or internet style a@b.c.d.e. Or put his real address in a signature line. *************************************************************************** In article <5970@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: > >NO, I would not trust indent. Then you are deluded. Indent is probably more trustworthy than your C compiler. > >Alternative 1: >You could write a program (call it undent) which replaces each >contiguous string of white space with a single blank character. You >could run it on my code before and after running indent and diff the >results. If they are the same, you are probably OK. This is a sufficient but not necessary condition. Indent will not in general pass this test. > >The one area of concern I'd have left is what is done with comments. >In particular, some CPPs treat the zero length comment /**/ as a >concatenation operator. Not if they are compiling the C language they don't. The string /**/ MUST be replaced by a single white space. Period. All pertinent references (K&R first edition, K&R second edition, and the actual ANSI standard) all agree 100% on this. If you so-called C compiler does something else, it is terminally broken. >Make sure that the undent program does NOT >treat this as white space. It MUST treat it as white space!!! Because that is what it is. Doug McDonald (mcdonald@aries.scs.uiuc.edu)
meissner@osf.org (Michael Meissner) (01/02/91)
In article <1990Dec28.220527.16131@jarvis.csri.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes: | arnold@audiofax.com (Arnold Robbins) writes: | >Andrew is fortunate enough to be running on a Unix system that doesn't | >use COFF for it's object files --- COFF files have a timestamp in them. | >If you know where it is (I don't) ... | | sigh.. | just cmp -l the files. if more than a few bytes are different, they're | different, otherwise it's the timestamps. I've done this, works fine. | of course just compiling a program twice & "cmp -l" ing it will show you where | the bytes are. and there's always /usr/include/a.out.h. no problem. This doesn't always work with some object file formats out there. For example, with the MIPS ECOFF object file format, the filenames are put into the object file. The MIPS assembler explicitly puts an entry for the assembly file into the table, even if the first line of the assembly file is a .file to set the filename (it puts that in as well). If you have a compiler that produces assembly output and invokes the assembler (such as GCC), the assembler input file is invariably created using the process ID in the filename. Two successive runs will produce differences in the filenames stored. One of the things that I did in my MIPS debug patches to GCC, is strip out the useless filename, so that only the timestamps will differ. The OSF/rose object file format has the potential for the same problem in that it has a field to record the command line of the object file creator. Thus if you compare .o's you will see differences, but if you compare linked programs you won't (since the linker puts it's own command line in the field). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
benson@odi.com (Benson I. Margulies) (01/03/91)
Multics has a compare_object command that did a logical compare, section by section. Surely OSF can do as well. Surely someone could write one and put it in the public domain, in any case. I would if I needed it. -- Benson I. Margulies
meissner@osf.org (Michael Meissner) (01/03/91)
In article <1991Jan2.164722.15516@odi.com> benson@odi.com (Benson I. Margulies) writes: | Multics has a compare_object command that did a logical compare, | section by section. Surely OSF can do as well. Surely someone could | write one and put it in the public domain, in any case. | I would if I needed it. I'm planning on writing one. I hacked together a perl script that compares MIPS ECOFF binaries section by section. Perl is not the language to write such a beast, so the mark-II version will be in C. It reminded me of my early days at Data General, where you had to write your own structures for doing system calls from the assembly language parameters (which is why I became a fanatic about providing the structures for the C compiler I wrote for them). -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Considering the flames and intolerance, shouldn't USENET be spelled ABUSENET?
asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) (01/04/91)
In article <5971@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: > In article <256@ptcburp.ptcbu.oz.au> rick@ptcburp.ptcbu.oz.au (Rick Stevenson) writes: > ..... > .Why don't you run a copy of your src files through indent, recompile, > .and compare new object files with the old versions? The proof of the > .pudding... > > I've never been able to compare object successfully. Object files > tend to have imbedded line numbers, version numbers, etc. which cause > them to compare differently. Is there a utility out there which will > enable me to determine if the code and data parts of an executable or > object file are the same? You should be able to run 'strip' on the object files to remove any extraneous garbage, including information for debuggers. Although I like someone's suggestion of compiling to assembly source with the -S option much better. As he pointed out, this not only identifies a difference, it indicates where it is as well. (Or at least gives you an idea, depending on how transmorgrified it becomes with optimization.) -- asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) ========================= Opinions are Mine, Typos belong to /usr/ucb/vi "We're sorry, but the reality you have dialed is no longer in service. Please check the value of pi, or see your SysOp for assistance." UUCP: hplabs!felix!asylvain ============================================
asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) (01/04/91)
In article <1991Jan1.151157.19442@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: [...] > In article <5970@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: > > > >NO, I would not trust indent. > Then you are deluded. Indent is probably more trustworthy than your > C compiler. Well, it has less work to do ... other than that, who knows? [...] > >The one area of concern I'd have left is what is done with comments. > >In particular, some CPPs treat the zero length comment /**/ as a > >concatenation operator. > > Not if they are compiling the C language they don't. The string > /**/ MUST be replaced by a single white space. Period. All pertinent > references (K&R first edition, K&R second edition, and the actual > ANSI standard) all agree 100% on this. If you so-called C compiler > does something else, it is terminally broken. It may be standard, but there *are* C compilers which do this. And, of course, programmers who have taken advantage of the "feature". > >Make sure that the undent program does NOT > >treat this as white space. > > It MUST treat it as white space!!! Because that is what it is. I agree. However, when one is stuck with the task of making a piece of code work, s/he is usually not concerned with what the "correct" is supposed to be, except for the results generated by the application. Actually, anyone with code which makes extensive use of the "feature" should probably rewrite it anyway, especially if upgrading to a system or compiler where the "feature" (correctly) doesn't exist. But that's a decision to be made on a case-by-case basis, i.e., is it cheaper to rewrite the code, or find a kludge around the problem? (I know, nobody likes "kludges", but this is the real world and elegance must sometimes take a backseat to expediency. Ah, but that's a whole 'nother thread!) -- asylvain@felix.UUCP (Alvin "the Chipmunk" Sylvain) ========================= Opinions are Mine, Typos belong to /usr/ucb/vi "We're sorry, but the reality you have dialed is no longer in service. Please check the value of pi, or see your SysOp for assistance." UUCP: hplabs!felix!asylvain ============================================
karl@ima.isc.com (Karl Heuer) (01/05/91)
In article <1991Jan1.151157.19442@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >In article <5970@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes: >>some CPPs treat the zero length comment /**/ as a concatenation operator. > >Not if they are compiling the C language they don't. The string >/**/ MUST be replaced by a single white space. Period. All pertinent >references (K&R first edition, K&R second edition, and the actual >ANSI standard) all agree 100% on this. Unfortunately, prior to ANSI C there was no such thing as "the C language"; there were multiple dialects of C. One subfamily, including the dialect described by K&R1, treated comments as whitespace. Another, which includes the dialect described by the Ritchie compiler with the Reiser cpp, treated them as empty. Whether this was a bug in the compiler or in the manual cannot be resolved without further information. X3J11 accepted both K&R1 and widespread existing practice as evidence in defining the new language. In this case they went with K&R1, not because it was sacred text, but because the behavior described by K&R1 is better. (And because they'd added an alternate way to do concatenation.) Karl W. Z. Heuer (karl@ima.isc.com or uunet!ima!karl), The Walking Lint
gertjan@westc.uucp (Gertjan van Oosten) (01/07/91)
> In article <12184@sybase.sybase.com> forrest@sybase.com writes: > > > Do you trust 'indent' > > enough to run it on all your source file without making any mistakes? > > I don't need to -- I can compile my programs before and after > and compare the object files. If they're not identical, > something's broken. > -- > --Andrew Koenig > ark@europa.att.com Sadly, this is not enough :-( I had a version of 'indent' (sorry, don't know which, nor the OS version (it was SunOS)) that ate some comment from my file. And I definitely do NOT consider source files with and without comment equal. As an aside: what does one do when the object files aren't identical? Regards, -- -- Gertjan van Oosten, gertjan@westc.uucp OR mcsun!hp4nl!westc!gertjan -- West Consulting bv, Phoenixstraat 49, 2611 AL Delft, The Netherlands -- P.O. Box 3318, 2601 DH Delft -- Tel: +31-15-123190, Fax: +31-15-147889