C/C++ is not my native platform so playing with patches is not trivial thing
for me. I have (partially) learned it long time ago and now use it only for
POV patching. I'm changing various sourcefiles but I have not natural skill to
select which warning is important. So to extract my own I started to fix
sources to avoid all "built-in" warnings when -Wall setting is used with gcc
3.1 (under DJGPP in my case). I know this effort is nothing becouse POV will
be rewritten but I do it for my knowledge and comfort of compiling. I do all
changes patch-like method controlled with definitions like "#define
AVOID_TYPE_CONVERSION_WARNINGS_PATCH" in frame.h. But I have met two warnings
I can't fix (perhaps there is more but I'm currently did 50% of files). I
looking for help in fixing those warnings:

1. "aggregate has a partly bracketed initializer"

It is reported for line 105 of file_pov.cpp. This line closes definition of
gPOV_File_Extensions array. There is correct number of entries in array
initializer. There is correct number of closing } for {. I have tried to
replace for example every line like:
  { ".jpg",  ".JPG",  ".jpeg", ".JPEG" }, // POV_File_Image_JPEG 
with line like
  { { ".jpg" },  {".JPG"},  {".jpeg"}, {".JPEG"} }, // POV_File_Image_JPEG 
and then compiler reported error instead of warning (sorry, can't recall it's
content here). So how to remove this warning ?

2. "multi-character character constant"

It is reported for some header files like for example povms.h (lines 192-215).
There is a note about this warning in gnu gcc documentation: "Usually they
indicate a typo in the user's code, as they have implementation-defined
values, and should not be used in portable code." Portable code? Hmm, so how
to fix this ?

I have additional platform specific question. I can't write warnings of
compiler with gcc under djgpp to file with simple redirection
  gcc ... > file.txt
It creates file.txt but warnings are outputted to the screen. Is it general
rule for gcc or just problem of djgpp port ? Is there switch in options like
for POV ? I can't find anything like this in documentation. And sorry, I'm not
unixer at all.

ABX

Post a reply to this message

In article <28gtou4t56f843790s28f5r236q80k3boi@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> warnings when -Wall setting is used with gcc

Using all gcc warning is pointless.  Gcc supports 8 and 16 bit platforms,
and many warnings the frontend will emit make a lot of sense when developing
for an embedded processor, but they just waste your time on desktop or
server system.

In particular the implicit type conversion warnings are the biggest nonsense
in both gcc and VC because C as well as C++ explicitly define which implicit
type conversions exist and how they behave.  It is obvious that a compiler
should not warn about perfectly legal and well behaving code by default.  If
it does it tries to enforce a certain style of programming the compiler
developer seems to prefer, but in this case it fails the basic usability
requirement of all software, which is the a machine should never be the
master of a human!

Of course, setting the maximum warning level changes this rule (it should
then warn about everything it can detect), but such a thing does not belong
into the default warning set, but the all warning set (gcc and VC warn by
default about this incorrectly).

In particular important is that explicit conversions, if used incorrectly to
get rid of compiler warnings can degrade performance (because you could be
tempted to first bit-mask integers for example).

On the other hand the compilers do fail miserably to detect truly
non-portable and dangerous code like that in the octree.cpp, also it is well
within their theoretical power to detect such code with little overhead in
their dataflow analysis module...

> 1. "aggregate has a partly bracketed initializer"

No idea what it is complaining about.  The code is perfectly legal.

> 2. "multi-character character constant"

These are nonsensical compiler warnings for perfectly legal and portable
code as long as the platform being used has 32 bit or bigger ints.  As
POV-Ray will not run on 16 bit processors, you can just disable those
warnings, like the compiler developers should have done in the first place
when the target code is for a platform whose ints (or other variable sizes)
can hold the data without problems.

    Thorsten

____________________________________________________
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

On Mon, 23 Sep 2002 10:51:19 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> In particular the implicit type conversion warnings ...

Thanks for your whole note.

> > 1. "aggregate has a partly bracketed initializer"
>
> No idea what it is complaining about.  The code is perfectly legal.

So I will try ask in gcc/djgpp related forums. Perhaps it is some bug.

> > 2. "multi-character character constant"
>
> you can just disable those warnings

I did that quickly.

ABX

Post a reply to this message

On Mon, 23 Sep 2002 10:27:42 +0200, ABX <abx### [at] abxartpl> wrote:
> I can't write warnings of compiler with gcc under djgpp to file

I can, http://www.delorie.com/djgpp/doc/utils/utils_7.html for others.

ABX

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Using all gcc warning is pointless.

  I tend to disagree.

  In our project, which I'm working, we have (at this moment) 71695 lines of
code in 359 source files. We get 0 warnings when compiling with the flags
"-Wall -W -pedantic -ansi". I don't remember making any compromises in order
to keep gcc happy.
  So it's perfectly possible to avoid the warnings.

> In particular the implicit type conversion warnings are the biggest nonsense
> in both gcc and VC because C as well as C++ explicitly define which implicit
> type conversions exist and how they behave.

  You seem to misinterpret the idea behind the warning.
  Yes, the standard defines how explicit conversions work. However, the
idea behind the warning is that converting from a bigger type to a smaller
type loses information and when this is done implicitly, it's often a mistake
from the part of the coder (ie. the coder didn't notice that he is assigning
for example a double to an integer, thus losing information, which could
result in the code not working).
  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" that you are indeed making the conversion deliberately
and that it's not just a programming mistake, and most importantly, it's like
a comment to someone reading your code that "note: there's a conversion done
here". The reader doesn't have to wonder if you just made a mistake there or
you are doing it on purpose.
  Of course the most important use of this warning is when you actually make
the mistake and the compiler warns you and then you can fix it, instead of
wondering why your code doesn't work.

  I see nothing wrong with this.

>  It is obvious that a compiler
> should not warn about perfectly legal and well behaving code by default.

  You seem to think that a warning is the same thing as an error.
  If the code is perfectly legal, then the compiler must not issue an error,
naturally. However, I see nothing wrong in the compiler issuing warnings on
suspicious code, which may be a mistake from the part of the programmer.
  For example, this is perfectly legal:

void foo()
{
  do_something;
  return;
  do_something_else;
}

  However, that looks quite suspicious. The last command is never executed
(and the compiler will most probably just optimize it away). However, it's
quite improbable that the programmer made that deliberately (what's the
point in writing code which is clearly never executed?).
  Of course with code that is as straightforward as that it's pretty obvious.
However, with more complicated code, with many ifs etc, it might not be
as obvious that a certain part is never executed, and thus it's most probably
a programming mistake. The warning is quite useful.

  Warnings are not about the code being legal or illegal. It's about helping
the user with suspicious-looking code.
  Warnings have often helped me catching mistakes at compilation time, which
is a great help.

  Don't bother telling me that a warning has never helped you catching a
mistake, because I won't believe it.

> In particular important is that explicit conversions, if used incorrectly to
> get rid of compiler warnings can degrade performance (because you could be
> tempted to first bit-mask integers for example).

  Even if someone would make that needless bit-mask, any modern compiler
is probably so smart that it will optimize it away.

  Even though many times compilers are quite poor at optimizing some things,
in other cases they are surprisingly clever. For example, I once tested a
code like this:

(with a, b and c being unsigned ints):

  a = (b<<c)|(b>>(32-c));

  When I looked at the asm code generated by the compiler, to my surprise
it had compiled that complicated statement as one single rotation command,
instead of making a substraction, two shifts and an or.

>> 2. "multi-character character constant"

> These are nonsensical compiler warnings for perfectly legal and portable
> code as long as the platform being used has 32 bit or bigger ints.  As
> POV-Ray will not run on 16 bit processors, you can just disable those
> warnings, like the compiler developers should have done in the first place
> when the target code is for a platform whose ints (or other variable sizes)
> can hold the data without problems.

  Are you sure that there may not be a problem with endianess when using
multi-character constants?
  For example, consider a code like this:

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?

  If it does not work, then the warning is very useful.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

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

Thorsten Froehlich <tho### [at] trfde> wrote:
> Why should a compiler force the programmer to bloat the code?

  You are still acting like a warning was an error. The compiler is not
forcing you to do anything.

  And if you want to avoid "bloating the code", then don't use comments at
all and write everything with the minimal amount of whitespace.
  Writing extra code is not always bad, but can be all the contrary. If it
makes the code more clear, then it's good.

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

  I don't understand why you deliberately misread what I said. I didn't
say that the compiler is preventing implicit conversions. I said that if
an implicit conversion is losing information, then that can be a programming
mistake and the compiler is warning about it.
  The compiler does not warn about converting from a smaller type to a
larger one. Why? (Reading your text one would get the impression that
it warns about those as well.)

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

  Now I don't understand. First you say that it's good to have the warning
available, and immediately after that you say that it should not be issued.
Which is it?

> let me show this by a different example:  Does gcc issue a warning if

  I know that gcc does *not* warn about many things it should, and I could
list quite many things here if I wanted. However, I don't see how that is
relevant to the question that gcc *does* warn about some other things.

  I don't understand the ideology "if it doesn't warn about this, it shouldn't
warn about anything at all".

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

  I fail to see where does that code write anything to a file.

  But as you say, that code is not good, and the compiler warning about it
is only a good thing, don't you think?
  You are saying that the compiler should not warn about that (because it
will not warn if you compare the int you read from the file with a constant,
because that's just way too difficult for the compiler to catch).

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

  I am a professional. I make mistakes. The compiler has sometimes helped me
finding them.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

On Mon, 23 Sep 2002 13:58:15 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> 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.

I did not mean to start another war in the cream of our small society. My
intention was to remove some obvious typos. For example: there is a lot of
calls to compile_instruction() function in fncode.cpp where fourth parameter
is 0. But for some strange reason three of them use 0.0 instead of 0. I can't
call it 'favourite coding style' becouse other calls clearly shows this
favourite style. I think one thing is legal code, second is legal, clean and
consistent code. Just two cents from amatour C programmer.

ABX

Post a reply to this message

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

>>  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.
>
>   I don't understand why you deliberately misread what I said. I didn't
> say that the compiler is preventing implicit conversions. I said that if
> an implicit conversion is losing information, then that can be a programming
> mistake and the compiler is warning about it.

No, you said "What gcc is doing is to recommend you to make the conversion
explicit." and I never said what you imply, so this is pointless.

In any case, I don't have the time to waste in another game with you trying
to turn my words around until they say something you don't like.  I said
what I said and it is very clear, if you don't understand it, so be it.

I am leaving this discussion here, simply ignoring the rest of your post.

    Thorsten

____________________________________________________
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

In article <gr0uoucgievsj2oa80j8cuqner7e9j7ean@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> there is a lot of
> calls to compile_instruction() function in fncode.cpp where fourth parameter
> is 0. But for some strange reason three of them use 0.0 instead of 0

Oh, this is easy.  It so happens that the constant table defines the
constant at array locaction "0" to be zero and the constant at array
locaction "1" to be one.  For maximum clarity, replace it with
"POVFPU_AddConstant(0.0)", which will have the same effect.

    Thorsten

____________________________________________________
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