In article <bob-EABE57.17554212022008@[EMAIL PROTECTED]
>,
Robert Peirce <bob@[EMAIL PROTECTED]
> wrote:
> I have the following definitions in a header file:
>
> /*
> Declarations for database variables
> */
>
> char t[TL]; /* ticker */
> char n[SN]; /* name */
> int g1,g2,g3; /* group codes */
>
> TL is defined as 9 and SN as 31 in another header file.
>
>
> They are used in the following code segment:
>
> fgets(s1, BUF, sd);
>
> strcpy(t, s1);
> t[TL-1] = '\0';
> printf ("Ticker = %s.\n", t); // This is correct
> printf ("Something happens between here . . .\n");
>
> strcpy(n,s1+TL); // This is tra****ng t
> printf ("And here . . .\n");
> printf ("Ticker = %s.\n", t); // This is trash
> n[SN-1] = '\0';
>
> This code works fine under Uwin on a PC. The module compiles with no
> errors or warnings on my Intel based MacBook Pro. Something seems to be
> getting stepped on but I can't figure out how.
>
> I think I am missing something obvious. Can anybody help?
I just thought of something you Apple experts might know. This has
always worked before because t came in memory before n. I am copying
s1+TL to n, which is bout 150 characters into a 31 character string. It
is going to trash anything that follows it in memory, which has never
been a problem because n always followed t. While this is probably a
really dumb assumption, it has worked for 20 years. However, does that
actually happen in this case? If t follows n in memory, it would
explain why t is getting trashed. It wouldn't quite explain exactly
what is getting into t, but it would be a start.
--
Robert B. Peirce, Venetia, PA 724-941-6883
bob AT peirce-family.com [Mac]
rbp AT cooksonpeirce.com [Office]
|
