Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!astroatc!prairie!dan
From: dan@prairie.UUCP (Daniel M. Frank)
Newsgroups: net.unix-wizards
Subject: Re: Microport Unix -- Large Model Problems
Message-ID: <271@prairie.UUCP>
Date: Thu, 30-Oct-86 23:47:28 EST
Article-I.D.: prairie.271
Posted: Thu Oct 30 23:47:28 1986
Date-Received: Fri, 31-Oct-86 20:03:17 EST
References: <188@vsedev.VSE.COM>
Reply-To: dan@prairie.UUCP (Daniel M. Frank)
Distribution: net
Organization: Prairie Computing, Madison, Wisconsin
Lines: 73
Keywords: Microport, Unix, Memory, Segmentation

In article <188@vsedev.VSE.COM> ron@vsedev.VSE.COM (Ron Flax) writes:
>Has anyone  else  out  there  been  experiencing  problems  with porting
>programs to Microport Unix V/AT that fall into the large model category?
>It seems  that  most  everything  I  port  (try  to port?)   has pointer
>alignment problems,  as  indicated by  lint, or  just core  dumps with a
>segmentation violation at strange places in the code, like on a strlen()
>call?

   The problems aren't generally with Microport, they are with brain-
damaged, unlinted programs that presume that sizeof int = sizeof *,
or even (in one case), that ALL scalar data types are always the same
size when passed into a function.  Let me make a few observations and
suggestions of how to find these problems and what to watch for.

   First, the lint you have is probably broken, unless you have the
very latest release (in the last two days).  You will find the new,
repaired version of lint (and sdb, actually), very useful.

   Suggestion:  compile everything with -g.  sdb is very useful
for finding obscure portability bugs that lint will not find (usually
because of a VARARGS directive).

   Nasties to watch for:

    1) Failure to declare functions returning long or *.  The compiler
	   will happily truncate return values to one word, which will
	   usually cause segmentation violations very quickly, or in
	   the case of long returns, cause odd program behaviour.  malloc()
	   and time() are favorites, as are string functions returning
	   pointers.

	2) Constructs of the form 1 << n, where n is greater than 15.
	   Guess what happens?  The compiler optimizes this to zeroing
	   out a register.  You want 1L << n.  This bug is from compress.c

	3) Silly function arguments, usually constants.  time(0) is a
	   popular one.  This should be time((long *)0).

	4) Very silly constant function arguments in varargs functions,
	   where lint can't find them.  execl and execle are very
	   popular in this category.  Watch for varargs functions
	   that use null pointers to terminate lists; folks usually
	   use 0 rather than the proper (char *)0.

	5) Varargs functions that use a bunch of integer arguments
	   to copy the stack.  These are all over the place, in
	   such classics as patch and inews.  The method is not
	   bad, per se, but usually there aren't enough of these
	   arguments if ints are shorter than pointers.  Redeclare
	   them to be long instead.


   (I am posting this generally, rather than mailing back to the poster,
because I would beg, implore, plead, and otherwise abase myself before
authors of C programs posted to the net to try and be sensitive to
some of these problems.  Yes, I know the 286 is brain-damaged and all
that, but a bunch of us got `em cheap from this guy in a plaid sport
coat who told us that they were the wave of the future, and now we
can't afford Suns.  Watch for assumptions about pointer sizes.  Use
the varargs functions and macros provided in System V and BSD instead
of bogus argument lists.)

   On the crash problem, try again with Microport support.  Stress
that there are not many multi-terminal sites, and that this is occurring
on different hardware.  Ask for Henry and use my name.

   Good luck!
	  Dan

-- 
    Dan Frank
    uucp: ... uwvax!prairie!dan
    arpa: dan%caseus@spool.wisc.edu