c/6906: warn about asserts with side effects

c/6906: warn about asserts with side effects

[Matthias Klose]

>Number:         6906
>Category:       c
>Synopsis:       warn about asserts with side effects
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 01 16:36:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Anthony DeRobertis <asd@suespammers.org>
>Release:        3.1 (Debian) (Debian unstable)
>Organization:
The Debian Project
>Environment:
System: Debian GNU/Linux (unstable)
Architecture: i686
	
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  gcc-3.1        3.1-2          The GNU C compiler.
ii  binutils       2.12.90.0.7-1  The GNU assembler, linker and binary utiliti
ii  libc6          2.2.5-6        GNU C Library: Shared libraries and Timezone
host: i386-linux
configured with: /mnt/data/gcc-3.1/gcc-3.1-3.1ds2/src/configure -v --enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr --mandir=$\(prefix\)/share/man --infodir=$\(prefix\)/share/info --with-gxx-include-dir=$\(prefix\)/include/g++-v3-3.1 --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --enable-clocale=gnu --enable-threads=posix --enable-java-gc=boehm --enable-objc-gc i386-linux
>Description:
[ Reported to the Debian BTS as report #123468.
  Please CC 123468@bugs.debian.org on replies.
  Log of report can be found at http://bugs.debian.org/123468 ]

Anthony DeRobertis:
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.
>How-To-Repeat:
	
>Fix:
	
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: c/6906: warn about asserts with side effects

[neroden]

Synopsis: warn about asserts with side effects

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

Re: c/6906: warn about asserts with side effects

[bangerth]

Synopsis: warn about asserts with side effects

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