ac@utgpu.UUCP (05/15/87)
I wasted quite a bit of time the last few days trying to port a UUENCODE and UUDECODE program to OS9. It was a port of a port of a port but the version I finally got was for Mark William's C on an Atari ST. The really aggravating aspect of my problems was that they resulted from bugs I already knew about but I didn't think to check the source for these problems when I started having difficulties. Although these bugs have been reported before, I will describe them again in the hopes that others can avoid the problems I had. 1) Fopen normally opens the file specified in it's first argument according to the access specified in it's second argument. If the open fails for any reason, then NULL is returned, otherwise a valid file pointer is returned. If, however, the string which specifies the access includes an invalid letter, then the open will always "succeed", and a non-NULL file pointer is returned. This file pointer is in no way associated with the file you were trying to open! It appears to be STDIN or STDOUT. In my specific case the open was: fopen(argv[1],"rb") "B" is not valid under OS9 C so when the program went to read from my input file it hung waiting for input from the keyboard. 2) The code produced for comparisons of unsigned integers to literal zeros is incorrect. For example, if I is an unsigned int then the comparison i>0 will not work correctly. Code i!=0 instead. Avoid "<", ">" and combination of these with "=". 3) The final problem I had is one that I can't really put my finger on. I had added a bunch of diagnostic fprintf functions calls to my program. They were all very similar. I had just copied them to various points in the program to dump out the value of certain variables I was interested in. At one point I added a few more of these statements and started getting all sorts of "unresolved references" from the linker. The solution seemed to be to remove some of the calls but I can't for the life of me see how the last few added fprintf's were any different than the earlier one. Has anyone ever had any problems with unexplainable unresolved references? -- Name: Mark Acfield (University of Toronto Computing Services) Path: ihnp4!utgpu!ac Alias: ac@utoronto.bitnet
ingoldsby@calgary.UUCP (05/16/87)
In article <1987May15.141952.4911@gpu.utcs.toronto.edu>, ac@gpu.utcs.toronto.edu (Mark Acfield) writes: > > > 3) The final problem I had is one that I can't really put my finger on. > I had added a bunch of diagnostic fprintf functions calls to my program. > They were all very similar. I had just copied them to various points > in the program to dump out the value of certain variables I was interested > in. At one point I added a few more of these statements and started > getting all sorts of "unresolved references" from the linker. > The solution seemed to be to remove some of the calls but I can't for the > life of me see how the last few added fprintf's were any different than > the earlier one. Has anyone ever had any problems with unexplainable > unresolved references? > > -- Yes, and they puzzled me too. In my case I discovered that one of the passes of the compiler doesn't complain if it runs out of disk space. The output just seems to go to the great bit bucket in the sky. Later on, after the intermediate files have been deleted you are not aware that it ever ran short of space. The linker, however, can't find the last routines and gives unresolved refs. On my system, I find that making sure I have a couple of hundred K free on the disk helps. Then again, with R/S disks you can't have a couple of hundred K free :> Terry ihnp4!alberta!calgary!ingoldsby
jimomura@lsuc.UUCP (05/16/87)
Mark! Bad timing man! I ported a Uuencode and Uudecode to OSK
a few days ago. I ported a DRI C version and it compiled without any
changes in the Uudecode and only 2 small changed in the Uuencode.
I thought about posting it but changed my mind. I expect that they
would have compiled equally under 6809 C. Oh well.
In case anyone is interested, on BIX we've got the following work
in progress:
1. Modified Lempel-Ziv Compress (same 'compress' as on most Unix systems).
I got this to work on small text files. It died on object code and
on large text files. I have no further time to debug it. If someone
else wants to finish it I'll send it via mail.
2. ARC has been ported by a fellow in Germany. I'm awaiting a copy and
I'll get in touch with Software Enhancements for their approval to
post it to BIX when it arrives. I'll also ask about the Net.
3. SDB. The Users' Group has a port of this apparently, but I didn't find
out until after I'd started my own port. I don't know what version
the Users' Group has, so I may finish this port. Someone else on
BIX may finish it anyway. There didn't seem to be much to do.
4. Proff. I looked at the code, shook my head and said "not right now".
I like 'proff'. It doesn't look all that portable though. Not after
I started really looking at it.
5. KB (Knowledge Base) Same problems as Proff. I've halted work on it
for now. These two programs seem too difficult for me to do at my
current level of experience. Maybe later.
6. 'Profit' is one of those weird deals where the author has requested
that you don't post ported versions. It's easy enough to port, but
you have to get the sources from the author ($5.00 or so). Did I
say Profit? Wrong program. I meant 'Planit'.
7. I've just begun a rough spec for a calendar/datebook. I'm also looking
to see if someone else has written one I like. I don't want to write
one if I can avoid it, but it's starting to look necessary.
These are most of the current public domain things I'm involved in
one way or the other (and other members of BIX). As a commercial enterprise,
someone on BIX is porting X-Windows to a high performance OS-9 machine
with ACRTC support, but that has nothing to do with the conference directly.
We're looking forward to his/their report though.
I'm glad to hear that someone is working on Uuslave. I've seen the
sources for Uuslave and Uuclone and I don't like the looks of either.
They both seem to have substantial portions of machine code which may
just amount to drivers, but may cause problems. Good luck to him/them(?)!!
Cheers! -- Jim O.
--
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura