[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Last call comments with LDAP C API #4



Isn't this a rather peculiar definition for a client-side control?

"The ldctl_value.bv_lenfield MUST always be set to 4.  The
ldctl_value.bv_val field MUST point
to a 4-octet integer flags value."

Wouldn't it be more reasonable to define it in implementation-specific terms
such as impl_uint_t?  For example, "The ldctl_value.bv_lenfield MUST always
be set to sizeof(impl_uint_t).  The ldctl_value.bv_val field MUST point to a
impl_uint_t flags value."
This would allow the field to be used naturally by both clients and the api,
without needing to do anything special to ensure use of a 4-octet value.

Tom Salter

 > -----Original Message-----
 > From: Mark Wahl [mailto:M.Wahl@INNOSOFT.COM]
 > Sent: Friday, November 12, 1999 8:48 PM
 > To: mcs@netscape.com
 > Cc: Mark Wahl; timhowes@yahoo.com; andyhe@MICROSOFT.com;
 > anoopa@MICROSOFT.com; kurt@openldap.org; ietf-ldapext@netscape.com
 > Subject: Last call comments with LDAP C API #4
 > 
 > 
 > 
 > Mark, here are some comments I received, primarily from our 
 > engineers, 
 > on the C API.  If they look reasonable to you, I would 
 > consider that most of 
 > them could be treated as last call clarification requests.   
 > Let me know if
 > you have any issues with them.
 > 
 > 
 > 1) In 11.3.1 it says "The ldctl_value.bv_val field MUST 
 > point to a 4-octet 
 > integer flags value."
 > 
 > This is not 'integer' in the sense of a C int (since a C int 
 > may not be 4 
 > bytes), nor is it an ASN.1 INTEGER which is variable length. 
 >  This sentence
 > therefore needs to specify the encoding of an integer value 
 > in 4 octets.  In 
 > particular, the endian of this value needs to be specified.  
 > Host byte order 
 > or network byte order?  
 > 
 > I (--mfw--) assume host, so "The ldctl_value.bv_val field 
 > MUST point to a 4 
 > byte area containing the flags integer value in host byte order."
 > 
[...]
 > Mark Wahl, Directory Product Architect
 > Innosoft International, Inc.
 >