csrobe@ICASE.ARPA (Charles S. Roberson) (07/28/87)
In Atari Digest vol 87 issue 291, Howard Chu writes: >I've recently hacked the sources for ARC 5.20 to work on our Vax, Suns >and Apollos. I thought you might like to see some potential problems that I detected in arclzw.c on our Sun: line 277: warning: illegal pointer combination when the following initialization is attempted: unsigned char *bp = buf; but buf is declared as: static char buf[BITS]; /* input/output buffer */ I don't see why the authro had to mix character types. One or the other should have worked consistently. I will admit that I have not gone to great lengths to figure this one out, but I would have used an unsigned char since I am twiddling bits and doing arithmetic. line 701: warning: constant -1 is out of range of unsigned short comparison line 701: warning: value coerced to 65535 for bug compatibility i like this one. if((localbuf=getc_unp(fd))==EOF) /* get start of next code */ getc_unp does not have any form of prototype/declaration for arclzw.c, so it defaults to int. It is defined elsewhere as static INT, where INT is defined as a short int in arc.h. Even better it is assigned to localbuf which is defined as as an unsigned INT and compared to EOF which is -1 on my system. So what we have is: if( (unsigned short int = int) == -1 ) Not to mention that he uses 2 gotos in this file. I like the utility, but I don't like this cavalier use of C. I don't want to trust something that is this loose with my data. I'm afraid to go bopping around in any more of the code, I don't know what I'll see. From looking at the flow control in the code, it looks like the code was written by an assembly language programmer who taught him self the syntax of C without learning proper programming style associated with higher level languages. [I'm jumping on this because code like this may work on one machine but when it is ported to different architectures or even other compilers, it's open season. If someone is going to play the game they had better play by the rules. I don't want to get this code near a dpANSI C compiler. For any of you out there who are porting this hibernating virus, BE VERY CAREFUL! Test it like mad. Get somebody to clean it up. For godz sake, run lint on the sucker! Experience has proven this one pretty well. I personally have moved arc'd files between an IBM PC ( i confess, yes i touched one, but they made me do it ) and my Atari ST. But there *ALWAYS* that untested path.] Also the documentation is sparse when it comes to libtws.a. Could you tell us a little more about libtws.a other than what is in the header to tws.h? Where is it available? > The 5.12 he posted had #ifdef's >which claimed to allow it to run on STs. I just got my ST, and don't >have a C compiler for it yet, so I wouldn't know... As soon as i get it working on the Sun (BSD4.2 Sun Release (3.3|3.4)) and i get my hard disk back from Supra, i will try to compile it on my atari using MWC. (I will probably try a rewrite, but I don't know if I have it in me. I don't know what I'll do). Let's see, "if ain't broke don't fix it." But how do I know if it ain't broke? It sure looks ill to me. >If you can get to the Internet, you can ftp it off our vax. Umix is >at 35.1.1.10, login 'ftp' password <any>. I'll provide my copy of the >5.20 sources in an arc file. Grab it in binary mode from > ~ftp/pub/hyc/arcsrc.arc The path actually appears to be: /pub/hyc/arc.shar[123] also, the section in the SHell ARchive for marc.c seemed to be corrupted: >echo shar: extracting marc.c '(7944 characters)' >sed 's/^X//' << \SHAR_EOF > marc.c >X/* MARC - Archive merge utility . . . >X abort("Unable to delete old copy of %s",arcname); >X if(rename(newname,arcname)) >X XXXSHAR_EOF it looks like some lines (3?) got crunched somewhere. This makes the shell run right past the "SHAR_EOF" into tws.h and bombs. I will try to ftp again, at off-peak hours, but you might want to check to make sure your arc.shar3 file is not corrupt. Thank you for posting your sources. Please don't take any of the comments made above personally, I just thought you might like to know. -c -------------------------------------------------------------------- Chip Roberson ARPANET: csrobe@icase.arpa 1105 London Company Way BITNET: $csrobe@wmmvs.bitnet Williamsburg, VA 23185 UUCP: ...!seismo!gmu90x!wmcs!csrobe --------------------------------------------------------------------
hyc@UMIX.CC.UMICH.EDU (Howard Chu) (07/28/87)
Thanks for the comments. I hadn't gone hunting down those messages, either, because they were "only warnings" and the finished product works without a hitch on our Suns. However, I admit they should be fixed soon, and I'll try something to that effect, since the compiler claims (in the one example) that the "type coercion" isn't going to work in release 4 of their OS. I'd forgotten to mention that I'd changed the format of the distribution. You should, in fact, get everything in pub/hyc - there are 3 shar files for arc, and also 2 shar files for phoon, the package that libtws.a is provided in. (Phoon was written by Jef Poskanzer, and posted to mod.sources a few months ago.) Actually, just get the README file there, it explains all this too. (And I'm tired of explaining this over again....) I didn't realize the shar file was corrupt, I'll look at it and try recreating it... Note, marc.c isn't used in this distribution at all, and tws.h is also included in phoon, so if you have the corrupt copies of the shar file, you can still build yourself a working ARC. -- Howard Chu University of Michigan Computing Center, Unix Project
billw@wolf.UUCP (Bill Wisner) (07/30/87)
Why not try to get a copy of the sources to PKARC and PKXARC? These two
programs for the IBM, one for making archives and one for extracting, increase
ARC's throughput by reading the entire entry from the ARC file before
extracting. Not being glued to the disk while extracting, it does a much
faster job. Or, you could just write this into standard ARC. (Call it ARC
6.00?)
--
Bill Wisner
..{sdcsvax,ihnp4}!jack!wolf!billw
Look ma, no copyright!