J
Jordan Abel
Chris said:[On extensions in general, with strlcat as an example]
Keith Thompson said:... C99 4p6 says:
A conforming implementation may have extensions (including
additional library functions), provided they do not alter the
behavior of any strictly conforming program.
with a footnote:
This implies that a conforming implementation reserves no
identifiers other than those explicitly reserved in this
International Standard.
Since no strictly conforming program can use strlcat(), an
implementation can legally provide it as an extension.
Indeed -- and then a not-strictly-conforming program can use it.
The biggest danger is that, by doing so, the not-strictly-conforming
program may fail to port to a future Standard C ("C08", perhaps),
if the authors of that future standard choose to include a strlcat()
function that is *different* from the one provided by the implementation
in question.
So in other words, an implementation is allowed to define their own
str[a-z]+ identifier, and that's conforming to the standard. But by
doing so, they run the risk of potential problems when a future version
of the standard decides to introduce that same identifier?
If so, why is an identifier like str[a-z]+ not reserved for: just the
standard and not the implementation? After all, aren't identifiers like
_strlcat() reserved for the implementation and not the standard (and
therefore an implementation should use _strlcat() instead of strlcat())?
I'd think that the standard wouldn't choose an arbitrary name like
strlcat(), but rather base it on its functionality in one or more
existing implementations.
The problem is where existing implementations conflict, or where the
standard decides to handle some corner cases in a way that existing
implementations don't. e.g. snprintf's return value.