Thorsten Froehlich <tho### [at] trfde> wrote:
> No, this is incorrect!  All it does is trick the compiler in shutting up
> with its nonsense messages while changing absolutely nothing for the broken
> compiler

  You are starting to be quite irritating.
  If you say that "broken compiler" thing once or twice, then it's an opinion,
but when you start to repeat over and over, it starts to be an obsession.
An irritating obsession.

  Just imagine that someone would start to post messages about povray warning
about the camera being inside a non-hollow object in perfectly legal scenes
over and over, and calling povray "broken" and similar derogatory names. That
would certainly irritate many people.

  One thing is to whine about a warning you think is irrelevant, and another
totally different thing is to say that the program is broken because of this
irrelevant warning. It's a kind of insult.

  So would you stop, please?

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

>> Line numbers don't help me much (they change...).  I need the function name
>> :-)
>
> There is only one occurance of it in that file - it is case kPOVMSType_Long in
> POVMSObject_DumpAttr function.

Nope, but change the type of h and l to int and unsigned int respectively.

    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 <3d983ba2@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Just imagine that someone would start to post messages about povray warning
> about the camera being inside a non-hollow object in perfectly legal scenes
> over and over, and calling povray "broken" and similar derogatory names. That
> would certainly irritate many people.

IIRC, this is a known bug:  <http://www.povray.org/download/3.5-bugs.php>

So in this regard POV-Ray is "broken".  Not seriously "broken", of course.

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

> I still wonder it is correct to use
> implementation dependand features.

Well, unless you don't want to use any POD types you will have to.  As you
know, the precision of ints, floats, doubles, or even if chars are signed or
unsigned by default is implementation defined as well.  Just like many other
things.  Otherwise C/C++ would not be such powerful languages and we would
still be writing device drivers in assembler - not that that would always be
a bad thing, but still ;-)

    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 in message:
> If you mix a programmer defined implementation with an implementation
> defined implementation.

Could you please tell us why do you have to mix? It seems to be somewhat
unfair to compare your code to the code with *artificial* flaws... Why
cannot you just write

    unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');

    if(prog == FOURCHARS_TO_INT('A','B','C','D'))
        puts("equal");
    else
        puts("not equal");

and get rid of unnecessary wornings? That would certainly be a better
quality code.

Post a reply to this message

In article <3d997467$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> Could you please tell us why do you have to mix? It seems to be somewhat
> unfair to compare your code to the code with *artificial* flaws... Why
> cannot you just write

Because there is no need.  With the original code there is nothing wrong,
and in real code, not the trivial example i give, nobody could tell why it
would not work.  Adding traps for programmers in legal and well working code
just to silence a compiler warning in some broken compilers is not exactly a
good solution...

    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 <3d997467$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

>     unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');
>
>     if(prog == FOURCHARS_TO_INT('A','B','C','D'))
>         puts("equal");
>     else
>         puts("not equal");
>
> and get rid of unnecessary wornings? That would certainly be a better
> quality code.

By the time when cluttering code with unnecessary macros is considered
better code, I am going to jump out of the window!

    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:
> By the time when cluttering code with unnecessary macros is considered
> better code, I am going to jump out of the window!

By "better quality code" I mean the code that

1) generates less worning messages and thus

2) is less likely to fail.

As to the first point, I consider this a big virtue by itself -- at the very
least helping to spot warnings issued for actually buggy code. I for one
always use a custom POV-Ray compile, with my own additions, and mind you: it
is a real pain dealing with all those 3.5 changes that generate so many
warnings.

As to the second... Thorsten, believe it or not, compiler writers are not
idiots. Not all of them. There ARE cases when simple multi-character
constants would not work, while #defines or similar means would rectify the
situation... For instance, you cannot write a RIFF chunk ID like you do, you
have t use FOURCCs. Well, as far as I can tell (and I know you good enough
by now), at this point you would argue about the "broken format of a broken
OS", and "general inability to provide portable solutions for binary
formats", right? Then consider writing/reading text files:

  unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');
  fprintf(outfile," %lu", prog);
  ...
  fscanf(infile," %lu",&prog);
  if( prog==FOURCHARS_TO_INT('A','B','C','D')) { ... }

This code would work ACROSS MOST platforms. While alternative (your)
approach would fail if files are to be transferred between e.g. PCs and old
Macs (with their Motorola 68k BE CPUs). And even if we are to port it to
some EBCDIC-based dinosaur, we still can just modify the macro definition
accordingly, not every piece of code dealing with constants. So the code is
MORE portable and thus BETTER. Please note: not "absolutely portable and
thus the BEST", but still worth trying.

Post a reply to this message

In article <3d9980e2$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> 1) generates less warning messages and thus

It only generates warnings on broken compilers.  If the compiler you use is
broken, the solution is to switch to a compiler which is not broken or to
workaround the broken compiler by disabling the particular warning by hand.

> 2) is less likely to fail.
<snip>
> As to the second... Thorsten, believe it or not, compiler writers are not
> idiots. Not all of them. There ARE cases when simple multi-character
> constants would not work, while #defines or similar means would rectify the
> situation...

No, this is nonsense.  They do work as specified everywhere!

Your example is yet again one of those reading data from disk misuse cases.
Maybe you do not understand that "implementation defined" is exactly what
you show?  It does not even have to work when using two compilers on the
same platform.  An "implementation" is a single compiler on a single
platform.

Maybe you have not noticed, but POV-Ray neither reads nor writes
multicharacter constants.  It does not because that behavior is
implementation defined.  So there is absolutely nothing wrong and nothing
that can ever break anywhere either.

>   unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');
>   fprintf(outfile," %lu", prog);
>   ...
>   fscanf(infile," %lu",&prog);
>   if( prog==FOURCHARS_TO_INT('A','B','C','D')) { ... }
>
> This code would work ACROSS MOST platforms. While alternative (your)
> approach would fail if files are to be transferred between e.g. PCs and old
> Macs (with their Motorola 68k BE CPUs). And even if we are to port it to
> some EBCDIC-based dinosaur, we still can just modify the macro definition
> accordingly, not every piece of code dealing with constants. So the code is
> MORE portable and thus BETTER. Please note: not "absolutely portable and
> thus the BEST", but still worth trying.

I am not really sure if I should be upset or offended by such ignorance as
this issue has already been discussed and explained well in this thread.
Please read the whole thread first before repeating something already
discussed.  If you don't want to read the whole thread, please stop adding
noise to the discussion.


    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:
> It only generates warnings on broken compilers.

  Are you doing thus simply to taunt me?

  It seems impossible for you to understand that 'abcd' produces a different
value depending on the platform you are compiling to.
  If you, for example, read four bytes from a file to an integer and then
compare it with 'abcd', the result will depend on the platform the program
is compiled for.
  Thus, since you are probably writing code with is not portable across
platforms, it's your code which is broken and the warning is relevant.

  Putting the camera inside a non-hollow object in povray is perfectly
legal, yet povray warns about it. Does this mean that povray is broken?
No, it means that povray warns you that you might be doing something which
has unexpected results.
  This is exactly the same case as with the 'abcd' warning. It might be legal,
but it has a certain probability of not working as you expect in a different
platform than yours.

  POV-Ray does it. Why can't gcc do it?

  I kindly asked you before to stop that insulting behaviour, but you won't
do it. That starts to be rather irritating.

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