You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2000/11/05 22:35:33 UTC
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
brane@tigris.org wrote:
> Log:
> * libsvn_subr/hashdump.c (read_length_line): Change `i' to `size_t' to
> match parameter and silence MSVC warning.
By the way, shouldn't that parameter be `apr_size_t'?
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 06, 2000 at 04:45:03PM -0800, Matthew Braithwaite wrote:
> On Mon, Nov 06, 2000 at 04:41:31PM -0800, Greg Stein wrote:
> >
> > apr_size_t exists in case some whacko platform doesn't have a size_t in its
> > header files. Dunno any, but the need was discovered by Apache (at some
> > point in the past) and it just flowed into APR.
> >
> > My guess is that it isn't really needed any more.
>
> Ye gods. size_t is defined by ANSI C. Can't one count on *anything*? :-)
hehe... Python was K&R compliant until just a few months ago (we then
revamped the whole source tree to use prototypes and ANSI-style func defn).
For maximum portability, you have to be wary for tweakiness in the header
files. Sick, yes, but thankfully it isn't much of an imposition.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Branko Čibej <br...@xbc.nu>.
Matthew Braithwaite wrote:
> Ye gods. size_t is defined by ANSI C. Can't one count on *anything*? :-)
? Hey, this is *C* we're talking about, and *ix. :-)
(Sometimes, after I've spent hours trying to get some "portable" code to
work on three different "Posix-compliant", major-brand Unices, I like to
pronounce that wildcard literally -- "Splatix". Does wonders for my
state of mind ...)
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Matthew Braithwaite <ma...@braithwaite.net>.
On Mon, Nov 06, 2000 at 04:41:31PM -0800, Greg Stein wrote:
>
> apr_size_t exists in case some whacko platform doesn't have a size_t in its
> header files. Dunno any, but the need was discovered by Apache (at some
> point in the past) and it just flowed into APR.
>
> My guess is that it isn't really needed any more.
Ye gods. size_t is defined by ANSI C. Can't one count on *anything*? :-)
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Karl Fogel <kf...@galois.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Agreed. Seems like I asked about something similar a while back and people
> said "no way". When APR gets split out of Apache (probably this week), then
> we can bring this up on the new APR dev lists.
Okay, sounds good.
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 06, 2000 at 04:58:55PM -0600, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
> > Well, there is ANSI C (the syntax/compiler), and then there are the
> > libraries. While we can easily require an ANSI C compiler (and we do), the
> > library/headers is possibly a different issue.
> >
> > apr_size_t's presence signals the fact that at some point, size_t was NOT
> > available somewhere.
>
> But it does not indicate that size_t was not present on a system
> claiming to be ANSI C-compliant.
>
> Because apr_size_t was inherited via some historical issue in Apache
> (which might, for all I know, have been trying to compile in non-ansi
> environments), we don't actually know that there are systems where APR
> currently
>
> a) compiles and works with apr_size_t
> b) but doesn't without apr_size_t
>
> My suspicion is that there is no such environment -- that anywhere APR
> can be used these days, there is a working size_t anyway.
>
> If some APR developer knows of a system that contradicts this, then
> there's a compelling reason to keep `apr_size_t'. But if it's just
> around because someone encountered a problem once, maybe it's time to
> get rid of it?
Agreed. Seems like I asked about something similar a while back and people
said "no way". When APR gets split out of Apache (probably this week), then
we can bring this up on the new APR dev lists.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Karl Fogel <kf...@galois.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Well, there is ANSI C (the syntax/compiler), and then there are the
> libraries. While we can easily require an ANSI C compiler (and we do), the
> library/headers is possibly a different issue.
>
> apr_size_t's presence signals the fact that at some point, size_t was NOT
> available somewhere.
But it does not indicate that size_t was not present on a system
claiming to be ANSI C-compliant.
Because apr_size_t was inherited via some historical issue in Apache
(which might, for all I know, have been trying to compile in non-ansi
environments), we don't actually know that there are systems where APR
currently
a) compiles and works with apr_size_t
b) but doesn't without apr_size_t
My suspicion is that there is no such environment -- that anywhere APR
can be used these days, there is a working size_t anyway.
If some APR developer knows of a system that contradicts this, then
there's a compelling reason to keep `apr_size_t'. But if it's just
around because someone encountered a problem once, maybe it's time to
get rid of it?
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Karl Fogel <kf...@galois.collab.net>.
Jim Blandy <ji...@zwingli.cygnus.com> writes:
> I suggest we add AC_TYPE_SIZE_T to configure.in, and use size_t
> throughout. If there are no objections, I'll do this shortly.
Amen.
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Jim Meyering <me...@ascend.com> writes:
>
> Greg Stein <gs...@lyra.org> wrote:
> | Well, there is ANSI C (the syntax/compiler), and then there are the
> | libraries. While we can easily require an ANSI C compiler (and we do), the
> | library/headers is possibly a different issue.
> |
> | apr_size_t's presence signals the fact that at some point, size_t was NOT
> | available somewhere.
>
> That was certainly the case.
> That's why autoconf's AC_TYPE_SIZE_T macro came into being.
> It defines size_t to be `unsigned' on systems that don't define size_t.
> Then you can use `size_t' even on systems that lack it.
I suggest we add AC_TYPE_SIZE_T to configure.in, and use size_t
throughout. If there are no objections, I'll do this shortly.
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Jim Meyering <me...@ascend.com>.
Greg Stein <gs...@lyra.org> wrote:
| Well, there is ANSI C (the syntax/compiler), and then there are the
| libraries. While we can easily require an ANSI C compiler (and we do), the
| library/headers is possibly a different issue.
|
| apr_size_t's presence signals the fact that at some point, size_t was NOT
| available somewhere.
That was certainly the case.
That's why autoconf's AC_TYPE_SIZE_T macro came into being.
It defines size_t to be `unsigned' on systems that don't define size_t.
Then you can use `size_t' even on systems that lack it.
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Greg Stein <gs...@lyra.org>.
Well, there is ANSI C (the syntax/compiler), and then there are the
libraries. While we can easily require an ANSI C compiler (and we do), the
library/headers is possibly a different issue.
apr_size_t's presence signals the fact that at some point, size_t was NOT
available somewhere.
Cheers,
-g
On Mon, Nov 06, 2000 at 04:44:50PM -0600, Karl Fogel wrote:
> In that case, I would prefer to use `size_t', so as not to confuse
> people into mistakenly thinking that something special is going on.
>
> Subversion is only meant for ANSI C, and `size_t' is ANSI, so as far
> as Subversion is concerned, it's always okay.
>
> If APR's target audience is also ANSI C (which it appears to be,
> judging from the function prototypes), then probably APR could safely
> get rid of `apr_size_t' too, and for the reasons given above I think
> that would be a good idea.
>
> (Of course, it should still define it to size_t, for backwards
> compatibility, but it wouldn't have to document it nor encourage its
> use anymore.)
>
> -K
>
> Greg Stein <gs...@lyra.org> writes:
> > On Tue, Nov 07, 2000 at 12:55:45AM +0100, Branko Cibej wrote:
> > > Karl Fogel wrote:
> > > >> By the way, shouldn't that parameter be `apr_size_t'?
> > > >
> > > > I'm not really sure what the advantage/disadvantage would be. (?)
> > >
> > > Oh well, no advantage as such, just consistency. Do we want to be
> > > consistent about using APR types? I'd say yes, if it doesn't cost a lot,
> > > but It's not my call.
> >
> > apr_size_t exists in case some whacko platform doesn't have a size_t in its
> > header files. Dunno any, but the need was discovered by Apache (at some
> > point in the past) and it just flowed into APR.
> >
> > My guess is that it isn't really needed any more.
> >
> > I'm with Branko on this one: let's use apr_[s]size_t consistently.
> >
> > Cheers,
> > -g
> >
> > --
> > Greg Stein, http://www.lyra.org/
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Karl Fogel <kf...@galois.collab.net>.
In that case, I would prefer to use `size_t', so as not to confuse
people into mistakenly thinking that something special is going on.
Subversion is only meant for ANSI C, and `size_t' is ANSI, so as far
as Subversion is concerned, it's always okay.
If APR's target audience is also ANSI C (which it appears to be,
judging from the function prototypes), then probably APR could safely
get rid of `apr_size_t' too, and for the reasons given above I think
that would be a good idea.
(Of course, it should still define it to size_t, for backwards
compatibility, but it wouldn't have to document it nor encourage its
use anymore.)
-K
Greg Stein <gs...@lyra.org> writes:
> On Tue, Nov 07, 2000 at 12:55:45AM +0100, Branko Cibej wrote:
> > Karl Fogel wrote:
> > >> By the way, shouldn't that parameter be `apr_size_t'?
> > >
> > > I'm not really sure what the advantage/disadvantage would be. (?)
> >
> > Oh well, no advantage as such, just consistency. Do we want to be
> > consistent about using APR types? I'd say yes, if it doesn't cost a lot,
> > but It's not my call.
>
> apr_size_t exists in case some whacko platform doesn't have a size_t in its
> header files. Dunno any, but the need was discovered by Apache (at some
> point in the past) and it just flowed into APR.
>
> My guess is that it isn't really needed any more.
>
> I'm with Branko on this one: let's use apr_[s]size_t consistently.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 07, 2000 at 12:55:45AM +0100, Branko Cibej wrote:
> Karl Fogel wrote:
> >> By the way, shouldn't that parameter be `apr_size_t'?
> >
> > I'm not really sure what the advantage/disadvantage would be. (?)
>
> Oh well, no advantage as such, just consistency. Do we want to be
> consistent about using APR types? I'd say yes, if it doesn't cost a lot,
> but It's not my call.
apr_size_t exists in case some whacko platform doesn't have a size_t in its
header files. Dunno any, but the need was discovered by Apache (at some
point in the past) and it just flowed into APR.
My guess is that it isn't really needed any more.
I'm with Branko on this one: let's use apr_[s]size_t consistently.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Branko Čibej <br...@xbc.nu>.
Karl Fogel wrote:
>> By the way, shouldn't that parameter be `apr_size_t'?
>
>
> I'm not really sure what the advantage/disadvantage would be. (?)
Oh well, no advantage as such, just consistency. Do we want to be
consistent about using APR types? I'd say yes, if it doesn't cost a lot,
but It's not my call.
--
Brane �ibej
home: <br...@xbc.nu> http://www.xbc.nu/brane/
work: <br...@hermes.si> http://www.hermes-softlab.com/
ACM: <br...@acm.org> http://www.acm.org/
Re: CVS update: subversion/subversion/libsvn_subr hashdump.c
Posted by Karl Fogel <kf...@galois.collab.net>.
Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> brane@tigris.org wrote:
>
> > Log:
> > * libsvn_subr/hashdump.c (read_length_line): Change `i' to `size_t' to
> > match parameter and silence MSVC warning.
>
> By the way, shouldn't that parameter be `apr_size_t'?
I'm not really sure what the advantage/disadvantage would be. (?)
-K