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

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

Is this replacement for all 0 and/or 0.0 ? Does this influence only parsing
time?

ABX

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> ignoring the rest of your post.

  A lesson in politeness?

-- 
#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 <687uouc7i1dtlqjjj2coji4lq7d2a7ej9s@4ax.com> , ABX 
<abx### [at] abxartpl>  wrote:

> Is this replacement for all 0 and/or 0.0 ? Does this influence only parsing
> time?

For the 0.0 only.  It does not really influence parsing time.

    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