more apr_size_t (was: Re: CVS update: ...)

[Greg Stein <gs...@lyra.org>]

On Thu, Nov 09, 2000 at 05:37:18PM -0500, Greg Hudson wrote:
>...
> We have N-th hand evidence that people noticed this.  And I don't
> particularly believe it;

I don't particularly believe it either :-), but it is a small cost for the
potential benefit... [below]

> maybe someone didn't realize that you have to
> include one of a couple specific header files to get size_t, or
> concluded that it was defined incorrectly when it wasn't.  That kind
> of faulty conclusion is made all the time.  On the other hand, a
> missing or mis-defined size_t would almost certainly be noticed before
> release on any system claiming to be ANSI C; all sorts of code uses
> size_t, and has for a long time.

We don't release SVN for particular systems. There is no way that we can
test every possible system or combination. Instead, what will happen is that
some yin-yang out in Podunk, USA is going to compile the thing on his A/UX
box and find that it breaks because of a missing size_t. Then we have to
deal with the bug reports, resolve the proper fix, reintegrate that into
SVN, and make a new release.

Sorry, I'll take apr_size_t today and just not worry about the problem.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: more apr_size_t (was: Re: CVS update: ...)

[Karl Fogel <kf...@galois.collab.net>]

I think I've timed out on this issue -- use whichever one you like,
when you have a choice; and if you see me using one or the other
inconsistently, feel free to change it. :-)

It's pretty clearly never going to cause an actual portability problem
either way.

-K

Greg Stein <gs...@lyra.org> writes:
> On Thu, Nov 09, 2000 at 05:37:18PM -0500, Greg Hudson wrote:
> >...
> > We have N-th hand evidence that people noticed this.  And I don't
> > particularly believe it;
> 
> I don't particularly believe it either :-), but it is a small cost for the
> potential benefit... [below]
> 
> > maybe someone didn't realize that you have to
> > include one of a couple specific header files to get size_t, or
> > concluded that it was defined incorrectly when it wasn't.  That kind
> > of faulty conclusion is made all the time.  On the other hand, a
> > missing or mis-defined size_t would almost certainly be noticed before
> > release on any system claiming to be ANSI C; all sorts of code uses
> > size_t, and has for a long time.
> 
> We don't release SVN for particular systems. There is no way that we can
> test every possible system or combination. Instead, what will happen is that
> some yin-yang out in Podunk, USA is going to compile the thing on his A/UX
> box and find that it breaks because of a missing size_t. Then we have to
> deal with the bug reports, resolve the proper fix, reintegrate that into
> SVN, and make a new release.
> 
> Sorry, I'll take apr_size_t today and just not worry about the problem.
> 
> Cheers,
> -g
> 
> -- 
> Greg Stein, http://www.lyra.org/