While I was doing a long overdue disk back up for my main machine, I 
decided to try a compile of the beta 2 release on my raspberry pi 4 4GB- 
which happened to be running the more common 32bit rasbian os(1).

The configure and compile went mostly OK, except I had trouble getting a 
tiff development library installed - for reasons not related to POV-Ray 
and which I've not sorted. There are a lot of extra 'notes' from the 
compiler over the usual warnings which can probably be turned off, but I 
didn't chase these.

We get an almost immediate segfault trying to run even stuff like povray 
--help which comes from vfe/vfesession.cpp. I expect others would follow 
should one get to where we start to render anything.

---
We have four unix flavor configuration files in:

unix/povconfig/syspovconfig_bsd.h
unix/povconfig/syspovconfig_gnu.h
unix/povconfig/syspovconfig_posix.h

and

unix/povconfig/syspovconfig_osx.h

All have nearly identical set up code that I've changed - in povr - to:

//-----------
#if (0)  // Use simpler c++11 method TODO remove 0 if no issues
#if defined(_POSIX_V6_LPBIG_OFFBIG) || defined(_POSIX_V6_LP64_OFF64)
     // Below NOT true 32 raspbian os on 64bit raspberry pi 4 hardware.
     // long is at least 64 bits.
     #define POV_LONG long
#elif defined(_POSIX_V6_ILP32_OFFBIG) || defined(_POSIX_V6_ILP32_OFF32)
     // long is 32 bits.
     #define POV_LONG long long
#else
     // Unable to detect long size at compile-time, assuming less than 
64 bits.
     #define POV_LONG long long
#endif

#define POV_ULONG unsigned POV_LONG

#else   //----------------------------

// C++11 required so we can just set macros directly.
#define POV_LONG  std::int_least64_t
#define POV_ULONG std::uint_least64_t
#endif  // Use simpler c++11 method
//-------------

(1) - There is now a 64bit raspbian os mostly aimed at the newer 8GB 
models and there has been for quite a while 64bit Ubuntu versions for 
the raspberry pi 4. Not everyone with a raspberry pi will hit this 
issue, but many with a raspberry pi 4 will.

The issue can be guessed at from the code comments; It turns out that 
first test can be true and the 'long int' not be at 64 bits as the code 
comment states. The C++11 standard guarantees 'long long int' is at 
least 64bits, but 'long int' can be only 32 bits and this we get with 
the raspbian 32 bit os.

Aside: We have code since the move to c++11 taking POV_LONG and 
POV_ULONG to always be 64 bits - the bit in vfesession.cpp is just the 
first tripped upon where this not true. The code there has a hard LL 
literal assuming long long int is 64 bits.

Bill P.

Post a reply to this message

On 8/26/21 3:19 PM, William F Pokorny wrote:
> The code there has a hard LL literal assuming long long int is 64 bits.

Blast it, I meant to write:

"The code there has a hard LL literal assuming POV_LONG is 64 bits."


With C++11 'long long int' and 'unsigned long long int' are always at 
least 64 bits.

Bill P.

Post a reply to this message

On 8/27/21 5:04 AM, William F Pokorny wrote:
> On 8/26/21 3:19 PM, William F Pokorny wrote:
>> The code there has a hard LL literal assuming long long int is 64 bits.
> 
> Blast it, I meant to write:
> 
> "The code there has a hard LL literal assuming POV_LONG is 64 bits."
> 
> With C++11 'long long int' and 'unsigned long long int' are always at 
> least 64 bits.
> 

In working on documentation for my povr branch changes I noticed the 
issue here is essentially github issue #384.

"vfesession.cpp:342 overflow in conversion from long long int to
long int on m68k #384"

https://github.com/POV-Ray/povray/issues/384

I've for a month or so in those handful of configuration files simply 
had the lines:

// C++11 required. We can set following macros directly.
#define POV_LONG  std::int_least64_t
#define POV_ULONG std::uint_least64_t

over the conditional logic which was there.

This looks to be what clipka recommended in responding to #384.

Bill P.

Post a reply to this message