[Radiance-general] Bug in replmarks

[Georg Mischler]

Hi all,

one of my customers has just tripped over a bug that is present
in all Radiance versions I have looked at so far, but only has
any consequences on Windows. I haven't had the time to look at
3.4 yet, but it's quite likely to around there too.

The function replace() in replmarks.c allocates a string buffer
on the stack, but doesn't worry about its contents any further
at this point. The assumption seems to be that the function
buildxf() will do so, which it does most of the time. The problem
is, that for octree instances that are not scaled, and are exactly
aligned with the parent coordinate system, this is not the case.
In this situation, strlen() is applied to the *unaltered* string,
and the remaining transformation arguments are written *after*
anything that is already present there.

As a result, the output data will almost always contain
arbitrary and usually binary characters. On unix, this doesn't
seem to be a problem very often, as the parser appears to simply
ignore binary data in scene files. The Windows version correctly
reports 'bad arguments for instance "xxxx"'.

Fortunately, the fix is simple. At the beginning of the replace()
function in replmarks.c, include the following line:

	buf[0] = '\0'; /* make sure we don't include any garbage */

This garantees that the string in the buffer has a length of
zero to begin with, and avoids all further confusion.


Have fun!

-schorsch

-- 
Georg Mischler  --  simulations developer  --  schorsch at schorsch.com
+schorsch.com+  --  lighting design tools  --  http://www.schorsch.com/