Add comments on how to verify poimters. (#5196)

diff --git a/doc/antora/modules/developers/pages/coverity.adoc b/doc/antora/modules/developers/pages/coverity.adoc
index df7d195b16f4a08dcb1a3e7d0605f0bfc72298c8..8b5200374c59eb2e22afcc5ab658a7684232a2b5 100644 (file)
--- a/doc/antora/modules/developers/pages/coverity.adoc
+++ b/doc/antora/modules/developers/pages/coverity.adoc
@@ -125,7 +125,7 @@ static inline uint16_t fr_nbo_to_uint16(uint8_t const data[static sizeof(uint16_
 }
 ----
 
-Coverity considers not only the value fr_nbo_to_uint16() tainted, but the pointer as well. One can range check a length--how does one validate a pointer?
+Coverity considers not only the value fr_nbo_to_uint16() tainted, but the pointer as well. One can range check a length--how does one validate a pointer? Actually, there are ways. The talloc library lets you associate a string with allocated memory indicating its type, and gives you `talloc_get_type()` and `talloc_get_type_abort()` to check that type, and once that's known, if there's some property things of that type have, you can check that too. That reduces the issue to letting Coverity know that those actions validate the pointer--Coverity can recognize range checks on numeric values as validation, but this it won't recognize. The way around it is to split that out into a function and model it as verifying the pointer. That brings its own problem. If in the original function the state of the pointed at object affects what is done with it, that state checking code will have to be replicated in it.
 
 === Taint propagation