Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!videovax!dougs
From: dougs@videovax.tv.tek.com (Doug Stevens)
Newsgroups: comp.os.msdos.programmer
Subject: Re: Borland Turbo C 1.5
Summary: Problems with structures accessed across file boundaries (long).
Keywords: Turbo C 1.5, problems float
Message-ID: <6249@videovax.tv.tek.com>
Date: 4 Jan 91 19:35:21 GMT
References: <1991Jan3.125057.21477@cbnewsm.att.com>
Organization: Tektronix TV Measurement Systems, Beaverton OR
Lines: 28

In article <1991Jan3.125057.21477@cbnewsm.att.com>, mds1@cbnewsm.att.com (marc.d.sayre) writes:
> 
> 	I use this structure a lot across functions ...
> 
> 	I recently started to expand the code and start getting weird responses
> 	when I execute the program ...
> 

I've seen this problem MANY times in systems in which the dependencies have
not been maintained in the make file.

In these cases, the definition of the structure is in an include file, and
is not listed as a dependency for all the files that use it. The program gets
extended by adding another field to the structure, and some code that operates
on that field. All the code that operates on fields listed BEFORE the new 
field works OK, but code operating on fields listed AFTER the new field breaks
(because the file containing the code has not been re-compiled, and still
uses the old offset within the structure to access the field).

A dead give-away is to do a build-all (if you are operating from a make file,
just touch all the .c's, then re-compile); if the code starts working, the
above problem is occurring.

Another really nasty possibility is that the structure is independently
defined in every file that uses it, and the definitions are not the same.

My approach is to put structure definitions in .h files, and to always use
autodependency checking when compiling and linking.