Dts12 at 11:31, 23 October 2006

2006-10-23T11:31:04Z

New page

This is a problem (at least apparently) with the v4 UCD module
API, which uses a ''"magic number"'' to distinguish between the various
column objects implemented by a common variable handling routine.
Since this field is defined as an unsigned character, it can only
take values 0-255. So at first sight, it would appear that the
agent cannot support tables (or scalar groups) with more than 256
objects, since this would start to duplicate these magic numbers.

However, the agent doesn't actually care which routine implements
a given object, and magic numbers only need to be unique within a
single variable handling routine. So it is actually perfectly
possible to implement a larger table by splitting it between two
(or more) variable handling routines. These can then re-use the
magic numbers quite safely:

struct variable1 [] = {
{MAGIC1, ASN_INTEGER, RWRITE, var_myfirst, 1, { 1}},
{MAGIC2, ASN_INTEGER, RWRITE, var_myfirst, 1, { 2}},
:
{MAGIC255, ASN_INTEGER, RWRITE, var_myfirst, 1, {255}},
{MAGIC1, ASN_INTEGER, RWRITE, var_mysecond, 1, {256}},
{MAGIC2, ASN_INTEGER, RWRITE, var_mysecond, 1, {257}},
:
{MAGIC255, ASN_INTEGER, RWRITE, var_mysecond, 1, {510}}
};

All that matters is that a given magic number isn't re-used within
the same variable handling routine. The v5 table handlers typically
use an integer variable for holding column information, so aren't
subject to the same limitations.

Though I'd have to question whether having such a wide table is
necessarily a particularly good design strategy!

Template:FAQ:Coding 17 - Revision history

Dts12 at 11:31, 23 October 2006