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

> Thorsten Froehlich <tho### [at] trfde> wrote:
>> ignoring the rest of your post.
>   A lesson in politeness?

it's quite sad to see flame-war beetween, as I see, good programers ;)

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> it's quite sad to see flame-war beetween, as I see, good programers ;)

  Differing opinions is one source of progress, I think.
  If everyone would think in the exact same way, then there would be
a lot less room for innovation.

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

On Mon, 23 Sep 2002 10:51:19 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:

>In article <28gtou4t56f843790s28f5r236q80k3boi@4ax.com> , ABX 
><abx### [at] abxartpl>  wrote:
>
> > warnings when -Wall setting is used with gcc
>
> Using all gcc warning is pointless.

But somehow I did it :-)
I have now warning-free version of sources. And now I can say what I changed -
warnings were mostly generated with additions/changes introduced in 3.5. Old
code from 3.1 and earlier versions did not cause warnings usually. I can say
nothing about (x)windows compilation. I did it only with pure dos/unix
compile.

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

It is array of structures with one element - array. It have to be "double
bracketed" (is this english correct ?). So instead of:
  { ".jpg",  ".JPG",  ".jpeg", ".JPEG" },
it should be:
  { { ".jpg",  ".JPG",  ".jpeg", ".JPEG" } },

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

It helped to add definition:

#define FOURCHARS_TO_INT(c1,c2,c3,c4) \
                    (((unsigned long) c1 << 24) | \
                     ((unsigned long) c2 << 16) | \
                     ((unsigned long) c3 << 8 ) | \
                     ((unsigned long) c4      ))

I have additional question. Is this more correct or still valid if I replace
line 1756:
  fprintf(file, "%.8x%.8x\n", h, l);
with line:
  fprintf(file, "%.8lx%.8lx\n", h, l);
?

ABX

Post a reply to this message

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

> It helped to add definition:
>
> #define FOURCHARS_TO_INT(c1,c2,c3,c4) \
>                     (((unsigned long) c1 << 24) | \
>                      ((unsigned long) c2 << 16) | \
>                      ((unsigned long) c3 << 8 ) | \
>                      ((unsigned long) c4      ))

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, but potentially *breaking* the code on compilers which handle
multibyte character constants correctly!!!

The correct solution is to simply turn off the particular warning.

    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 11:44:39 +0200, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> but potentially *breaking* the code on compilers which handle
> multibyte character constants correctly!!!

how ?

ABX

Post a reply to this message

On Mon, 30 Sep 2002 08:58:48 +0200, ABX <abx### [at] abxartpl> wrote:
> I have additional question. Is this more correct or still valid if I replace
> line 1756:
>   fprintf(file, "%.8x%.8x\n", h, l);
> with line:
>   fprintf(file, "%.8lx%.8lx\n", h, l);
> ?

I mean in povms.cpp :-)

ABX

Post a reply to this message

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

>> line 1756:
>>   fprintf(file, "%.8x%.8x\n", h, l);
>> with line:
>>   fprintf(file, "%.8lx%.8lx\n", h, l);
>> ?
>
> I mean in povms.cpp :-)

Line numbers don't help me much (they change...).  I need the function name
:-)


    Thorstem


____________________________________________________
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: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