In article
<reinder-9A82C7.00190413022008@[EMAIL PROTECTED]
>,
Reinder Verlinde <reinder@[EMAIL PROTECTED]
> wrote:
> 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?
>
> 1. you do not describe all variables: what is BUF? sd? s1?
BUF is 1024.
sd is the current 160 character line from the s.d file and it is copied
into s1, which is of size BUF.
> 2. I find it strange that you can figure out that "strcpy(n,s1+TL)" is
> the problematic line, but can not find out why. If you use a
debugger,
> or even if you just insert print statements to dump all pointer
> values and their contents, it should not be too hard to find out what
> is wrong.
Actually, that is exactly how I found what line was causing the problem,
but I cannot figure out why. s1+TL starts at the name ('n' is a
security name and 't' is a ticker symbol), as it should, and terminates
with a new line as it should.
T and n, which are defined in a header file, are used in a number of
other programs which do the same sort of thing but work as expected.
I have tried to use gdb, but I am having problems understanding how to
set it up properly, so I resorted to print statements.
> 3. I tend to evade programming in 70's C, so I may be wrong, but I
> think that the supposedly zero-terminated argument "s1+TL" to that
> strcpy call may be of arbitrary length if the call "fgets(s1, BUF,
> sd)" read less than TL-1 characters.
I wrote this stuff many years ago and I have ****ted it to several
different platforms, including a NeXT. It currently runs on a PC under
Uwin. Usually I have no problems with it. Print statements I used
earlier in tracking this down show that sd has all 160 characters. It
it pretty clear that t is getting stepped on by strcpy but I cannot
figure out how or why.
--
Robert B. Peirce, Venetia, PA 724-941-6883
bob AT peirce-family.com [Mac]
rbp AT cooksonpeirce.com [Office]
|
