Keith Ray thoughts about BAd APIs
Ray has a point, bad API start at the very beginning although I’m not certain in the supplied example: problem lies in the language itself. alloc
just presents a solution as best captured by a language philosophy very
useful in past times (and still suitable for certain things).
I’m not a C guy but if I where one I would object against keeping double of information just to make sure that StringCopy
like operation does not write past boundaries. Don’t be enraged, I do
think this to be a worthwhile goal but then again how would you handle
a request for an overwrite anyway?
For
a debug build an assertion would just be fine from the library, but how
about production builds? Note that there is none return code from StringCopy
signaling if copying occurred or it was ignored for safety reasons. Not
to think about the further complications of having yet another return
code to worry about: what if it is not handled? Of course the caller
could always check before StringCopy but then again how would you reinforce it?
If you want safety (I do) use a language that has the right support for it! I’m really annoyed when I see char* like constructs when a C++ compiler with an excellent from both safety and performance std::string is readily available.
