On Fri, 2005-05-27 at 09:29, Vance Shipley wrote:
> On Fri, May 27, 2005 at 09:13:13AM +0100, Dave Shield wrote:
> }
> } Are you *really* that tight on space that a few extra bytes is
> } going to make a difference?
>
> The point is that to "handle an error" I need to understand what
> happene
On Thu, 2005-05-26 at 22:51, Vance Shipley wrote:
> On Thu, May 26, 2005 at 09:00:08AM +0100, Dave Shield wrote:
> }
> } (but don't forget to check for null pointers first!)
>
> Speaking of which ...
>
> With the table_data helper can I asume that when my handler
> is called for a GET request
On Fri, 2005-05-27 at 03:00, Vance Shipley wrote:
> } So if the table was indexed by a single integer value,
> } you could retrieve this using
> }
> } long intIndex = *ti->indexes->val.integer;
> }
> } (but don't forget to check for null pointers first!)
> If the request made it into
On Thu, May 26, 2005 at 09:00:08AM +0100, Dave Shield wrote:
}
} netsnmp_table_request_info *ti =
} netsnmp_extract_table_info( request );
}
} The field 'ti->indexes' holds a varbind list containing
} the index values from the incoming request.
}
} So if the table was indexed
On Thu, May 26, 2005 at 09:00:08AM +0100, Dave Shield wrote:
}
} (but don't forget to check for null pointers first!)
Speaking of which ...
With the table_data helper can I asume that when my handler
is called for a GET request that it has validated the index?
Is the following test unnecessa
On Thu, 2005-05-26 at 00:25, Vance Shipley wrote:
> When a SET
> arrives for an existing row I can extract my row data using:
>
> netsnmp_extract_table_row_data(request);
>
> I take it though that this will return NULL when the row doesn't
>
I'm implementing an agent using the table_data helper. One area
where I have yet to see the light is in row creation. When a SET
arrives for an existing row I can extract my row data using:
netsnmp_extract_table_row_data(request);
I take it though that this will return NULL when the r
