why apr_size_t?

["Roy T. Fielding" <fi...@apache.org>]

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?

....Roy

Re: why apr_size_t?

["Roy T. Fielding" <fi...@apache.org>]

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

Re: why apr_size_t?

[Cliff Woolley <jw...@virginia.edu>]

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.

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."

--Cliff