On Friday, July 12, 2002, at 08:12 AM, Cliff Woolley wrote:
On Thu, 11 Jul 2002, Roy T. Fielding wrote:

As near as I can tell from looking at the code and cvs logs, the only
reason we have apr_size_t and apr_ssize_t is because win32 wants to
define apr_ssize_t.  Is that because win32 doesn't have ssize_t?
Is there a reason why we don't simply define ssize_t on that platform?

We've run into problems before doing things like this, well I suppose more with functions than with typenames. But in general, if we're going to export something, IMO it must always be apr_ namespaced.

Hmm, but we wouldn't be exporting something in this case, unless you mean all interface types should be encapsulated. I only believe that should be true if they are truly abstract data types.

For example, there was a case recently where if strchr() or something was
missing, we would just define it.  But that would break binary
compatibility with later patchlevels of the same OS that suddenly *did*
define it, as we'd get duplicate definitions.

Obviously the binary-compatibility argument doesn't hold for typenames,
but I still think it wise to have everything consistently namespaced.  It
makes it easier for the programmer too -- if you're using APR, then all
your types start with "apr_".  It would be annoying to have to remember
"oh, APR gives me this one, but there's no apr_ on it.  APR gives me this
other one but there *is* an apr_ on that."

Is that really easier? The reason I asked is that there are dozens of reusable code libraries out there that use POSIX types specifically to avoid making every variable in the client code library-specific. That makes it easier when you perform a series of actions across multiple libraries. I'd think that this would be a regular occurrence once folks figure out how to create content filters.

Hmm, I guess the real issue would be if other libraries, having figured
out that ssize_t is not defined, go ahead and define it themselves for
that platform.  If the client combined the header files from both
that library and APR, then they would get conflicts.  *shrug*

I guess that's reasonable.  However, we should document the rationale,
because defining a type without conversion functions means that people
have to do a cast from apr_ssize_t to ssize_t in their own code.

....Roy



Reply via email to