Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!mit-eddie!killer!gtmvax!dms3b1!dave
From: dave@dms3b1.UUCP (Dave Hanna)
Newsgroups: comp.sys.amiga
Subject: Re: Lattice 5.02 bugs?
Summary: Size mismatch in variables?
Message-ID: <196@dms3b1.UUCP>
Date: 21 Apr 89 10:09:50 GMT
References: <493@bilver.UUCP>
Reply-To: dave@dms3b1.UUCP (Dave Hanna)
Distribution: usa
Organization: Infotouch Systems, Inc., Dallas
Lines: 62

In article <493@bilver.UUCP> alj@bilver.UUCP (arthur johnson) writes:
> Has anyone else experienced the following problems with Lattice 5.02?:
> 1) You pass a pointer (&variable) to a subroutine, change the variable
>    within the subroutine (*variable = ???), and then leave.  Upon return
>    from your subroutine, the variable contains crap (variable = 2600000 or
>    so).  Within the subroutine, the value is correct up to actually exiting
>    the routine.
> 2) You do a typical scanf (scanf("%d", &feh)).  No matter what you type,
>    feh contains 0.

Both these problems can be a result of size mismatch between variables
pointed to in the calling routine and what is expected by the called routine.

E.g.   
{
    long int foo;
    ...
    subr(&foo);
    ...
}

void subr(bar)
short int *bar;
{
   *bar = result;
}



    Since the subroutine is treating the pointer as pointing to a 2-byte
value, and has no knowledge of how the calling routine is treating it,
it stores the result in the upper two bytes of the long word variable.
Also, if you print it out within the subroutine, it will print out
to be the expected value.  When you get back to the calling routine,
foo has had it's top two bytes modified, with the least significant
two bytes unmodified, and you try to print it out as a long word
quantity.  The best thing you could see would be result*65536, which
would be puzzling enough.  If foo had garbage in the least significant
two bytes, it would be even less recognizeable.

    Same thing with the scanf if feh is a short quantity.  Scanf
will dump the results into memory as ints (which I think are 32 bits
by default in Lattice -- not sure about that) unless the scan format
is modified with an 'h' (for half-size).  So if feh is a short, you
would actually be seeing the upper two bytes of what you scanned, 
which would most likely be zero.  The correct scanf statement in
that case would be (I think):
	scanf("%hd", &feh)

	All these comments are generic 'C', and do not apply
particularly to Lattice.

    And, of course, this may or may not be the problem.  It is a possible
source, that's all.  Hope it helps.
>Arthur Johnson Jr. -=> {uiucuxc, hoptoad, petsd}!peora!rtmvax!bilver!alj


-- 
Dave Hanna,  Infotouch Systems, Inc. |  "Do or do not -- There is no try"
P.O. Box 584, Bedford, TX 76095      |                        - Yoda
(214) 358-4534   (817) 540-1524      |
UUCP:  ...!killer!gtmvax!dave        |