Stefan Sperling wrote:
> On Thu, Jun 25, 2009 at 03:05:01PM +0100, Julian Foad wrote:
> > Would there be an advantage in taking a length parameter instead of an
> > end pointer? I think you would still need the equivalent assertion
> > (length >= 0), because C doesn't protect against passing a negative
> > number even if the data type is "unsigned".
>
> But that's a good reason for consistenly using unsinged.
> On all levels. If the function already wants unsinged, the caller
> should try to pass unsigned, too, without casting, anywhere.
Unfortunately that doesn't work as well as you'd hope. See, for example,
this discussion:
<http://blogs.msdn.com/matt_pietrek/archive/2004/11/12/256775.aspx>...
starting with the comment from "Adrian" half way down.
> > If you want to use a length
> > for other reasons, such as consistency with other APIs, that's fine of
> > course.
>
> It's just consistency, really. And also because an API that allows you
> to simply pass sizeof(buf) instead of pointer offsets is much easier
> to use, IMO. No brain-power involved for the programmer, because
> the programmer can assume that the function will take care not to
> overrun the buffer. That's just a pattern I've grown used to.
>
> > Also:
> >
> > > /* Return the first eol marker found in [@a buf, @a endp) as a
> > > * NUL-terminated string, or NULL if no eol marker is found.
> > > *
> > > * If the last valid character of @a buf is the first byte of a
> > > * potentially two-byte eol sequence, just return "\r", that is,
> >
> > Shouldn't it return what's there (which could be "\n" or "\r") rather
> > than always "\r" ...
> >
> > > * assume @a buf represents a CR-only file. This is correct for callers
> >
> > ... and "CR-only or LF-only"?
>
> I don't know. The function has always been doing this, even
> while it was still a static function in libsvn_diff.
> I don't want to change this behaviour because I'd have to tweak
> the callers, too.
I looked at the implementation. It does what I thought it should. The
doc string's wrong.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2365328
Received on 2009-06-25 17:12:11 CEST