This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/17308] nonnull attribute not as useful as it could


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308

frankhb1989 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |frankhb1989 at gmail dot com

--- Comment #13 from frankhb1989 at gmail dot com ---
It should be noted that current implementation is conflict with assertions in
some cases, as in
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/VA2QCXJGXVLH43327TRR5UM2BP52DWIC/.
The purpose of such an attribute is not emphasized in the documentation, which
leads to the confusion.

I'm actually not against the semantics it implies, but I find the warning
actually reduce its availability for other reasons.

Note `assert` is required to be supported by the standard, so it will work
across different implementations, including those do not support
`__attribute__` at all. To get the code portable, the attributes will always be
wrapped in macros whose names are not reserved identifiers. It should be
natural that by conditionally defining such macros as nothing, each
configuration of every implementation would be happy eventually, because
modifying assertions everywhere in current code (instead modifying the macros)
is obviously infeasible in general.

A question is, when to disable the attribute?

For debug build configurations (with `NDEBUG` undefined), it has almost no side
effect by conditional definition based on some conditions (like `NDEBUG`),
except one: the conditions may have to be duplicated in #ifdef/#if in different
places of the code. It is still not a big trouble for `assert` normally, but it
can be a disaster for custom assertion macros when the conditions are
complicated enough. And though rarely, it can be a nightmare after the
condition macros are defined (after necessary #undef) more than once, by
different authors of the code.

For release configurations (such as builds with properly defined `NDEBUG`), the
problem is more serious. Since the attribute is designed as a hint of
optimization, it should not be defined as nothing besides debugging. But to
modify all occurrence of assertions is still even more absurd, whether they
will generate code or not.

So there is a dilemma: which one to keep, the assertions or the attribute?
Removing the assertions is infeasible; unconditionally disabling the attribute
is illogical (and totally nonsense for old versions of GCC which I need to
adapt to). And clearly, I don't want to maintain multiple copies of the code
just for different build configurations; I definitely need both of them in such
cases. Thus either choice is essentially bad.

The final workaround (*not the fix*) is to disable the warning itself, which is
configuration-neutral and it should does work at least as old versions of GCC.
However, old compiler drivers do not recognize such options. To maintain the
divergence in build scripts is dirty. So it should better be... pragmas? The
last problem: #pragma or _Pragma to disable such diagnostics does not work. Is
it a bug, or unsupported at all?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]