[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: timeval in ldapext-ldap-c-api-01
If you are worried about namespace collision, why not define your own
timeval structure with a slightly different name like
typedef struct l_timeval {
LONG tv_sec;
LONG tv_usec;
} LDAP_TIMEVAL, * PLDAP_TIMEVAL;
int ldap_result(
LDAP *ld,
int msgid,
int all,
struct l_timeval *timeout,
LDAPMessage **res
);
-Anoop
> -----Original Message-----
> From: Kurt D. Zeilenga [SMTP:Kurt@OpenLDAP.Org]
> Sent: Friday, November 13, 1998 10:12 AM
> To: ietf-ldapext@netscape.com
> Subject: timeval in ldapext-ldap-c-api-01
>
> I believe the use of struct timeval should be clarified.
> As the spec currently reads, it appears as it should be
> defined within the header(s) like the other non-opaque
> structures within the namespace.
>
> I believe the spec should state the this structure
> must be externally defined by the application developer
> by either including the appropriate system header or
> defining it herself.
>
> One could argue that the implementation should define
> it (or cause it to be defined). But...
>
> If timeval does exist within the system headers,
> the application must include the appropriate header.
> If the implementation includes the header, the
> namespace will be poluted with a wide range
> of symbols and likely result in clashes. It
> should also be noted that <sys/time.h> (where
> timeval is normally defined) and <time.h> cannot
> both be safely included on older platforms.
>
> If timeval doesn't exist within any system headers,
> the implementation is forced to declare it. But
> a developer may be using a third party library
> that also depends on timeval. The third party
> package defines it, the implementation defines it,
> the application fails to compile.
>
> Because some implementations can not safely declare
> struct timeval, all implementions SHOULD NOT.
>
> Kurt