[
https://issues.apache.org/jira/browse/MESOS-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bannier updated MESOS-5105:
------------------------------------
Issue Type: Improvement (was: Bug)
Summary: Implement clang-tidy check catching accidential use of wrapped
library functions (was: Implement clang-tidy check catching accidential use of
wrapped libc functions)
> Implement clang-tidy check catching accidential use of wrapped library
> functions
> --------------------------------------------------------------------------------
>
> Key: MESOS-5105
> URL: https://issues.apache.org/jira/browse/MESOS-5105
> Project: Mesos
> Issue Type: Improvement
> Reporter: Benjamin Bannier
>
> We define a number of wrappers for C stdlib or POSIX functions, e.g., in
> stout. The usual pattern is to reuse the name of the library function, but
> use "safer types", effectively adding an additional override for the wrapped
> function.
> Since functions in e.g., stout are not wrapped in namespaces (and we'd e.g.,
> pull both a libc function and a wrapper in the same scope with {{using}}
> directives anyway), there is a danger of accidentally calling the naked
> library function instead of the wrapped one, consider e.g.,
> {code}
> char* getenv(const char*); // C
> Option<string> getenv(const string); // stout
> void f() {
> getenv("string literal"); // calls the C function
> }
> {code}
> Good rules of thumb seem to be:
> - If both a C stdlib function and another function with identical name can be
> seen in the same scope, we shouldn't call the C stdlib function (but for the
> case where we are in the process of defining a wrapper),
> - For certain kinds of functions we should never use naked C stdlib
> functions, but always wrappers. This requires a catalog of possible wrappers.
> We should attempt to enforce these for C stdlib and POSIX functions with
> static analysis checks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
