All Projects

A scene of a hollow sphere viewed from the inside:

difference {
    sphere { 0, 100 }
    sphere { 0, 99 }
    pigment { rgb 1 }
    finish { ambient .4 }
}

global_settings {
    radiosity {
        error_bound .1
    }
}

Rendering produces dark splotches at the centers of the pretrace blocks, as shown in the attached image. Blocks rendered earlier have darker splotches. They also differ in shape between renders even with +HR (but not with +WT1).

Turning “always_sample” on, changing “pretrace_end” to 0.01, or increasing “count” past 1000 makes them imperceptibly faint (they can still be seen by increasing image contrast).

This is possibly a bug, as 3.6 doesn’t produce these artifacts regardless of additional settings.

povray.beta-test thread

#macro A()
    #local f = function { x }
#end

#local f = 1;
A()

This gives:

File 'bug.pov' line 2: Parse Error: Attempted to redefine float identifier as
 function identifier.

The problem is that this makes using functions in library macros difficult. Basically, they must have a globally unique name that’s not used in any of the macros or files that call the macros. #undef doesn’t really help, because it destroys the identifier in the calling scope.

For example, one of the macros in the standard include files names a function “fn”, so this doesn’t work:

#include "transforms.inc"

#local fn = 42; // fnord?
#local fn_pos = vtransform(x, transform { rotate 30*y } );

The reason for this restriction is explained in Parse_RValue in source/backend/parser/parse.cpp:

    // Do NOT allow to redefine functions! [trf]
    //   #declare foo = function(x) { x }
    //   #declare foo = function(x) { foo(x) } // Error!
    // Reason: Code like this would be unreadable but possible. Is it
    // a recursive function or not? - It is not recursive because the
    // foo in the second line refers to the first function, which is
    // not logical. Further, recursion is not supported in POV-Ray 3.5
    // anyway. However, allowing such code now would cause problems
    // implementing recursive functions after POV-Ray 3.5!

In this case the restriction is applied too broadly: it should be safe to redefine anything other than a function to a function and still avoid it looking like recursion. In fact, there’s a restriction in Parse_Declare specifically to prevent redefining functions.

#macro A()
  #local foo = function { x }
  foo
#end

#local bar = A();

This causes either a segfault, corruption detected by malloc, or “Parse Error: Unknown user defined function”.

After some debugging I think this is what happens.

In source/backend/parser/parse.cpp, Parser::Parse_RValue is called to define the value of bar. Get_Token is called, which invokes A() and which ultimately returns foo as a FUNCT_ID_TOKEN. This token is handled by CASE_VECTOR in Parse_RValue. The relevant clause calls Parse_Unknown_Vector to parse additional tokens (e.g. “foo ( 1 )”). There aren’t any other tokens, but in the process of determining that, #end is reached and Return_From_Macro destroys the symbol table of A, including foo.

So by the time the CASE_VECTOR clause decides that foo is a function identifier that should be copied, the function is destroyed (both the function itself and its number in the symbol table). So here:

    Temp_Data  = (void *) Copy_Identifier((void *)*Token.DataPtr,*Token.NumberPtr);

if *Token.DataPtr (in this case, a function index) was already overwritten, we get “Unknown user defined function”; if it still has the valid function number, it increments the reference count of the function (which has already been freed) back from 0, and we get a double-free later.

A similar problem occurs when foo is a spline.

A tentative patch for the function case is attached.

In vfe/unix/unixoptions.cpp, -V is defined as a synonym for -​-version, overriding its general meaning of Verbose=off.