Bug 150149 - local variable used before set
local variable used before set
Product: Fedora
Classification: Fedora
Component: jasper (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2005-03-02 17:10 EST by David Binderman
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-24 09:28:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
init tmpval before first use (334 bytes, patch)
2005-06-24 09:17 EDT, Rex Dieter
no flags Details | Diff

  None (edit)
Description David Binderman 2005-03-02 17:10:40 EST
Description of problem:

I just tried to compile package jasper-1.701.0-3 from 
Redhat Fedora Extras development tree.

The Intel compiler said

pnm_enc.c(431): remark #592: variable "tmpval" is used before its
value is set

The source code is

        uint_fast32_t tmpval;
        int c;

        n = (wordsize + 7) / 8;
        tmpval &= PNM_ONES(8 * n);

Suggest init tmpval before first use.

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Rex Dieter 2005-06-22 12:47:16 EDT
Update to kile-1.8.1 coming soon... See bug #161343
Comment 2 David Binderman 2005-06-23 05:27:08 EDT
>Update to kile-1.8.1 coming soon

Good, but does an upgrade guarantee that a bug is fixed ?

It might be a wise idea to have a look at the new version
to check that the bug is fixed.
Comment 3 Michael Schwendt 2005-06-24 07:21:32 EDT
Yeah, right. Please either 

 * do care and fix the bug/forward it upstream + close this as UPSTREAM


 * don't care and leave it open.
Comment 4 Rex Dieter 2005-06-24 09:04:10 EDT
Looks like I closed the wrong bug.  Reopening...
Comment 5 Rex Dieter 2005-06-24 09:17:46 EDT
Created attachment 115931 [details]
init tmpval before first use

Attempt 1 at patch.
Comment 6 Rex Dieter 2005-06-24 09:28:53 EDT
Sent Upstream: http://groups.yahoo.com/group/jasper-discussion/message/891
Comment 7 Michael Schwendt 2005-06-24 10:04:56 EDT
Watching the diff outside its full context, it looks highly questionable. "zero
AND something" remains zero.
Comment 8 Rex Dieter 2005-06-24 10:15:23 EDT
Good point, however, "Undefined value AND something" is even scarier, don't you
think?  (-:
Comment 9 Rex Dieter 2005-06-24 10:16:51 EDT
I'm starting to think this is a geniune coding error and
tmpval &= PNM_ONES(8 * n);
was probably meant to be (something like)
tmpval = PNM_ONES(8 * n);
Comment 10 Michael Schwendt 2005-06-24 11:36:25 EDT
And even then, the next line would overwrite tmpval completely:

    tmpval = (*val) << (8 * (4 - n));

I think it's a thinko. It's WORKSFORME for us, but upstream should have interest
in cleaning up this code. Based on the function name (put an unsigned integer
into a stream) and what the code does (store the uint bytewise, most-significant
byte first), the criticised line does nothing useful. Let's see:

static int pnm_putuint(jas_stream_t *out, int wordsize, uint_fast32_t *val)
	int n;
	uint_fast32_t tmpval;
	int c;

	n = (wordsize + 7) / 8;
	tmpval &= PNM_ONES(8 * n);
	tmpval = (*val) << (8 * (4 - n));
	while (--n >= 0) {
		c = (tmpval >> 24) & 0xff;
		if (jas_stream_putc(out, c) == EOF) {
			return -1;
		tmpval = (tmpval << 8) & 0xffffffff;
	return 0;

Example: wordsize=8 => n=8+7/8=15/8=1 => it shifts val 24 bits to the left into
tmpval, so the loop stores bits 31-24 (the 8 bit wordsize) into the stream and
is done.

The PNM_ONES macro fills at most 32 bits with ones. When dealing with signed (!)
integers, one could use it for a mask, which extends the sign-bit into the
upper-most bits of a word. E.g. store 4-bit 0xe (-2) as 8-bit 0xfe. However,
this code does nothing like that since it overwrites tmpval with the full 32-bit
*val as the last step before writing the individual bytes into the stream. With
the shift to the left, the lower bits of tmpval are zeroed out.

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