I built pov 3.7 rc6 on my Raspberry PI. There are a couple of issues.

Here's the blurb from configure (source was povray-3.7.0.RC6.tar.gz):

   POV-Ray 3.7.0.RC5 has been configured.

   Built-in features:
     I/O restrictions:          enabled
     X Window display:          enabled (using SDL)
     Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff
     Unsupported image formats: openexr

   Compilation settings:
     Build architecture:  armv6l-unknown-linux-gnueabi
     Built/Optimized for: armv6l-unknown-linux-gnueabi
     Compiler vendor:     gnu
     Compiler version:    g++ 4.6
     Compiler flags:      -pipe -Wno-multichar -Wno-write-strings 
-fno-enforce-eh-specs -s -O3 -ffast-math -pthread

I got the following compiler errors:

   shape/poly.cpp:188:3: warning: this decimal constant is unsigned only 
in ISO C90 [enabled by default]
   shape/poly.cpp:188:3: warning: this decimal constant is unsigned only 
in ISO C90 [enabled by default]
   shape/poly.cpp:188:3: warning: this decimal constant is unsigned only 
in ISO C90 [enabled by default]

   processoptions.cpp:1180:9: warning: case label value is less than 
minimum value for type [enabled by default]

   povms.cpp:304:3: warning: anonymous type with no linkage used to 
declare variable '<anonymous struct> POVMSStreamOrderTables' with 
linkage [enabled by default]

   renderfrontend.cpp:1165:57: warning: trigraph ??) ignored, use 
-trigraphs to enable [-Wtrigraphs]

   vfesession.cpp:594:11: warning: case label value is less than minimum 
value for type [enabled by default]

Of the above, the errors in processoptions.cpp & vfesession.cpp are 
significant. On this platform a 'char' is unsigned by default. Here's a 
test program that exhibits the same error message and shows that there 
are actual errors:

   #include <stdio.h>

   enum badT  { bAA, bBB        } bad_e;
   enum goodT { gAA, gBB, xx=-1 } good_e;

   main( int ac, char ** av )
   {
     char ch = EOF;
     signed char sch = EOF;

     printf( "ch=%d, sch=%d\n", ch, sch );

     bad_e = (badT) -1;
     good_e = (goodT) -1;
     printf( "bad_e=%d, good_e=%d\n", bad_e, good_e );

     switch( bad_e ) {
       case bAA: printf( "case bad_e == bAA\n" ); break;
       case -1:  printf( "case bad_e == -1\n" ); break;
       default:  printf( "case bad_e == ? (default)\n" ); break;
     }

     switch( good_e ) {
       case gAA: printf( "case good_e == gAA\n" ); break;
       case -1:  printf( "case good_e == -1\n" ); break;
       default:  printf( "case good_e == ? (default)\n" ); break;
     }
   }

   $ g++ t.cpp
   t.cpp: In function 'int main(int, char**)':
   t.cpp:19:11: warning: case label value is less than minimum value for 
type [enabled by default]

   $ ./a.out
   ch=255, sch=-1
   bad_e=-1, good_e=-1
   case bad_e == ? (default)
   case good_e == -1

Thus you can see that neither the 'case EOF:' at line 1180 of 
processoptions.cpp nor the 'case -1:' at line 594 of vfesession.cpp will 
match unless the patches below are applied.

Here are a couple of patches that fix those two significant errors. For 
simplefrontend.h someone who understands why the enum variable gets 
assigned a '-1' will have to rework the patch and fix the actual 
assignment rather the kludging the declaration.

--- ./source/base/processoptions.cpp.orig       2012-02-05 
14:54:15.000000000 -0600
+++ ./source/base/processoptions.cpp    2012-08-16 11:17:19.773490094 -0500
@@ -1167,7 +1167,7 @@
         str[0] = 0;
         for (int i = 0; i < 65536; i++, *pos = 0)
         {
-               char ch = file->getchar();
+               int ch = file->getchar();
                 if (hadEscape && (ch == '"' || ch == '\'' || ch == '\\'))
                 {
                         hadEscape = false;


--- ./source/frontend/simplefrontend.h.orig     2012-02-05 
14:54:18.000000000 -0600
+++ ./source/frontend/simplefrontend.h  2012-08-16 11:22:46.244738423 -0500
@@ -124,7 +124,8 @@
         kStopping,
         kStopped,
         kFailed,
-       kDone
+       kDone,
+       kminusone = -1
  };

Post a reply to this message

Le 17/08/2012 19:53, Dave nous fit lire :
> 
>   shape/poly.cpp:188:3: warning: this decimal constant is unsigned only
> in ISO C90 [enabled by default]
>   shape/poly.cpp:188:3: warning: this decimal constant is unsigned only
> in ISO C90 [enabled by default]
>   shape/poly.cpp:188:3: warning: this decimal constant is unsigned only
> in ISO C90 [enabled by default]
> 
>  
The array is declared unsigned int, prefilled with numbers up to
0x8B18014C ( 2 333 606 220 ), with two neighbours at 2 203 961 430
(0x835DC856).

Are your int 64 bits ? Because I fail to see the issue on a classical 32
bits.

Should the literal be extended with a "u" to make it happy ?
(only the 3 big ones)

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> The array is declared unsigned int, prefilled with numbers up to
> 0x8B18014C ( 2 333 606 220 ), with two neighbours at 2 203 961 430
> (0x835DC856).

In C90 those are signed long long ints, and they are being assigned to
unsigned ints, hence the warning.

Write 0x8B18014CU and 0x835DC856U to make it explicit that unsigned ints
are desired.

-- 
                                                          - Warp

Post a reply to this message

Am 17.08.2012 19:53, schrieb Dave:

>    shape/poly.cpp:188:3: warning: this decimal constant is unsigned only
> in ISO C90 [enabled by default]
>    shape/poly.cpp:188:3: warning: this decimal constant is unsigned only
> in ISO C90 [enabled by default]
>    shape/poly.cpp:188:3: warning: this decimal constant is unsigned only
> in ISO C90 [enabled by default]

Should not be a problem. Theoretically, that is. We can fix it, and we 
probably should.

>    processoptions.cpp:1180:9: warning: case label value is less than
> minimum value for type [enabled by default]

This, folks, is actually an outright error, leading to issues when the 


>    povms.cpp:304:3: warning: anonymous type with no linkage used to
> declare variable '<anonymous struct> POVMSStreamOrderTables' with
> linkage [enabled by default]

The compiler has a point there.

>    renderfrontend.cpp:1165:57: warning: trigraph ??) ignored, use
> -trigraphs to enable [-Wtrigraphs]

Trigraphs suck, but yes, we should avoid them.

>    vfesession.cpp:594:11: warning: case label value is less than minimum
> value for type [enabled by default]

That line seems somewhat bogus.

> Of the above, the errors in processoptions.cpp & vfesession.cpp are
> significant. On this platform a 'char' is unsigned by default. Here's a
> test program that exhibits the same error message and shows that there
> are actual errors:

This has nothing to do with char being unsigned by default - except that 
it helped spot the errors. But they're errors either way.


Thanks for reporting those warnings.

Post a reply to this message

Am 17.08.2012 22:08, schrieb Le_Forgeron:

> Should the literal be extended with a "u" to make it happy ?

Yes.

> (only the 3 big ones)

Why not all of them?

Post a reply to this message

On 8/17/2012 4:17 PM, clipka wrote:
>>    vfesession.cpp:594:11: warning: case label value is less than minimum
>> value for type [enabled by default]
>
> That line seems somewhat bogus.

Variable 'm_BackendState' is declared as type 'State' (vfe/vfesession.h 
line 1316). The switch statement (vfe/vfesession.cpp line 576) contains 
a 'case -1:'. Whoever wrote that code perhaps expected that 
m_BackendState could have the value '-1'. If it does, then the case will 
never be caught since '-1' is not a valid value for that enum.

Post a reply to this message

Am 17.08.2012 23:35, schrieb Dave:
> On 8/17/2012 4:17 PM, clipka wrote:
>>>    vfesession.cpp:594:11: warning: case label value is less than minimum
>>> value for type [enabled by default]
>>
>> That line seems somewhat bogus.
>
> Variable 'm_BackendState' is declared as type 'State' (vfe/vfesession.h
> line 1316). The switch statement (vfe/vfesession.cpp line 576) contains
> a 'case -1:'. Whoever wrote that code perhaps expected that
> m_BackendState could have the value '-1'. If it does, then the case will
> never be caught since '-1' is not a valid value for that enum.

Yes, that's what I'm thinking. Have done some quick code digging to see 
if it is ever set to -1 somewhere, but it turns out to be more than a 
5-minute job.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 17.08.2012 19:53, schrieb Dave:
> >    renderfrontend.cpp:1165:57: warning: trigraph ??) ignored, use
> > -trigraphs to enable [-Wtrigraphs]
>
> Trigraphs suck, but yes, we should avoid them.

Hard to believe there was a time when not all English-based computers understood
7-bit ASCII.

Post a reply to this message

Am 18.08.2012 00:39, schrieb Cousin Ricky:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 17.08.2012 19:53, schrieb Dave:
>>>     renderfrontend.cpp:1165:57: warning: trigraph ??) ignored, use
>>> -trigraphs to enable [-Wtrigraphs]
>>
>> Trigraphs suck, but yes, we should avoid them.
>
> Hard to believe there was a time when not all English-based computers understood
> 7-bit ASCII.

Well, the trigraphs were there for /non/ English-based computers, which 
often used 7-bit national derivatives of ASCII. Those typically replaced 
a common set of 8 characters - curly braces, square brackets, pipe 
symbol, backslash, tilde and hash - with language-specific characters 
(in the German "GSCII", for instance, those were the umlauts, the sz 
ligature, and the German paragraph sign), so C programs without 
trigraphs would look pretty odd on those computers.

BTW, the UK also had their own derivative of ASCII, replacing the hash 
sign with a pound sterling sign, but AFAIR the other characters were 
left unharmed.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> (in the German "GSCII", for instance, those were the umlauts, the sz
> ligature, and the German paragraph sign),

Why does a German acronym begin with the letter 'G'?

Post a reply to this message