Bug 145524 - assignments in assert statements - avoid ?
assignments in assert statements - avoid ?
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-01-19 06:46 EST by David Binderman
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-19 16:36:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Binderman 2005-01-19 06:46:06 EST
Description of problem:

I just had a look at the source code for glibc-2.3.4-3

I found the following assignment statements nested into assert statement.

../BUILD/glibc-20041219T2331/iconv/strtab.c:  assert (endp = retval +
+ 1);
../BUILD/glibc-20041219T2331/stdio-common/tst-ungetc.c:  assert ((c =
getc (fp)) == 'a');
../BUILD/glibc-20041219T2331/hurd/sigunwind.c:      assert
(link->thread.prevp = &ss->active_resources);

I'm not saying this code is wrong - just deeply suspicous. 
The code will do different things, depending on wether the assert
statements are switched in or out.

Suggest code rework to avoid such assignment statements in assert

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Jakub Jelinek 2005-01-19 16:36:24 EST
Thanks.  strtab.c and sigunwind.c fixed in CVS, tst-ungetc.c doesn't use the
normal assert, but defines its own assert macro, so there is no bug there.

Note You need to log in before you can comment on or make changes to this bug.