Hi!

Marco> Hi ! I'm studying the error messages returned by the library Marco> and I've some = problems with the following one:

Marco> index element `%s::%s' of row `%s' should but cannot have a Marco> size restriction

Marco> Could someone explain me what does it means and when this error Marco> messages is shown ?

Juergen> OIDs in SNMP are restriced to 128 subidentifier maximum. If Juergen> you index a table by an OID, you will run over the 128 Juergen> subidentifier limit. So the index should have a size Juergen> restriction but the SMI does not allow you to define such a Juergen> size restriction for OIDs.

Juergen> [This seems to be a frequently asked question. Frank, do you Juergen> have time to start a file where we just collect these Juergen> things?]

There is already an explaining desciption in error.c, but just for the case the error message that is shown in case of a local definition. I think, we should just update these texts in error.c instead of starting a new kind of TODO file.

{ 5, ERR_INDEX_OID_NO_SIZE, "index-element-no-size", "index element `%s' of row `%s' should but cannot have a size restriction", "Object identifiers are restricted in size to have at most 128\n" "sub-identifiers. This implies that all index elements used to form\n" "instance identifiers should have a size contraint which ensures\n" "that the 128 sub-identifier constraint is kept intact for any\n" "possible combination of the index elements' values (RFC 2578,\n" "Section 3.5). However the type OBJECT IDENTIFIER cannot formally\n" "be restricted in size (Section 9) although it is legal to use\n" "objects type OBJECT IDENTIFIER as index elements."}, { 5, ERR_INDEX_OID_NO_SIZE_MOD, "index-element-no-size", "index element `%s::%s' of row `%s' should but cannot have a size restriction", NULL},

-frank

Bill Fenner wrote:

Wow. I have

http://www.icir.org/fenner/mibs/libsmi-errors/

which attempts to be similar expansions of the error names, but I haven't updated it in a while and didn't notice the expanded error.c .

There is just the infrastructure and very few error types with such detailed descriptions. I think your list of descriptions is very nice to help update the list in error.c. Would that be ok for you (I guess so, but I should have asked)?

Bill Fenner wrote:

I'm happy for you to copy my work into errors.c . Behind the scenes I have it seperated into two pieces -- a reference, e.g. "RFC2578 section 7.1.12", and a quote, e.g. [...] I'd love to be able to generate my pages from errors.c, but I'd like to keep the emphasis. Perhaps the string in the file could have some sequence like // to replace the emphasis.

Ah, I did not recognize that it's a quote from the specs. :-) I expect that there are some cases where it is more complicated, e.g. when a rule is violated that is based on ASN.1.

What I have in mind is a short paragraph for each error, that (a) describes the reason precisely (a quote might be reasonable in many cases), and (b) gives a reference to the specs where possible.