On 09/01/2014 17:30, Jordan Rose wrote:
On Jan 9, 2014, at 6:57 , Alp Toker <[email protected]
<mailto:[email protected]>> wrote:
I'm not making an assertion. The standard is very clear on this:
*17.6.4.3 Reserved names [reserved.names]*
If a program declares or defines a name in a context where it is
reserved, other than as explicitly allowed by this Clause, its
*behavior is undefined*.
*17.6.4.3.2 Global names [global.names]*
Certain sets of names and function signatures are always reserved
to the implementation:
* *Each name that contains a double underscore __*or begins
with an underscore followed by an uppercase letter (2.12) *is
reserved to the implementation for any use*.
* Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.
I know I shouldn't be getting into this, but...
*1.3.24 undefined behavior [defns.undefined]*
behavior for which this International Standard imposes no requirements
/[ Note: Undefined behavior may be expected when this
International Standard omits any explicit definition of behavior
or when a program uses an erroneous construct or erroneous data.
*Permissible undefined behavior* ranges from ignoring the
situation completely with unpredictable results, *to behaving
during translation or program execution in a documented manner
characteristic of the environment* (with or without the issuance
of a diagnostic message), to terminating a translation or
execution (with the issuance of a diagnostic message). Many
erroneous program constructs do not engender undefined
behavior; they are required to be diagnosed. — end note ]/
(emphasis mine)
As I read this, a valid interpretation of this program is that when
LEAK_SANITIZER is defined, the program contains undefined behavior,
and therefore it should only be set in a context when the particular
implementation is known to do something sensible for this particular
undefined behavior (that is, use the function at runtime to disable
leak checking).
I don't see this as abstractly different from the standard-specified
practice of replacing the global operator new, so I don't think it's
inherently an anti-pattern. I think everyone agrees on this since
you've said already you'd have no objections if the name weren't one
of the restricted [global.names] names.
Would it help if the function were pre-declared in a system header,
and then just implemented or not implemented in user code?
Hi Jordan,
That's the current situation -- as long as sanitizer headers are
available and in use the part of the spec you highlighted means it's
acceptable.
The problem arises when sanitizer headers aren't available.
The discussion now is whether we can find a way for Kostya to provide
the function definition unconditionally without having to wrap it in an
ifdef.
This function is documented as being special and different from the
other __lsan_ implementation-defined functions, so my suggestion is to
give it a conventional C user library name such as
LSANShouldDisableSanitizer() and place the declaration in an
lsan_control.h header. That will make it clear that it's intended to be
defined and treated as an ordinary weak linked function.
Apart from correctness, it appears this would be closer to the intention
given that this is a control function.
Alp.
Jordan
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
