This patch adds nullability annotations to <string>. This allows the compiler to warn if a null pointer is passed to a non-null annotated pointer argument. The main question is whether we want to add these annotations. It adds quite a bit of extra code and potential bugs (false warnings) for a potentially small gain.
I think this is interesting and it may have some value, however:
- I wouldn't annotate pointers that don't have any requirement with anything. In other words, I wouldn't use _Null_unspecified or _Nullable unless there's a benefit to doing that.
- I would define a libc++ macro for these builtins.
Also, can you link to or explain the full benefits of these builtins? I'm curious to know what the compiler can do with them (is there anything beyond warning if you pass nulltpr?).
I'm not sure how much value the _Null_unspecified and _Nullable annotations add.
I also don't see the value in annotating private internals, presumably we're not passing bad data ourselves, and any bad user data should be caught as it enters via the public API.
Further, there are a lot of changes to <string> but almost no tests for them. For each application of the _Nonnull annotation, we should be able to write a test that demonstrates the behavior change. If the annotation cannot be observed, we shouldn't add it.
Requesting more tests before this lands.
What value is produced by adding `_Nullable' here?
I get adding _Nonnull where applicable, but I'm less sold on the rest of the annotations.
Do we really need to decorate internal functions? We should be able to diagnose all ill-formed user data when it's passed into the public API.
Does this pass? It doesn't look like your typical verify tests. I think there's something going on here.