Re: svn commit: r11155 - in trunk/subversion: clients/cmdline include libsvn_client libsvn_ra_dav libsvn_ra_local libsvn_ra_svn libsvn_repos mod_dav_svn svnserve tests/clients/cmdline/getopt_tests_data

Garrett Rooney wrote:
> Philip Martin wrote:
>> We already have functions, e.g. svn_path_remove_components, where it
>> doesn't make make sense to pass a -ve value (they don't document it
>> either) so perhaps just say "-ve values are invalid".
>
> Why only document it when we can force the issue by declaring the
> argument unsigned? It seems awfully close to saying "we're never going
> to modify this argument" instead of just making it const.

There's a big difference: 'const' is enforced whereas 'unsigned' is not.

There is a strong case for avoiding 'unsigned' integer types altogether in C programming (except for low-level bit manipulations etc.). This has mainly to do with the fact that they hardly protect you at all from such errors because of automatic (silent) conversions from signed to unsigned, and especially because unsigned has priority when a binary operator takes one of each.

void blah(unsigned Revision);
...
int Offset = -2;
blah(Offset); /* Generally no error or warning. (you can make some compilers warn) */
...
int Offset = ...; /* number of revisions after (+ve) or before (-ve) Head */
unsigned Revision = HeadRevision();
if (Revision + Offset < 0) error();
/* Oops: will never error, because type of (Revision+Offset) is unsigned. */

The Java language takes this to a logical conclusion and has no unsigned types.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 1 19:25:01 2004