It appears that dealing with null is a little inconsistent. Methods like len and as_str have return values, but everything else fail!s the task.

I would expect these all to do the same thing, and I would personally expect that course of action to be failure.

@alexcrichton Failure on .len() is the other possible course of action, but it just didn't seem particularly useful. The other methods fail because they don't have a sensible alternative behavior (well, with_ref() could yield the null pointer, but that's not very useful).

.as_str() has an optional return value because not all valid CStrings can be valid Rust strings (notably, CStrings don't require utf-8). I suppose it could return None on a non-utf8 string and fail on a null buffer, but as long as it has an optional return type already, why fail?

Incidentally, I think .iter() might also crash on null. The question is, make it fail or make it be an empty iterator? I'm tempted to make it fail. Although if I do that, that lends more credence to the suggestion to make .len() fail on null as well.

Hmm.

I've rewritten this to fail on null buffer. I'm also added the same failure to .iter().