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 <gstein@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/
Received on Sat Oct 21 14:36:14 2006