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

>  Are you doing thus simply to taunt me?

By now I am repeating it to tease you...

>   It seems impossible for you to understand that 'abcd' produces a different
> value depending on the platform you are compiling to.

No, I just fail to see is how this can possible cause a problem if the value
never leaves or enters the program.  If you can demonstrate that this, which
is the only way it is even useful in POV-Ray, can cause any problem, please
go ahead.  But don't criticize code for something it isn't even doing.
Maybe you should check what the code is doing with it...

    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

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, I just fail to see is how this can possible cause a problem if the value
> never leaves or enters the program.  If you can demonstrate that this, which
> is the only way it is even useful in POV-Ray, can cause any problem, please
> go ahead.  But don't criticize code for something it isn't even doing.
> Maybe you should check what the code is doing with it...

  So what you are saying is that since POV-Ray does not use the multichar
constants in the wrong way, then they should remove that warning from gcc?
  Have you ever thought that POV-Ray is not the only program in the world?

  When I deliberately put a camera inside a non-hollow object, POV-Ray still
warns me about it, even though I am not doing anything wrong nor illegal.
I still don't see how this warning makes POV-Ray broken.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

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

>> No, I just fail to see is how this can possible cause a problem if the value
>> never leaves or enters the program.  If you can demonstrate that this, which
>> is the only way it is even useful in POV-Ray, can cause any problem, please
>> go ahead.  But don't criticize code for something it isn't even doing.
>> Maybe you should check what the code is doing with it...
>
>   So what you are saying is that since POV-Ray does not use the multichar
> constants in the wrong way, then they should remove that warning from gcc?
>   Have you ever thought that POV-Ray is not the only program in the world?

No, I said a compiler should not warn about correct code, which can be found
in millions of other programs as well.  If some people don't know C well
enough they deserve to be burned by their own mistakes.  The compiler should
not help me with thinks I know by default.  I said this before, didn't I?

So please, please, please, stop twisting my words around to claim things
they neither say directly nor can possibly say indirectly between the lines.

>   When I deliberately put a camera inside a non-hollow object, POV-Ray still
> warns me about it, even though I am not doing anything wrong nor illegal.
> I still don't see how this warning makes POV-Ray broken.

Well, POV-Ray will not and cannot function as expected.  So yes, it should
probably issue an error message...

    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

I think compiler warnings is an issue where no agreement is
possible.  I have worked for nearly 10 years with a group of
about 20 software developers.  They use a tool called
flexlint to scrub their C++ code.  They are a relatively
tight nit group, but I listened to them argue over this rule
and that rule for years.  They eventually dropped into a
voting system - some having larger votes - whenever deciding
to add or remove a check. This didn't make everyone happy
but things got done faster.

When communicating in non-native languages I try to remember
not to assume much emotional meaning in what is said.  It is
difficult enough to communicate with a person you know well,
in your native tongue and with them standing in front of
you.  Communication in a space like a newsgroup, in a second
language, with cultural differences - it is easy to end up
with everyone shouting into space.

Every one of you involved in this discussion is technically
competent. There are a thousand ways to roll a stone.

Post a reply to this message

In article <3D9A0B14.3082321F@attglobal.net>,
 "William F. Pokorny" <pok### [at] attglobalnet> wrote:

> Every one of you involved in this discussion is technically
> competent. There are a thousand ways to roll a stone.

Actually, there are infin...oh, never mind.

;-)

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, I said a compiler should not warn about correct code

  As I have said earlier, you are constantly confusing warnings with
error messages.

  Please read my lips: A warning is not an error message.

  Do you understand what does that mean?

  Error messages are issued when the code is incorrect. An error message
stops the compilation.
  When the code is correct, but suspicious, a warning can be issued. A
warning does not stop the compilation.
  Do you understand the difference between these two things?

  So what you are saying is wrong: Warning *must* warn about correct code,
and correct code alone. If incorrect code would only generate a warning,
that would be wrong. Incorrect code must generate an error.

  You also seem to fail to understand *why* warnings exist in the first
place.

> Well, POV-Ray will not and cannot function as expected.  So yes, it should
> probably issue an error message...

  Wrong. If there is no media nor fog in the scene, POV-Ray can function
correctly and moreover *does* function correctly. There's nothing wrong
in putting the camera inside an object. It's not an error and thus issuing
an error would be wrong.
  The point is that it can have some side-effects which are unexpected if
the scene uses fog or media and thus the warning is relevant.

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

ABX <abx### [at] abxartpl> wrote:
> #define FOURCHARS_TO_INT(c1,c2,c3,c4) \

  Just to clarify things:

  I completely agree with Thorsten that this is bad. You should not make
ugly hacks in order to avoid a warning which you *know* is irrelevant for
the code in question. I completely oppose this suggestion.
  If you can get rid of a warning in a way that: a) does not actually
modify the actual code, but simply adds extra unambiguating syntax to
it (such as extra parentheses to unambiguate an expression) and b) makes
the code cleaner and clearer, then it may be ok to do it.
  However, if you are going to actually modify how the code works just
to get rid of an irrelevant warning, and the resulting code is uglier,
clumsier and even more dangerous, then that's definitely a no-no.

  So I fully agree with Thorsten with this.

  However, what I strongly disagree with is that gcc is somehow "broken"
or is a bad compiler because of this warning.
  The warning may be irrelevant in *this specific case*, ie. the POV-Ray
code, but that does not mean it's *always* irrelevant in all cases which
exist in the world.
  I also disagree with the idea that a compiler should not issue any
warnings about code which is correct according to the C++ syntax definition.
The fact that a piece of code is syntactically correct does not mean that
it works ok. That's exactly what warnings are for: To inform you that
the piece of code you just wrote might not work as you want. The warning
might be irrelevant in some cases, but it still can be of great aid in
many cases.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3d9a4b7e@news.povray.org:

> ABX <abx### [at] abxartpl> wrote:
>   I also disagree with the idea that a compiler should not issue any
> warnings about code which is correct according to the C++ syntax
> definition. The fact that a piece of code is syntactically correct does
> not mean that it works ok. That's exactly what warnings are for: To
> inform you that the piece of code you just wrote might not work as you
> want. The warning might be irrelevant in some cases, but it still can be
> of great aid in many cases.

I agree. A simple case is the line:
  if (a = b)
It is perfectly legal in C, but at some warning level, the compiler howls...

And I agree with it. I may wanted to check if b is non-null, but most of the 
case, I just failed to type two equal signs.

If I want to do:
  if (f = Foo())
to check if Foo is not returning an error status, I should instead write:
  if ((f = Foo()) != 0)
which is uglier, but less prone to errors or ambiguity.

I know that some coders prefer to write:
  if (Foo() == f)
because if they forget an equal, an error will be thrown. But I don't like 
much this form, habits, you know?

BTW, I write now:
  f = Foo();
  if (f != 0)
which is more elegant, easier to read, and probably as efficient.
Some may object it wastes space (see the hot discussion about soft braces 
placement...) but I now prefer a nice layout to a compact one.
There was a time were I admired C's compactness (coming from Basic and 
Pascal worlds), but experience changed that :-)

BTW, removing warnings is not a futile task.
Lua programmers take careful steps to maintain strict ANSI C compliance, so 
their code is very portable. Sometime, when compiling with VC++, I get some 
warnings. Most of the time, they correct the code (mostly to add some 
explicit casts).
It allows:
- to insure no ambiguity (because of default rules) remains;
- to avoid inundating the poor programmer with a lot of harmless warnings, 
letting him miss the important ones...

Last note: you can't please everyone, including compilers.
Lua has the following function:
  static int io_exit (lua_State *L) {
    exit(luaL_opt_int(L, 1, EXIT_SUCCESS));
    return 0;  /* to avoid warnings */
  }
Well, VC++ issues a warning on the return line:
D:\Programmes\Langages\Lua\src\lib\liolib.c(565) : warning C4702: 
unreachable code
Both are right, of course. :-)
Note: the function must return an int because it is the signature of all Lua 
functions (called by the interpreter).

-- 
--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--=#=--
Philippe Lhoste (Paris -- France)
Professional programmer and amateur artist
http://jove.prohosting.com/~philho/

Post a reply to this message

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

>   I also disagree with the idea that a compiler should not issue any
> warnings about code which is correct according to the C++ syntax definition.

Well, if you don't read carefully you will of course continue to miss that I
am complaining about the default warnings.  Not about being able to enable
other warnings.  In fact, I made this clear early in this thread.

It is hard to argue if you either intentionally misunderstand what I say or
simply intentionally forget it.

    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 <Xns### [at] 204213191226> , Philippe Lhoste 
<Phi### [at] GMXnet>  wrote:

> Warp <war### [at] tagpovrayorg> wrote in news:3d9a4b7e@news.povray.org:
>
>>   I also disagree with the idea that a compiler should not issue any
>> warnings about code which is correct according to the C++ syntax
>> definition. The fact that a piece of code is syntactically correct does
>> not mean that it works ok. That's exactly what warnings are for: To
>> inform you that the piece of code you just wrote might not work as you
>> want. The warning might be irrelevant in some cases, but it still can be
>> of great aid in many cases.
>
> I agree.

Well, Warp intentionally misrepresented what I said in order to argue about
something else just for the sake of argument.  I never disagreed on the
point he makes, in fact I made very clear:

In article <3d8ed609$1@news.povray.org> , "Thorsten Froehlich"
<tho### [at] trfde> wrote:
> 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).


    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