On Thu, 2009-06-25 at 16:24 +0100, Stefan Sperling wrote:
> On Thu, Jun 25, 2009 at 04:11:01PM +0100, Julian Foad wrote:
> > 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.
>
> He complains about having to use casts to eliminate compiler
> warnings. Well, that's probably a problem with the compiler.
It's not really a problem with the compiler, it's a problem that all
compilers have and all programmers have because of the way the C
language specification defines the rules. In a differently defined
language, unsigned integers could work well. In C, they only work well
in simple, localised contexts. They were mainly intended for low-level
bit manipulation, not to provide a "value must be >= 0" constraint.
> He also says you cannot reliably subtract two unsinged numbers
> from one another. But the same holds for signed values. Both can
> wrap around.
He doesn't say that. You're right that both can wrap around. The
difficulty he implied is with avoiding compiler warnings.
> > > > > /* 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.
>
> Now I've looked at it, too. :)
> I agree that the docstring is fairly unclear and does not
> match the implementation. Do you want to adjust the docstring?
Already done.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2365385
Received on 2009-06-25 18:31:16 CEST