On 10/19/2015 07:23 AM, Mikhail Maltsev wrote:
On 10/19/2015 02:13 PM, Bernd Schmidt wrote:
But for normal C conditions the patches end up using flag_checking, so
the CHECKING_P macro buys us nothing over ENABLE_CHECKING.
Presumably 'if (CHECKING_P)' can be used for performance-critical parts
(in this case the condition will be DCE-d) and also for those parts of
the compiler which we want to decouple from 'options.h'.
IIRC, Jeff's idea was get rid of 'ENABLE_CHECKING' completely and use
either 'flag_checking' or 'CHECKING_P'. But I don't know what is the
consensus on it (I would like to hear Jeff's and Richard's opinion).
Of course it will be easy for me to adjust the patch to whatever the
final decision will be.
Bernd,
The problem is the existing ENABLE_CHECKING conditions.
Anything which is #ifdef ENABLE_CHECKING will have its behavior changed
if we change things so that ENABLE_CHECKING is always defined with a value.
So if we wanted to continue to use ENABLE_CHECKING, but with a value,
then every #ifdef has to be fixed all-at-once.
By using CHECKING_P we can incrementally work our way through uses of
ENABLE_CHECKING, converting them as we go as we're not changing the
meaning of ENABLE_CHECKING.
Once everything is converted, we just drop ENABLE_CHECKING completely.
Does using CHECKING_P make more churn? Perhaps, but it allows us the
freedom to incrementally fix the existing code rather than having to do
everything at once.
jeff
