[Openexr-user] CTL bug/implementation issue

[gga]

CTL constant variables seem to not be namespace/context/file safe.
Attempting to load two files with similarly named static const variab=
les
will result in an exception, like:

Name rec709 has already been defined in current scope. (@error28)
terminate called after throwing an instance of 'Ctl::LoadModuleExc'

This problem can be reproduced easily by trying to load, for example,
both the sample transform_DPX_EXR.ctl and the transform_RRT.ctl files=
.
Both contain their own (identical) rec709 static variable implementat=
ion.

It is unclear from the ctl docs how this is to be worked around.

--=20
Gonzalo Garramu=F1o
***@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

[Florian Kainz]

Hi Gonzalo,

in CTL you fix duplicate names the same way as in C:
either make the variable names unique, for example, by
using a prefix, or, if you want a variable that is shared
by two transforms, move the variable into a separate CTL
module that is then imported by both transforms.

We may at some point add support for unnamed namespaces.

The duplicate variable in transform_DPX_EXR.ctl and
transform_RRT.ctl is an oversight and should be fixed.

Florian

Post by gga
CTL constant variables seem to not be namespace/context/file safe.
Attempting to load two files with similarly named static const variables
terminate called after throwing an instance of 'Ctl::LoadModuleExc'
This problem can be reproduced easily by trying to load, for example,
both the sample transform_DPX_EXR.ctl and the transform_RRT.ctl files.
Both contain their own (identical) rec709 static variable implementation.
It is unclear from the ctl docs how this is to be worked around.

[gga]

Post by Florian Kainz
Hi Gonzalo,
=20
either make the variable names unique, for example, by
using a prefix, or, if you want a variable that is shared
by two transforms, move the variable into a separate CTL
module that is then imported by both transforms.
=20
We may at some point add support for unnamed namespaces.
=20
The duplicate variable in transform_DPX_EXR.ctl and
transform_RRT.ctl is an oversight and should be fixed.
=20

Sounds reasonable.

Currently the main headache is that this prevents a totally valid mod=
ule
=66rom loading otherwise (and the error is quite cryptic to the user,=
too).
As ctl files are to be used mostly as runtime code unlike C, it might=
be
better to follow the queue from scripting languages and just output a
warning keeping either the original or new value.
If the duplicated constant variable is then misused only *then* raise=
an
exception.

For example, taking a queue from ruby which is a scripting language w=
ith
(pseudo) constants:

$ irb
irb> A =3D 20
=3D> 20
irb> A =3D "hello"
(irb):2: warning: already initialized constant A
=3D> "hello"

but the code loads and keeps working (unless A is later misused due t=
o,
for example, a change in type like the example above):

irb> A + 50
TypeError: can't convert Fixnum into String


On another note:

I haven't looked too deep into the CTL implementation yet, but...
Is there currently any way to output bytecodes or, better yet, encode
the ctl code? One of the original discussions on this list mentioned
that as a potential feature, so that, say, if ILM wanted to share dat=
a
with me, I would be able to use their ctl files, but, at the same tim=
e,
ILM could keep their proprietary color transforms secret (at least
without me doing some serious reverse engineering).


--=20
Gonzalo Garramu=F1o
***@advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Kubuntu Edgy

[Florian Kainz]

Post by gga
I haven't looked too deep into the CTL implementation yet, but...
Is there currently any way to output bytecodes or, better yet, encode
the ctl code? One of the original discussions on this list mentioned
that as a potential feature, so that, say, if ILM wanted to share data
with me, I would be able to use their ctl files, but, at the same time,
ILM could keep their proprietary color transforms secret (at least
without me doing some serious reverse engineering).

Reverse engineering of usable high-level code from the bytecodes
would be fairly easy, especially given that the CTL interpreter
is open source. You would have to write a reverse translator only
once; after that you could apply it to any number of transforms.
Supporting an unreadable execute-only representation in order to
protect trade secrets doesn't seem worth the effort; subverting
the protection would be all too easy.

If you want to protect your math, you may want to explicitly build
a lookup table and stick that into your .ctl program.