[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