On Mon, 30 Sep 2002 13:11:20 +0200, "Thorsten Froehlich" <tho### [at] trfde>
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.

ABX

Post a reply to this message

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

>> but potentially *breaking* the code on compilers which handle
>> multibyte character constants correctly!!!
>
> how ?

If you mix a programmer defined implementation with an implementation
defined implementation.  The following, while perfectly legal code may
break:

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

    if(prog == 'ABCD')
        puts("equal");
    else
        puts("not equal");

This is perfectly legal and will not break:

     unsigned long prog = 'ABCD';

    if(prog == 'ABCD')
        puts("equal");
    else
        puts("not equal");

Essentially the problem is that what you do actually creates a problem if
the implementation defined implementation differs from the programmer
defined implementation of multicharacter constants.  This may very well
happen depending i.e. on byteorder, but also on many other things.

Multicharacter constants are great if used consistently, but not if one
messes around with them like your macro does.  Some compilers think they
have to always warn you because you _might_ use it incorrectly.

POV-Ray uses it correctly and will work as it should because it never makes
any assumption like the actual representation of the multicharacter
constants, which your macro does.  It only compares multicharacter constants
with other multicharacter constants, which works without any limitations
whatsoever and is perfectly legal and clean code.  Except some compilers
with broken default warning settings warn about it, 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

On Mon, 30 Sep 2002 13:23:17 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> If you mix a programmer defined implementation with an implementation
> defined implementation.

I think I see the difference better now. I still wonder it is correct to use
implementation dependand features. Would you like to unroll some statement
about it ? I understnad it is necessary to make some assumptions about
compiler but gcc is very portable nowadays and povray I think is supposed to
be "gcc-compatible". For example I considered recently to buy some
palm/handheld with port of gcc to play with povray sources on the village
where I have no computer and waste time at evenings. But there is a risk I
could not use it becouse some modern assumptions were done to the sources. I
decided to buy old used Pentium 75 MHz for such portable compilation machine.
But I still affraid that future development would get me off becouse of
requiements. Right now Pentium 75 is enough for DJGPP with GCC 3.1 and some
MP3 in background. That's just fears, not criticism.

ABX

Post a reply to this message

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