Ron Parker wrote:
> 
> You only get 710? :)  Most of them are precision warnings, which are really
> kind of a nitpicky kind of warning anyway.  I've always just ignored them,
> until I can find the time to sit down and fix every single one, or someone
> else can.  There's definitely a lot of float->double->float conversions going
> on in various places, but fixing them would be quite a chore.

The MS compliler (at least VC 6) complains about const double -> float
assignments, like:

  float x = 2.0;

Which makes for even more warnings.

-Nathan

Post a reply to this message

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

> Just as an aside, when I built the source using VC 5, I get about 710
> warnings.

Wow! I get 1592 warnings if I activate the warnings for "implicit aritmmetic
conversions" and "unused arguments".
The point is that the implicit aritmmetic conversions are explicitly
mentioned in the ISO C++ standard and therefore are no code problem. Most
compilers have an option to show these warning. Just find the compiler
switch and deactivate them. The same goes for (currently) unused arguments.

All these warnings are for some reason part of the warning level 1 in VC 5.
The only lower level is level 0 which deactivated all warnings.
I leave it to you to imagine why Microsofts thinks it needs do warn users if
_well documented_ (and used for decades) *ISO* standard behaviour is
expected by the source code (programmer)...
However, you find what the MS progammers think of the standard in remarks
like those for warning C4800.

> In my experience this is not the best state to leave code in, so what's the
> current status on this?

Well, VC 5 is everything but confrom to any C/C++ standard, so don't expect
that all warnings it shows will ever be eliminated :-)  Most of its C++
warnings or errors are simply _wrong_ if you comapre it to the ISO C++
standard. I hope (but don't know) that most of these compiler bugs are fixed
in VC 6. If they are not, just use a different compiler. Watcom or
CodeWarrior will do and will generate much faster code as well. The problem
is that they are expensive.


    Thorsten


From the ISO 14882 standard (ISO C++ standard):

4 Standard conversions [conv]

1 Standard conversions are implicit conversions defined for built-in types.


4.8 Floating point conversions [conv.double]

1 An rvalue of floating point type can be converted to an rvalue of another
floating point type. If the source value can be exactly represented in the
destination type, the result of the conversion is that exact representation.
If the source value is between two adjacent destination values, the result
of the conversion is an implementation-defined choice of either of those
values. Otherwise, the behavior is undefined.


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csicom

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://www.povray.org

Post a reply to this message

In article <36c429f4.0@news.povray.org> , par### [at] my-dejanewscom (Ron 
Parker) wrote:

> You only get 710? :)  Most of them are precision warnings, which are really
> kind of a nitpicky kind of warning anyway.  I've always just ignored them,
> until I can find the time to sit down and fix every single one, or someone
> else can.  There's definitely a lot of float->double->float conversions going
> on in various places, but fixing them would be quite a chore.

Ron, it is nearly useless to try to remove this because it all is a result
of the macro DBL. If a platform defines it to float you get different
problems. If you add explicit type casts it will even be dangerous for other
platforms: You force the compiler to convert the type and if the platform
does not support native double precision floating point values, it will
rsult in much slower execution.


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: Tho### [at] csicom

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://www.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> > In my experience this is not the best state to leave code in, so what's the
> > current status on this?
>
> Well, VC 5 is everything but confrom to any C/C++ standard, so don't expect
> that all warnings it shows will ever be eliminated :-)  Most of its C++
> warnings or errors are simply _wrong_ if you comapre it to the ISO C++
> standard. I hope (but don't know) that most of these compiler bugs are fixed
> in VC 6. If they are not, just use a different compiler. Watcom or
> CodeWarrior will do and will generate much faster code as well. The problem
> is that they are expensive.
>

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 ).

Now, the float/double issue could stand some investigation, and that is exactly
the kind of information I was looking for.

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
warning C4018: '<' : signed/unsigned mismatch
warning C4244: '=' : conversion from 'unsigned short ' to 'unsigned char ',
possible loss of data
warning C4244: '=' : conversion from 'double ' to 'short ', possible loss of data

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

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


So, I have the float/double issue to mask and investigate later. Any others 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).

Post a reply to this message

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

Thorsten Froehlich wrote:

> 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.
>

Yes, that's probably the area that I need to watch the most. I won't consider my
code done 'till that kind of stuff is all resolved.

With wchar_t itself you get the same issue as with the float/double conversions
and int size. It's designated to contain Unicode characters, but may or may not be
16-bits. Some systems are reported to be using 32-bits for processor efficiency,
so just imagine if I pass an array of 16-bit values to a C call expecting 32-bit
values.

So, that's why I start with wchar_t. If, however, no wide-char API calls are made,
then USHORT should be no problem.

Oh, and I'll wait on the cleanup. I can always run my compiler output through
grep. See, it's good to ask these things, so as not to duplicate effort.

BTW, anyone compiling POV-Ray for 64-bit processors?

Post a reply to this message

In article <36C### [at] geocitiescom> , "Jon A. Cruz" 
<jon### [at] geocitiescom> wrote:

> With wchar_t itself you get the same issue as with the float/double
> conversions  and int size. It's designated to contain Unicode characters, but
> may or may not be 16-bits. Some systems are reported to be using 32-bits for
> processor efficiency, so just imagine if I pass an array of 16-bit values to a
> C call expecting 32-bit values.
>
> So, that's why I start with wchar_t. If, however, no wide-char API calls are
> made, then USHORT should be no problem.

There are no C calls that expect it, wchar_t is a C++ keyword and there is
no standard C library that will expect or take it.


    Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> In article <36C### [at] geocitiescom> , "Jon A. Cruz"
> <jon### [at] geocitiescom> wrote:
>
> > With wchar_t itself you get the same issue as with the float/double
> > conversions  and int size. It's designated to contain Unicode characters, but
> > may or may not be 16-bits. Some systems are reported to be using 32-bits for
> > processor efficiency, so just imagine if I pass an array of 16-bit values to a
> > C call expecting 32-bit values.
> >
> > So, that's why I start with wchar_t. If, however, no wide-char API calls are
> > made, then USHORT should be no problem.
>
> There are no C calls that expect it, wchar_t is a C++ keyword and there is
> no standard C library that will expect or take it.
>

But it is in C. It is in Normative Addendum 1. I was just using that as an example.
People working on internationalization stuff on Windows or Intel Linux might assume
16-bit when it gets 32 bits. Also, besides the standard, it is possible for people
to write routines (like the ones I did in uniutils.c) that operate on theses, and
then the difference would matter. That is what will probably have the most impact,
so the proper considerations should be made. That's all.

Post a reply to this message

In article <36C### [at] geocitiescom> , "Jon A. Cruz" 
<jon### [at] geocitiescom> wrote:

> But it is in C. It is in Normative Addendum 1.

Hmm, I don't have the ISO C standard documentation nor its later changes,
but my point was that it is not used in the standard C library.


    Thorsten

Post a reply to this message

>> You only get 710? :)  Most of them are precision warnings

>Ron, it is nearly useless to try to remove this because it all is a result
>of the macro DBL

DBL x = 2.0;

becomes

DBL x = (DBL) 2.0;

Is there anything unreasonable or dangerous about doing this?
I think it is worth keeping the MS compiler quiet, because sometimes
things like signed/unsigned, unused, uninitialised variable, actually
help solve problems.

Has anyone run POV through Purify, or Bounds Checker?

Post a reply to this message