In article <3d8efa91@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   What gcc is doing is to recommend you to make the conversion explicit.
> That has absolutely no effect in performance, as it's converted to the
> exact same code internally, and it makes your code more clear: You are
> kind of "documenting"

Why should a compiler force the programmer to bloat the code?  If those who
specified the standards had intended to prevent implicit conversions they
could have done so.  It is not the compiler writers job to second-guess
those who made the standard nor those who write code following the standard.

As I pointed out, it is good to have such a warning available, just like
many other warnings; but this does not imply that legal code should cause
any warning.

let me show this by a different example:  Does gcc issue a warning if I call
a function inside the argument list of another function, for example
"foo1(foo2(),foo3(),5)"?  My guess would be no seeing many people make such
a mistake by having foo2 and foo3 depend on some order.

I assume you agree with me that here not only something implicit is going
on, but also something implementation defined.  Yet there is no warning, or
maybe in the latest gcc versions there is...?

So, why warn for the well-defined implicit conversion but not for the much
more dangerous function call? -- I already answered this as it is the
compiler writers personal opinion that all conversions should be explicit.
That is fine, but as the standard does not cover this the compiler is
issuing the warning incorrectly if, and only if, it was not requested to
issue this warning by the programmer.

> You seem to think that a warning is the same thing as an error.

Please quit this nonsense.

>  Are you sure that there may not be a problem with endianess when using
> multi-character constants?

Yes.

> FILE* infile = fopen(...);
> int fileID;
> fread(&fileID, 4, 1, infile);
> if(fileID != 'RIFF') { error("Wrong file type"); }
>
>  Will that work in a high-endian/low-endian system?

Your example by itself is incorrect because writing any type to a file is
specified to be implementation defined.  It has nothing to do with a
multicharacter constant.  It will fail if you write for example the integer
1234567 to a file as well.  Obviously the compiler does not warn you about
specifying integers.  And nobody claimed a multicharacter-constant is a
string, expect I missed that so far!

Again you are claiming something to be suspicious which is well-defined
within the standard.  If the compiler writers do not like multi-character
constants, that is again their personal opinion.

Those who specified the standards, which, as I should add, have been
extensively peer-reviewed, simply did something this particular compiler
writer does not like.  That does not entitle the compiler writer to let the
compiler issue a warning by default.

To clarify my point:
* By default a compiler should only issue warnings if some assumption made
by the program is ambigious by the standard specification itself (there are
several such cases).
* A compiler should offer additional warnings for all logical program it can
detect.
* The compiler writer has to assume the user of the compiler is a
professional just like he is and knows what he is doing.  The compiler
writer may not try to teach the compiler user by default.


    Thorsten


PS:  The correct terms are Little Endian and Big Endian.

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message