Re: (c.harding 22644) Re: (c.harding 22613) int vs long in ldapext-ldap-c-api-01

["Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>]

Chris Harding wrote: 
> >As such, the C API should only require types/structures/defines that are
> >available in LCD C (Least Common Denominator C).  Requiring a type which
> >is widely available would not be wise.
> >
> Implementations that don't support the new ISO C (which after all isn't
> a standard yet) can always define the types by typedef.

Not without changing the namespace consumed by the API.

Many developers have multiple C translators available to them on a
single
platform.  In fact, most C translators support multiple translation
environments (POSIX, ANSI, SYSV, WIN32, BSD).  These
translations/environments
are dramatically different from one another.  A given synonym type
defined
type may not be available in all environments.  How is a is
implementation
that allows application developers to choose between available
environments
to reliability determine at compile time whether the synonym type is
available
or not?  (to determine it's safe to define it's own synonym).

> >In addition, I feel that implementation provided headers should be:
> >       1) idempotent
> >               You can include the same header more than once.
> >               The effect is as if you included it once.
> Agreed.
> 
> >       2) mutually independent
> >               No header requires that another header (including
> >               system headers) be included for it to work properly.
> >               Nor does the header include (or cause to be included)
> >               any system header or other header defined by the API.
> Agreed that this is desirable - but it may not always be possible.

The current specification does not require rely on any pre-declaration
of any types/structures/macros.  That is, the program:
	#include <ldap.h>
	int main() { return 0; }

should, but is not required to, compile without error.  I believe
this should become required.

> >       3) equivalent to file level declarations
> >               ldap headers must be included before the application
> >               refers to anything that the header defines or declares.
> You can even go further and require the application to define feature-
> test macros, as in POSIX.
> 
> >       4) well documented
> >               The draft need to state which headers are required
> >               by the implementation and details about their content.
> >
> Absolutely agreed!
> 
> >(the above was derived from Standard C library header requirements)
> >
> >The motivation behind these suggestion is to allow implementations
> >that are C translator neutral and to allow application developers
> >to use the available features of these C translators.
> >
> I don't agree completely with this, although making things independant
> of things that they don't need to depend on always sounds a good idea.

I don't want to outlaw implementations that currently support
traditional C, "common usage" C, Standard C, C++ or any other
language binding that can be described in terms of Standard C.

> If this principle had always been followed then the innovations
> introduced by the present ISO C standard - in particular function
> prototypes and the const modifier, would never be used. This would
> be a pity, as they are useful in interface definitions.

The API should use prototypes and const modifiers to DESCRIBE the
interface...  BUT implementors should be allowed to provide, at
their discretion, implementations that are compatible with other
languages (K&R C, latest ISO draft, Objective C, C++).

Kurt