On 02/07/13 11:37, Arran Cudbard-Bell wrote:
On 2 Jul 2013, at 08:53, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 07/02/2013 07:52 AM, Arran Cudbard-Bell wrote:
This may work for 2.x.x but definitely wont't work for 3.0 which uses direct DICT_ATTR pointer comparisons in some places (instead of comparing vendor/attribute number).
So... what *can* you do with Vendor-X-Attr-Y?
Use it to figure out which dictionary entries you're missing.
I was hoping for something more specific than that ;o) So you can't compare them; can you set them: update reply { Vendor-X-Attr-Y = 0xff } ? Can you xlat them? update request { Tmp-String-0 = "%{Vendor-X-Attr-Y}" } ? Or are they basically display-only i.e. debug output and detail file?
We can't modify the dictionaries dynamically after startup without locking the tree (on every read/write), else we could of added unknown attributes as octet type attributes.
The compromise is to dynamically allocate fake DICT_ATTR entries for attributes which couldn't be resolved in the dictionaries, or that have values which don't match their data type (64bit value in integer type for example).
As these DICT_ATTRs are dynamically allocated and unique to each request, comparing the pointers doesn't result in a match.
Ah.