- Package:
- gcc
- Source:
- gcc-defaults
- Description:
- GNU C compiler
- Submitter:
- Anthony DeRobertis
- Date:
- 2026-02-07 05:29:01 UTC
- Severity:
- wishlist
- Tags:
I realize this is probably implemented easily, but a warning about asserts with obvious side effects would be nice. For example: assert(ptr = malloc(...)) /* programmer didn't understand/think about assert */ assert(*ptr++) /* ditto */ assert(f()) /* very suspicious */ assert(i = 1) /* programmer made typo */ Some of these may be caught by other warnings (e.g., assignment in conditional), at least on #undef NDEBUG builds. The problem with these is, of course, that everything works fine for the debugging builds.[0] Then you do a release candidate build, and suddenly everything breaks. I wouldn't worry about: #ifndef NDEBUG ... ptr++ ... #endif btw, because that looks a lot more guilty to even a novice than assert(), which looks like a function call. [0] I'm not sure if assert is allowed to double-use its macro arguments or not. So its possible that the standard would allow some of the above to break, even on debugging builds. - -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux bohr 2.4.16 #2 SMP Wed Nov 28 05:25:00 EST 2001 i686 Locale: LANG=en_US, LC_CTYPE=en_US Versions of packages gcc depends on: ii cpp 2:2.95.4-8 The GNU C preprocessor. ii cpp-2.95 1:2.95.4-0.011006 The GNU C preprocessor. ii gcc-2.95 1:2.95.4-0.011006 The GNU C compiler. iD8DBQE8Flhu5lsmI6uA7bQRAoTfAKCG/Vxgu9c0qW7KCXf7lHethM1iaQCePPqv w+iRz/SSHiD0T5Q1eA2V6Ww= =1dtZ -----END PGP SIGNATURE-----
Thank you very much for your problem report. It has the internal identification `c/6906'. The individual assigned to look at your report is: unassigned.
# submitted Debian report #123468 to gcc-gnats as PR c/6904 # http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=c/6904&database=gcc forwarded 123468 gcc-gnats@gcc.gnu.org retitle 123468 [PR c/6904] warn about asserts with side effects thanks
State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Tue Jan 7 17:40:58 2003
State-Changed-Why:
As much as I sympathize with the goal of such a warning, I
doubt it will be possible to implement it. The reason is
that assert() is usually implemented via a macro. On my
system, it reads (if !NDEBUG):
--------------------
# define assert(expr) \
(__ASSERT_VOID_CAST ((expr) ? 0 : \
(__assert_fail (__STRING(expr), __FILE__, __LINE__, \
__ASSERT_FUNCTION), 0)))
---------------------------
so at the time the _compiler_ (as opposed to the
preprocessor) sees the condition, the special name "assert"
is already gone. On the other hand, the preprocessor doesn't
know anything about expressions with or without side effects.
I thus seriously doubt that such a warning can be implemented
without gross hacks...
W.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6906
State-Changed-From-To: feedback->suspended
State-Changed-By: neroden
State-Changed-When: Thu Apr 10 18:01:24 2003
State-Changed-Why:
Probably not implementable; keeping in case it is.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6906
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 neroden@gcc.gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC|neroden@gcc.gnu.org |------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
--
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic
Last reconfirmed|2003-10-01 04:02:16 |2003-12-31 16:03:17
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
------- Additional Comments From mbp at sourcefrog dot net 2004-08-10 23:56 -------
It might be nice if there were a compile-time function similar to
__builtin_constant_p which checked whether an expression was free of
side-effects. One could then write
# define assert(expr) \
(__builtin_pure_p((expr)) ? _real_assert(expr) :
warning_assert_expr_not_pure())
So this would be true for things like
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2005-09-10 16:23:19 |2005-12-10 05:43:37
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
------- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-15 19:45 ------- *** Bug 29480 has been marked as a duplicate of this bug. ***------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
--
fang at csl dot cornell dot edu changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fang at csl dot cornell dot
| |edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906
------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.
------- Comment #5 from chris dot pickett at mail dot mcgill dot ca 2008-03-03 02:55 ------- Maybe you could fix the preprocessor to warn about operators with known side effects. Can cpp see the entire expr in assert (expr)? If so, just search the tokens for =, ++, --, +=, -=, etc.------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 Florian Weimer <fw at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 felix <felix.von.s at posteo dot de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felix.von.s at posteo dot de In fact, I patched my copy of GCC to add __builtin_pure_p defined just like that and it seems to work fine. Might submit it soon (I didn't write any tests, though).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 felix <felix.von.s at posteo dot de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |felix.von.s at posteo dot de--- Comment #9 from felix <felix.von.s at posteo dot de> --- I have just realised that __builtin_pure_p is already expressible: #define __builtin_pure_p(expr) \ (__builtin_object_size(((void)(expr), ""), 2)) If (expr) is free of side effects, this is the same as __builtin_object_size("", 2), which is 1. Otherwise, the expression returns 0. This is documented behaviour, by the way. The documentation for __builtin_object_size at <https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html> states: Experimentation reveals __attribute__((pure)) is enough for __builtin_object_size to consider a function free of side effects.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 Sam James <sjames at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=111144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 Eric Gallager <egallager at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=105369
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 Sam James <sjames at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sjames at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 Eric Gallager <egallager at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |egallager at gcc dot gnu.org--- Comment #10 from Eric Gallager <egallager at gcc dot gnu.org> --- See also related issues bug 105369 and bug 111144
*你好!* 最近几个月，中国大陆很多医院人满为患，大部分人都发烧咳嗽。根据新唐人记者的采访，有些病人发病的速度极快，三四天时间就会出现高烧和肺部溃烂的情况，甚至很快会死亡。 但是中国医院却统一以流感方式进行处理，官方到底隐瞒了多少疫情的真相呢？ 真相不会永远沉默 正义终究要来临。 详情请看附件。 祝你一切都好！--- *法轮大法是佛法, 是正法。诚念九字真言得福报。* *法轮大法好，真善忍好* 中共进行活体器官移植可谓“一箭双雕”。在消除异己的同时，在器官移植市场获取暴利。受害者主要是法轮功学员，由于他们经常打坐，冥想，身体比较健康，因此也称为了器官活摘的主要受害者。当然，还包括政治异见人士和其他公民。据估算，自2000年以来，在中国进行了超过一百万例谋杀性器官移植。
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=117249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |87403 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
*你好!* 你可知道，空气清新剂（Air-fresheners) 可能致癌 ？ 研究人员发现，喷雾剂喷出的某些芳香剂，如Pinene 和Limonene, 有可能和臭氧反应生成致癌物质。 当大气中含臭氧量高的时候，只要你开窗就可触发这类化学反应。这项研究结果发表在最近一期的《环境科学和技术》的杂志上。 点击查看更多，不要错过任何重要信息！ https://tinyurl.com/zhiai-kongqi-qingxin-ji 祝你平安！--- 真理不会因为少数人的否定而消失，公正最终会到来。
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6906 Eric Gallager <egallager at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=57612