smartlist_len returns a (signed) int

[rransom]

smartlist_len(sl) has type int. It shouldn't be signed.

[rransom]

I don't think this can be fixed on 0.2.2.x. (We would have too many merge conflicts.)

[rransom]

It's also not quite clear what we want to do for lengths in general -- do we sometimes use negative return values to indicate failure of a function that would normally return a length? At the very least, we need safe (overflow-checking) unsigned-to-signed and signed-to-unsigned cast macros.

[mansour]

Replying to rransom:

It's also not quite clear what we want to do for lengths in general -- do we sometimes use negative return values to indicate failure of a function that would normally return a length? At the very least, we need safe (overflow-checking) unsigned-to-signed and signed-to-unsigned cast macros.

One approach is to pass a pointer to where "returned" lengths will be stored as an argument, and use the return values to indicate errors only.

See attached for an example.

[nickm]

If we're going to change the return type of smartlist_len() {or even if we're not}, we need to be prepared to audit all 448 places that uses it, to make sure it behaves right given an unsigned or a size_t or whatever.

As a stopgap, perhaps we should just ensure that a smartlist's size can't grow larger than INT_MAX ?

[nickm]

At the moment, actually, thanks to the smartlist_ensure_capacity fixes, we have the property that the capacity of a smartlist can never be more than INT_MAX . So it's okay to return an int for smartlist_len. I'm throwing this out of 0.2.3.x; it's a big refactoring, and I'm pretty sure that we don't actually *want* to allow a smartlist to have anything close to INT_MAX entries.