[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Pre-release version of ISO-8601 dates

From: Nuutti Kotivuori <naked_at_iki.fi>
Date: 2002-05-14 08:00:48 CEST

Karl Fogel wrote:
> Karl Fogel <kfogel@newton.ch.collab.net> writes:
>> The doc string for svn_time_from_nts() in svn_time.h should mention
>> this behavior (of returning 0 when it can't parse the timestring).
> ...But Philip's suggestion to just return error instead is better!
> :-)

Philip Martin wrote:
> Nuutti Kotivuori <naked@iki.fi> writes:
>> Index: ./subversion/libsvn_subr/time.c
>> ===================================================================
> [snip]
>> apr_time_t
>> svn_time_from_nts (const char *data)
>> {
> It's not part of your current patch, but this function can obviously
> fail. I think it should be
> svn_error_t * svn_time_from_nts(apr_time_t *when, const char *data,
> apr_pool_t *pool)

Yes, returning an error would be good. Also, the used apr_time_exp_gmt
and apr_implode_gmt can return errors (well, atleast the latter can).

But this would mean to touch each and every invocation of
svn_time_from_nts - which is a bit bigger job.

So the returning zero is an intermediate form (the previous version
just silently returned random times) that I left as is for this
release of the patch. But a viable solution indeed is not to document
the returning of 0 - but to fix the logic.

So - what should be done about those function calls? If conversion to
function that can return errors and handling all callers is wanted, I
can try to do it. Or such a job could just as well be listed as just
another bitesized task. I would, personally, rather get this format
changing off my hands ASAP - and the error handling can be fixed after
that - but you may feel differently.

-- Naked

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 14 08:02:42 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.