Re: problem with output of the program on different OS

pereges said:

> What text editors do you personally prefer while working
> on linux ?

vim

> What about vi ?

On my machine, 'vi' is an alias for 'vim'.

> On windows machine, I use Qeditor

gvim

<snip>

> And it would
>> not hurt to initialise index to -1 at this stage. If it remains -1
after
>> the loop, the original program was clearly assuming that the loop was
>> always setting this value,

<snip>

> I think this is not the problem.

Your code has many problems. This may be one of them.

> It is possible that index will be -1
> for many rays and its perfectly normal. The index value is just there
> to indicate which triangle the ray has hit. It is possible that the
> ray does not hit any triangle.  I have a member in the intersectresult
> data structure called 'hit'. If the ray does not hit any triangle,
> then hit will remain FALSE. index will probably contain some garbage
> value.

In your original code, its value is indeterminate under those 
cir***stances, and evaluating an indeterminate value means undefined 
behaviour. It's almost certainly not causing your problem, but "almost 
certainly" != "certainly"! Fix all the bugs, not just the ones that you 
think are im****tant. By all means fix the im****tant ones first, but don't 
ignore things you know are wrong but guess aren't a problem - your guess 
could be wrong.

You asked for hints on coding style, and that's one of them - *always*
make 
sure that a value is determinate before accessing it.

> But that's irrelevant

That's a guess, and it could be a wrong guess.

<snip>

>> Second fix to this file: in the raytrace() function, i is unused, so I
>> removed it.
> 
> Do you think its dangerous to have such declarations in bigger
> projects ?

No, but I think it's poor style. The less code you have, the less code you

have to read and understand. Removing dead code is good housekeeping, and 
will leave you with less clutter to wade through. This makes your life 
easier.

>> Well, I had to dig through three layers of #include before finding an
>> include for math.h. Not funny. Still, it's there somewhere.
> 
> My idea was to have such declarations at one place. Hence, I included
> it in common.h.

That's not a new idea, but whether it's a /good/ idea is a matter of 
opinion. Some people, no doubt, will agree with you about this. Maybe even

some experts will agree with you about this. Personally, I'd rather see 
the standard headers included in the source where they're needed. 
Otherwise, the reader has to either trust that you've remembered to 
include them or go looking to make sure. Neither is comfortable.

<snip>

>> I recommend that you plug this version in, and re-test. Do any of the
>> assertions fail? If so, that may well be your problem.
> 
> Yes, there is some problem while compiling radar.c.
> 
> The problem is with the assert(*numpoints >= 0) statement on line
> number 32 of radar.c as re****ted by pellesC compiler:
> 
> Building radar.obj.
> C:\Do***ents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32):
> warning #2130: Result of unsigned comparison is constant.

Oh, it's unsigned long *. I didn't notice that. Fair enough - the
assertion 
is unnecessary in that case, since *numpoints can't be negative. So /that/

assertion can be removed.

> C:\Do***ents and Settings\abc\Desktop\raytrace\raytrace\radar.c(32):
> fatal error: Internal error: 'Access violation' at 0x004083f3.

Interesting. That suggests that the pointer is NULL or indeterminate. But 
it can't be NULL because I inserted a check: assert(numpoints != NULL);

So it must be a bad pointer. Check the calling code.

<snip>

> BartC has obtained similar results using the PellesC compiler but he
> is getting different result when using dmc, lccwin, gcc on
> windows( all the three results using dmc, lccwin, gcc are same though
> for the above input). Can you please tell me what result you have
> obtained on your linux machine ? Are the results consistent everytime
> the program is executed ?

I haven't got as far as executing it yet. When I get some more time, I'll 
do some more code clean-up. When eventually I get around to executing it, 
I'll post the result here.

-- 
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www.
+rjh@[EMAIL PROTECTED]
 users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999