john@moncol.UUCP (John Ruschmeyer) (08/11/85)
I considered posting this to net.lang.*, but this group seems more appropriate. What is the most bizarre line/piece of code you have seen in a production program? My favorite (in BASIC) is: X = N & -1 which is the equivalent of: X = INT(N) I know there must be some better(?) ones out there. Let's see em'. -- Name: John Ruschmeyer US Mail: Monmouth College, W. Long Branch, NJ 07764 Phone: (201) 222-6600 x366 UUCP: ...!vax135!petsd!moncol!john ...!princeton!moncol!john ...!pesnta!moncol!john Disclaimer: Monmouth College is a mecca for diverse opinions. It is, therefore, highly unlikely that the above opinions are those of anyone but me. Silly quote: Around here we don't have cuisine. We have EATS.
thau@h-sc1.UUCP (robert thau) (08/15/85)
> What is the most bizarre line/piece of code you have seen in a production > program? > > Name: John Ruschmeyer I'm working in a bio lab which is heavily computer-based (computers control the experiments and do all the analysis). The programs are written by local people, who are biologists, not programmers. This results in a few real gems. (Note: The lab uses Whitesmith's C, with its hopelessly braindamaged library. I've translated where appropriate): To null-terminate a string terminated by newline: register char *cp; ... cp = index(s, '\n'); /* Note lack of error-check */ strcpy(cp, "\0\0"); To set cp to be four characters from the end of string s: /* This is O(n^2) */ for (cp = s; strlen(cp) > 4; cp++) ; To output an escape sequence (never mind why ...): printf("%c%c", '\033', 'F'); etc. -- Robert Thau \ Keeper of the *FLAME* )) rst@tardis.ARPA ( ( h-sc1%thau@harvard.ARPA \\
lhl@lanl.ARPA (08/15/85)
The most bizarre code I ever had to program follows (in FORTRAN) 100 IF (IREQ.EQ.0) GO TO 100 and was the accepted method, on a long-defunct system, of testing completion on an asynchronous I/O request. Lewis H. Lowe@The New Mexico Institute for the Incurably Different "You've got me stranded at the gas station of love And I have to use the self-service pump!" Wierd Al Yankovic
andyb@dartvax.UUCP (Andy Behrens) (08/15/85)
> What is the most bizarre line/piece of code you have seen in a production > program? I haven't seen it personally, but here's an example from Kernighan and Plauger's "Elements of Programming Style": DO 14 I = 1,N DO 14 J = 1,N 14 V(I,J) = (I/J)*(J/I) Their comment on this fragment is "A modest familiarity with Fortran tells us that this doubly nested DO loop assigns something to each element of an N by N matrix V. What are the values assigned? I and J are positive integer variables and, in Fortran, integer division truncates toward zero. Thus when I is less than J, (I/J) is zero; conversely, when J is less than I, (J/I) is zero. When I equals J, both factors are one. So (I/J)*(J/I) is one if and only if I equals J; otherwise it is zero. The program fragment puts ones on the diagonal of V and zeros everywhere else. (V becomes an identity matrix.) How clever! "Or is it?" Andy Behrens {astrovax,decvax,cornell,ihnp4,linus}!dartvax!andyb.UUCP andyb@dartmouth.CSNET andyb%dartmouth@csnet-relay.ARPA
csdf@mit-vax.UUCP (Charles Forsythe) (08/16/85)
In article <462@moncol.UUCP> john@moncol.UUCP (John Ruschmeyer) writes: >What is the most bizarre line/piece of code you have seen in a production >program? 6809 assembly language program: . . . LDB ,X+ ;get value from table --> SEX ;sign extend b into d --> BRA STRAP ;skip over next section . . . Well, I thought it was wierd. -- Charles Forsythe CSDF@MIT-VAX "Live on time. Emit no evil. Wait! I got that backwards!" -Rev. Wang Zeep
crandell@ut-sally.UUCP (Jim Crandell) (08/20/85)
> The most bizarre code I ever had to program follows (in FORTRAN) > > 100 IF (IREQ.EQ.0) GO TO 100 A former colleague of mine once found it necessary to write a program with just such a line in it for a now ancient Datacraft (now Harris) machine. To my taste, however, the line was not nearly so bizarre as the object code to which the Datacrock FORTRAN compiler converted it. This compiler was exceptionally stupid, even by the standards of its time, to such an extent that it didn't recognize that a statement of the form IF (<logical expression>) GO TO <label> would require only a conditional branch to <label> following the code to evaluate <logical expression> to a result in the condition register. Instead, it simple-mindedly generated a conditional branch to a forward, followed by an unconditional branch to <label> and finally the definition of the forward. Now it happens that branches were among the machine's fastest instructions, so the performance impact of this asininity wasn't really severe in most instances, but in the interesting case where the <label> following GO TO was identical with the one in columns 1-5, the compiler became so confused that it forgot to generate the unconditional branch, thus reducing the statement to a conditional no-op. Now this compiler was endowed with such a magnificent array of charming little quirks and truly endearing features -- I deeply regret that time doesn't permit me to enumerate even a fraction of them -- that I came to regard the idea of modifying it as the moral equivalent of blasphemy. I therefore proposed the creation of an object-code pessimizer, whose primary function was examining FORTRAN compiler output for sequences of this type and inserting the necessary but omitted instruction. Unfortunately, I never had time to reduce this revolutionary idea to practice. -- Jim Crandell, C. S. Dept., The University of Texas at Austin {ihnp4,seismo,ctvax}!ut-sally!crandell
bllklly@uwmacc.UUCP (Bill Kelly) (08/23/85)
The Sperry Univac 1100 is a ones-complement machine. The old Fortran compiler
took no special pains to avoid generating -0 in calculations. However,
for a statement like IF (X >=0) it would generate a Test Positive
instruction, which fails for -0. Therefore, Fortran programs were always
sprinkled with statements to convert a possible -0 to 0:
IF (X=0) X=0
Bizarre.
--
Bi|| {allegra, ihnp4, seismo}!uwvax!uwmacc!bllklly
Ke||y UW-Madison, 1210 West Dayton St., Madison WI 53706
"Anyone can do any amount of work provided it isn't the work he is supposed
to be doing at that moment." -- Robert Benchleymff@wuphys.UUCP (Swamp Thing) (08/27/85)
Well, this one's my favorite. Just skip over it if you've seen it before. I know it works on at least 3 IBM compilers. i = 1 j = 2 call sub(1,j) i = 1 write(6,*) i end subroutine sub(k,l) k = l return end The output, of course, is "2". Mark F. Flynn Department of Physics Washington University St. Louis, MO 63130 ihnp4!wuphys!mff ------------------------------------------------------------------------------ "There is no dark side of the moon, really. Matter of fact, it's all dark." P. Floyd
john@moncol.UUCP (John Ruschmeyer) (08/28/85)
>From: andrew@grkermi.UUCP (Andrew W. Rogers) >Message-ID: <554@grkermi.UUCP> >Organization: GenRad, Inc., Concord, Mass. > >When writing an overlaid program on HP-2100/RTE, you had to include a statement >like > > IF (2 .EQ. 4) CALL MAIN > >because the linker wouldn't load the main unless there was a reference to it - >but if you actually *called* MAIN, your program would restart... therefore the >above. (Optimization? Constant folding? What are those?) Ulp! By any chance did this FORTRAN let you change the value of a constant by passing it to a subroutine, as in: CALL FOO(2) . . . SUBROUTINE FOO(I) I=I + 2 RETURN END Each is bizarre enough alone, but together..... -- Name: John Ruschmeyer US Mail: Monmouth College, W. Long Branch, NJ 07764 Phone: (201) 222-6600 x366 UUCP: ...!vax135!petsd!moncol!john ...!princeton!moncol!john ...!pesnta!moncol!john Disclaimer: Monmouth College is a mecca for diverse opinions. It is, therefore, highly unlikely that the above opinions are those of anyone but me. Silly quote: Son, you're mixing ponderables again...
stpeters@steinmetz.UUCP (R L StPeters) (08/30/85)
> > 100 IF (IREQ.EQ.0) GO TO 100 > > and was the accepted method, on a long-defunct system, of testing > completion on an asynchronous I/O request. An old bug in the low-level VMS I/O calls (qio's) used to require a similar hack, and a lot of C code around here still has the line while (!iosb[1]); -- R. L. St.Peters (Dick) The "R" is for "Reptile". uucp: decvax!mcnc!ncsu!uvacs!edison!steinmetz!stpeters (uucp is forever) arpa: stpeters@ge-crd (federal express) "Any opinions expressed by my employer are probably not mine."
andrew@grkermi.UUCP (Andrew W. Rogers) (09/01/85)
In article <490@moncol.UUCP> john@moncol.UUCP (John Ruschmeyer) writes: >>From: andrew@grkermi.UUCP (Andrew W. Rogers) >> [Description of a weird quirk of HP FORTRAN and its loader] > >Ulp! By any chance did this FORTRAN let you change the value of a constant >by passing it to a subroutine, as in: > > CALL FOO(2) > . > . > SUBROUTINE FOO(I) > I=I + 2 > RETURN > END > Actually, I've never heard of a FOOTRAN compiler that *wouldn't* let you do the above - or even generate a warning! All parameters in FORTRAN are passed by reference and it is just assumed that you won't try anything (deliberately or otherwise) like the above. Algol (and most of its derivatives) support parameter passing by value as well as by reference. Call-by-reference parameters in Pascal and Ada (yeah, I know the latter aren't technically 'by reference') are explicitly flagged as such ('var' in Pascal, 'out' in Ada); more importantly, the mode of passing each parameter is known to the compiler when processing the call. Passing a constant parameter to a routine that might change its value is readily detected and results in an error message. The following programs *will not* compile: procedure foo(var i: integer); { Pascal } begin i := i + 2 end; . . foo(2); procedure FOO(I: in out INTEGER) is -- Ada begin I := I + 2; end FOO; . . FOO(2); Modern techniques of flow analysis could theoretically catch this sort of trap in FORTRAN - *if* FOO were in the same source module as all calls to it. Another solution (depending on machine architecture, memory management, and OS design) would be to place all constants in a read-only data area. Attempts to change constant values would either be ignored or generate a run-time error. (Anyone know of compilers/systems that do either?) Incidentally, there are several C compilers that allow you to pass the address of a constant (apparantly to facilitate interface to - you guessed it - FORTRAN subroutines). The FORTRAN example above could be written as foo(&2); . . foo(i) int *i; { *i += 2; } (I doubt that even 'lint' would catch this!) AWR (Is this the least bizarre posting, or what?)
jeq@laidbak.UUCP (Jonathan E. Quist) (09/01/85)
In article <593@grkermi.UUCP> andrew@grkermi.UUCP (Andrew W. Rogers) writes: >In article <490@moncol.UUCP> john@moncol.UUCP (John Ruschmeyer) writes: >>>From: andrew@grkermi.UUCP (Andrew W. Rogers) >>> [Description of a weird quirk of HP FORTRAN and its loader] >> >>Ulp! By any chance did this FORTRAN let you change the value of a constant >>by passing it to a subroutine, as in: >> >> CALL FOO(2) >> . >> . >> SUBROUTINE FOO(I) >> I=I + 2 >> RETURN >> END >> >Actually, I've never heard of a FOOTRAN compiler that *wouldn't* let you do >the above - or even generate a warning! All parameters in FORTRAN are passed >by reference and it is just assumed that you won't try anything (deliberately >or otherwise) like the above. > >Algol (and most of its derivatives) support parameter passing by value as >well as by reference. Call-by-reference parameters in Pascal and Ada (yeah, >I know the latter aren't technically 'by reference') are explicitly flagged >as such ('var' in Pascal, 'out' in Ada); more importantly, the mode of >passing each parameter is known to the compiler when processing the call. >Passing a constant parameter to a routine that might change its value is >readily detected and results in an error message. The following programs >*will not* compile: > > procedure foo(var i: integer); { Pascal } > begin > i := i + 2 > end; > . > . > foo(2); > > > procedure FOO(I: in out INTEGER) is -- Ada > begin > I := I + 2; > end FOO; > . > . > FOO(2); > > >Modern techniques of flow analysis could theoretically catch this sort of >trap in FORTRAN - *if* FOO were in the same source module as all calls >to it. Another solution (depending on machine architecture, memory >management, and OS design) would be to place all constants in a read-only >data area. Attempts to change constant values would either be ignored or >generate a run-time error. (Anyone know of compilers/systems that do either?) > >Incidentally, there are several C compilers that allow you to pass the >address of a constant (apparantly to facilitate interface to - you guessed >it - FORTRAN subroutines). The FORTRAN example above could be written as > > foo(&2); > . > . > foo(i) > int *i; > { > *i += 2; > } > >(I doubt that even 'lint' would catch this!) > >AWR > >(Is this the least bizarre posting, or what?) 1Lq% cat foo.c #include <stdio.h> main() { foo(&2); } foo(i) short *i; { *i += 2; } 2Lq% lint foo.c foo.c: foo.c(5): unacceptable operand of & foo.c(5): cannot recover from earlier errors: goodbye! Irmc. jeq
mouse@mcgill-vision.UUCP (der Mouse) (09/03/85)
>>When writing an overlaid program on HP-2100/RTE, you had to include a statement >>like >> >> IF (2 .EQ. 4) CALL MAIN >Ulp! By any chance did this FORTRAN let you change the value of a constant >by passing it to a subroutine, as in: > > CALL FOO(2) > . > . > . > SUBROUTINE FOO(I) > I=I + 2 > RETURN > END Now imagine if that FORTRAN *did* do constant merging (ie when you use the constant `2' three times, allocate only one 2)! TYPE *,2 CALL foo(2) TYPE *,2 CALL foo(2) TYPE *,2 writes out 2, 4, and 6 ?! Uh....maybe that could lend itself to some neat hacks.... -- der Mouse {ihnp4,decvax,akgua,etc}!utcsri!mcgill-vision!mouse philabs!micomvax!musocs!mcgill-vision!mouse Hacker: One responsible for destroying / Wizard: One responsible for recovering it afterward
jer@peora.UUCP (J. Eric Roskos) (09/05/85)
> The most bizarre code I ever had to program follows (in FORTRAN) > > 100 IF (IREQ.EQ.0) GO TO 100 That's not so bizarre... reminds me of some code in the DEC OS/8 boot loader (I think it was for the RK8/E): jmp . The way it worked was that the jmp was at the starting address for the code being loaded; the program would initiate the I/O operation, then sit there looping. When the I/O completed, some new code would appear there, and it would start off running again... -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 Uryc! Gurl'er cnvagvat zl bssvpr oyhr! Jung n qrcerffvat pbybe...
alexis@reed.UUCP (Alexis Dimitriadis) (09/07/85)
> >>Ulp! By any chance did this FORTRAN let you change the value of a constant > >>by passing it to a subroutine, as in: > >> > >> CALL FOO(2) > >> . > >> . > >> SUBROUTINE FOO(I) > >> I=I + 2 > >> RETURN > >> END > >> Now that we all had our laughs at the stupidity of FORTRAN, try running the following code through your favorite C compiler: --------------- char * yes() { return "yes"; } main() { strcpy(yes(), "no"); puts(yes()); } --------------- Sure enough, it prints "no". (Unless you make the data section read-only, of course, which will give you a _run_time_ error). - Alexis -- _______________________________________________ As soon as I get a full time job, the opinions expressed above will attach themselves to my employer, who will never be rid of them again. alexis @ reed {decvax,ihnp4,ucbcad,uw-beaver}!tektronix!reed.UUCP
scw@ucla-cs.UUCP (09/10/85)
In article <1582@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: >> The most bizarre code I ever had to program follows (in FORTRAN) >> >> 100 IF (IREQ.EQ.0) GO TO 100 > >That's not so bizarre... reminds me of some code in the DEC OS/8 boot loader >(I think it was for the RK8/E): > > jmp . > >The way it worked was that the jmp was at the starting address for the code >being loaded; the program would initiate the I/O operation, then sit there >looping. When the I/O completed, some new code would appear there, and >it would start off running again... >-- Actually it was sort of neat.: Boot program real boot address code meaning code meaning 20 6733 read block (0) 6734 skip on I/o done 21 5021 jump . 5020 jump .-1 6732 get status ... What you did was toggle in the 2 instruction bootstrap then start 20. The I/O actually started at 0 when 21 was read in the hard jmp . turned into a wait for I/O loop. When the I/O finally did compleat the program just skiped the jmp .-1 and ran along (really very nifty). Stranger still was the bootstrap for the PDP-12 , Linc-8 and Linc. There were 2 sets of 12 switches on the front panel (left and right) to boot the machine you put a Read Linc Tape block in the left switches and a block number and count in the right switches, there was another switch on the front panel marked DO, when you pressed the DO switch the instruction in the switches was executed (as I recall to boot os/8 you read block 0 (0701 0000) and to boot Dial you read 7 blocks from the middle of the tape (0700 7300)). Dial was as bizzare an operating system as you'd never want to see, you used the A-D knobs to control the cursor (you were ALWAYS either in the editor or running an application program). They did however have some interesting instructions on the machine (display 1/2 a character [put the 12 bits in the ACC on the screen as either the right or left half of character]). Another oddity that just came to mind. The LINC (DEC's first product) didn't have any serial output devices, what they did was to use 2 of the relays (6 of them altogether as I recall) to toggle a current loop line to drive a TTY-33 for a printer.
rob@ctvax (09/11/85)
Bizarre code? What about the PDP-11 program that runs backwards?
Put a
mov -(pc),-(pc)
in high memory and see that sucker go!
...convex!ctvax!robbobr@zeus.UUCP (Robert Reed) (09/17/85)
If we're into bizarre boot code, consider the boot loader for the IBM 1130. (Antique machine, but from the era where hacking was a basic survival skill). The 1130 provided two Initial Program Load (IPL) devices to boot the OS off the internal disk drive: a card reader or a paper tape reader. However, the hard-wired load procedure for the card reader was to put one 12 bit card column image in each sixteen bit word. Four bits would go to the top of each word and the other eight to the bottom, and there was a maximum of 80 consecutive words that could be loaded. The standard cold start program required at least one instruction which needed bits set in the unset four, and used many instructions which conveniently needed those bits set to zero. At least two bits of that field were index register bits for address decoding. So the cold-start program would use the first 12 instructions or so to modify the code to be used for doing the disk IO, and this code would then be executed. But the really bizarre thing came with the paper tape IPL. It would read four bits of each eight bit frame and stick it in the next four bit nibble, and continue to do so until it saw a bit in the fifth position of a column. The effect was that four frames would be read for each word in memory, loading every bit prior to IPL execution. Care to guess what the standard IPL program for paper tape looked like? If you guessed that the second frame of each foursome was empty, you're RIGHT! The same code was used. The same synthesis of instructions, in this case totally unnecessary was carried out. Bizarre, huh? -- Robert Reed, CAE Systems Division, tektronix!teklds!bobr