In fact, it makes no sense that ber_ptr < ber_buf; if it happens, the BerElement is corrupted, and an assertion failure may be more appropriate. Right now, no test is done, and the (trivial) function could be replaced with a macro... Since this is part of the private API, its change should be harmless. Also, it should be renamed ber_int_ptrlen().
p.
masarati@aero.polimi.it writes:
In fact, it makes no sense that ber_ptr < ber_buf; if it happens, the BerElement is corrupted, and an assertion failure may be more appropriate. Right now, no test is done, and the (trivial) function could be replaced with a macro... Since this is part of the private API, its change should be harmless. Also, it should be renamed ber_int_ptrlen().
Leave this for RE25 or later. Many of the ber functions could use such a change. Changing just one which happens not to be exported makes little difference. See the comments I added in encode.c, for example.
Also, remember that we often subtract pointers, so possibly we should make max(ber_slen_t) the supported maximum instead of max(ber_len_t).
masarati@aero.polimi.it writes:
In fact, it makes no sense that ber_ptr < ber_buf; if it happens, the BerElement is corrupted, and an assertion failure may be more appropriate. Right now, no test is done, and the (trivial) function could be replaced with a macro... Since this is part of the private API, its change should be harmless. Also, it should be renamed ber_int_ptrlen().
The macro exists: ber_pvt_ber_write() in libraries/liblber/lber-int.h.
I'll be introducing a new function ber_tag_t ber_skip_element(BerElement *ber, struct berval *contents); or something like that, you might find that useful instead. Will point *contents into the BerElement, with no alloc or \0-termination.
-
Hallvard B Furuseth -
masaratiļ¼ aero.polimi.it