Re: LDAP C API: Data Types and Legacy Implementations

[Mark Smith <mcs@netscape.com>]

Hallvard B Furuseth wrote:
> 
> Mark C Smith writes (rearranged by priority):
> 
> >> We need a way to printf() and sscanf() these types.
> >> ...
> >
> > I disagree.  Why?  Presumably applications will convert between
> > ber_int_t and another type of sufficient size if they need to use
> > printf() of scanf().
> 
> I was unclear, I meant that as one way to do printf/scanf.
> 
> > Or will that approach cause problems?
> 
> The problem is that a portable program can't know what "another type of
> sufficient size" might be.  Before `long long' and C9X's `intmax_t' were
> introduced, we could use `long'.  Maybe 10 years from now, we can expect
> <inttypes.h> to exist and use `intmax_t'.  Until then, we'd need a
> configure program to test if `long long' or worse exists, and whether or
> not printf/sscanf supports it.
> 
> So, to reiterate, we need either a promise "these types are not wider
> than `long'", or macros with format characters that can printf/scanf the
> new types directly.

I agree, assuming you NEED to write code that printf's or scanf's these
types.  I don't think the ability to do so is a core requirement of the
C LDAP API, although I could probably be convinced.


> ...
> >
> > I don't think we need to add new functions to address this issue, but
> > some clarifying text might be useful.  Maybe I misunderstand what you
> > suggest, but it would strike me as very odd to interpret a ber_tag_t
> > "least significant byte first."
> 
> Odd, yes.  That and functions to avoid it are just the 'least bad
> choices' I can think of which will let us inspect or construct a
> ber_tag_t, e.g. to get at the CONSTRUCTED bit.
> 
> > In all implementations of the ber...() functions I know of, the tag
> > values are simple integers where leading zero bits are essentially
> > ignored.
> 
> If they inherit from umich ldap, they malfunction with multi-octet tags
> anyway.  Umich ldap sometimes assumes that host integers are big-endian
> and sometimes not: ber_printf doesn't write multi-octet tags read with
> ber_peek_tag correctly, for example.  Also, it sometimes assumes tags
> are single-octet, and of course that 'char' is 8-bit.
> 
> Anyway, the reason I raise this point again is mostly aesthetic, I think
> this looks worse with a nice-looking named type than with an unexplained
> 'unsigned long'.

I understand your point.  I will need to look into the issues some more
with existing implementations (starting with the Netscape/Mozilla one!) 
We should probably clarify how tags are to be expressed as ber_tag_t
values.  I vote for "the value of the tag itself."  Code that wants to
do things like grab the constructed bit will need to be smart enough to
find the right bit.  Maybe we should extend the API in the future to
provide constructors and parsers for ber_tag_t's... but since (I think)
all of the BER tags currently used in LDAP fit in one octet, this isn't
an important issue for now.


> ...
> > I amk not convinced we need to add ber_uint_t as it won't be used in any
> > of the API calls defined by the draft.  Can you provide an example that
> > shows why it is needed?
> 
> Not in the API.  It's just that unsigend versions of integer types tend
> to be useful.  (pointers to) unsigned somethings get used when the
> signed something works wrongly in shift operations, or can get overflow
> traps, or the program says things like ((unsigned something)-1)/2 to get
> the max value (unless you #define LBER_INT_<MIN/MAX>), and so on.
> Usually 'unsigned long' is fine (if the something is known to be no
> larger than 'long'), but not always.
> That's all.

Okay.  I don't see much harm in adding ber_uint_t to the spec.

-- 
Mark Smith
Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.  Got LDAP?