Date: Fri, 14 Mar 2008 19:49:29 -0700 From: Doug Hardie <bc979@lafn.org> To: Derek Ragona <derek@computinginnovations.com> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: C compiler issue perhaps? Message-ID: <EE488DB7-2E54-48F5-A3E2-1357BF848978@lafn.org> In-Reply-To: <6.0.0.22.2.20080314202817.025de470@mail.computinginnovations.com> References: <A768FF06-4601-42C6-A491-634F5135DCCD@lafn.org> <6.0.0.22.2.20080314171533.023f7c88@mail.computinginnovations.com> <511EC772-36FD-4799-B4A1-3AE690B6D048@lafn.org> <6.0.0.22.2.20080314202817.025de470@mail.computinginnovations.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 14, 2008, at 18:31, Derek Ragona wrote:
> At 06:56 PM 3/14/2008, Doug Hardie wrote:
>> There is no code running at that point. Its just sitting there
>> waiting for me to enter a gdb command.
>>
>>
>> On Mar 14, 2008, at 15:16, Derek Ragona wrote:
>>
>>> At 05:10 PM 3/14/2008, Doug Hardie wrote:
>>>> I have a program I was testing with gdb. I was trying to figure
>>>> out
>>>> why c.rmonths was always zero when it should have been 6. Stepped
>>>> through using the gdb n command. Here is the output:
>>>>
>>>> (gdb)
>>>> 215 c.rmonths = (edate - tdate) /
>>>> toMONTHS;
>>>> (gdb)
>>>> 223 c.dial_in = u.dial_in[0];
>>>> (gdb)
>>>> 224 c.dsl = u.dsl[0];
>>>> (gdb) p c.rmonths
>>>> $1 = 0
>>>> (gdb) p c
>>>> $2 = {fa = 0, pwp = 0, disp_email = 0, imonths = 0, rmonths = 6,
>>>> type = 73 'I', cd = 0 '\0', dial_in = 82 'R', dsl = 0 '\0',
>>>> dsl_kit = 0 '\0', ip = 0 '\0', domain = 0 '\0', n_domain = 0
>>>> '\0',
>>>> renewal = 89 'Y', program = "I\000\000"}
>>>> (gdb) p c->rmonths
>>>> $3 = 6
>>>> (gdb) p c.rmonths
>>>> $4 = 6
>>>>
>>>>
>>>> Notice, the first time i print it its zero. The second time its 6.
>>>> What gives here? I have seen this before but couldn't pin it down.
>>>> The program is not compiled with any optimization. It is in a
>>>> shared
>>>> library though.
>>>
>>> It is hard to tell without the code you used. I would put some
>>> printf's in the code and see what and when that variable gets set to
>>> in actual running code.
>>>
>>> -Derek
>
> I understand it is waiting at a breakpoint in gdb. What I meant was
> put printf's in your code and run the program and look at the
> output. You can use fprintf's to stderr if your prefer and just
> look at the stderr output.
>
> It is hard to diagnose what could be a compiler error, or a coding
> error. Remember in C you can do many things you really shouldn't.
> It is also advisable to run lint over your source code too.
All that lint shows is it doesn't like comments using // and lots of
errors in /usr/include files.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EE488DB7-2E54-48F5-A3E2-1357BF848978>