home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.sys.mac.programmer
- Path: sparky!uunet!pageworks.com!world!siegel
- From: siegel@world.std.com (Rich Siegel)
- Subject: Re: Inconsistantcy in Think C
- Message-ID: <Btt4v5.Gv7@world.std.com>
- Organization: GCC Technologies
- References: <1992Aug30.091804.1@acad2.alaska.edu>
- Date: Sun, 30 Aug 1992 17:35:28 GMT
- Lines: 35
-
- In article <1992Aug30.091804.1@acad2.alaska.edu> asmah@acad2.alaska.edu writes:
- >I have run into some very strange problems working with Think C 5.0 lately and
- >would like to know if anybody know's what is causing them. Here is one I can
- >easily define.
- >
- >I have a sprintf() statement which doesn't work the first time through, but
- >works during a second time. As far as I can tell, all the variables are
- >identical during both passes. This is what it looks like.
- >
- >CharsHandle input;
- >TEHandle TEFields[20];
- >
- >input = TEGetText(TEFields[0]);
- >sprintf((**ARH.c_employee).last_name,"%.*s",(**TEFields[0]).teLength,(**input));
- >return 1;
- >
-
- If your ANSI library is in a different segment than the routine with
- the printf, then your call to printf() is causing a segment load,
- which in turn will cause the handles (**ARH.c_employee) and (**input)
- and (**TEFields[0]) to move. The best way to solve this problem is to
- lock the handles before calling sprintf(), or place the ANSI library
- in the same segment as the code that calls into it, to avoid the
- segment load. In general, it's not a good idea to depend on
- dereferences like this as arguments to function calls.
-
- R.
-
-
-
- --
- -----------------------------------------------------------------------
- Rich Siegel Internet: siegel@world.std.com
- Software Engineer & Toolsmith
- GCC Technologies
-