In article <36C52BCA.8AED0DA7@geocities.com> , "Jon A. Cruz" 
<jon### [at] geocitiescom> wrote:

> Yes, I understand much of this, but... the benefit I found in cleaning up
> those warnings in other work helped in cleaning up code I've done in various
> cross-platform work (DOS, OS/9, Win16, Unix, Win32, Linux ).

So far, there have been no (major) problems with POV-Ray in cross-platform
functionality...

> One side effect is that all those float/double warnings make it hard to spot
> the significant warnings such as those from truetype.c:
>
> warning C4101: 'i' : unreferenced local variable

Compilers in general don't generate any code for unused variables...so this
is not serious, it only shows the constant development of the source code
:-)

> warning C4018: '<' : signed/unsigned mismatch

This is more interesting, but most likely not that serious at all.

> warning C4244: '=' : conversion from 'unsigned short ' to 'unsigned char ',
> possible loss of data
> warning C4244: '=' : conversion from 'double ' to 'short ', possible loss of

I have not tried, but if you do an explicit type cast, does this warning go
away?   (And personally, I think that the warning "possible loss of data" is
a very bad wording, the correct wording for this is "possible loss of
precision"...well MS calls "bug fixes" "service packs", so I guess for them
it makes sense ;-)

> warning C4700: local variable 'len' used without having been initialized

This warning is mileading (also it is correct), this is the only case in the
source code this happens: len is passed by pointer to a function that then
returns a value though it.

> Personally, I think the "unreferenced local variable" warnings that MS pops
> out (even on it's java compiler) are extremely handy.

Yes, they are useful! I don't know any compiler that does not have at least
a switch to do so. :-)

> Also, the signed/unsigned
> mismatch gets very significant for font glyphs where the values are 16-bit
> Unicode glyphs that are getting mapped from 8-bit chars, etc.

Yes, it does.

> So, I have the float/double issue to mask and investigate later. Any others

Please read my reply to Ron Parker regarding the float/double conversion as
well. Personally I think that there is no reason to change this at all, why
change code that hasn't created to any problems in the last 8 years?

> that I should be aware of, or should I just go head and do some nit-picking
> and submit my changes? (I know not to complain about anything without be
> willing to do something about it).

As Chris Young announced, there will be a 3.5 version. So just that you
don't do done work again: Cleaning up the unused variables, "len" not being
initialized and the unsuded function argument warnings have been cleaned up.
If you have more/other changes (like the Unicode patch) I would suggest to
e-mail Chris Young (C_Y### [at] compuservecom), explain your changes and ask
him how to submit them (don't send a large file at once). He gets a lot of
e-mail (I guess) and it might take a few days for him answer your e-mail.

Oh, and please be very careful when changing/using types. I saw in your
Unicode patch (at least in the first version) that you used wchar_t. This
might work with most compilers, but USHORT is the type to use in truetype.c.
This helps a lot when integrating a patch.


    Thorsten

Post a reply to this message