Bug 137378 - asterisk-capi-0.3.5-7: local variable used before set
Summary: asterisk-capi-0.3.5-7: local variable used before set
Status: RESOLVED FIXED
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: unspecified
Hardware: All SUSE Other
: P5 - None : Minor
Target Milestone: ---
Assignee: Reinhard Max
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-07 14:44 UTC by David Binderman
Modified: 2006-01-23 14:37 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Binderman 2005-12-07 14:44:00 UTC
I just tried to compile package asterisk-capi-0.3.5-7 with the Intel C
compiler. It said

chan_capi.c(151): warning #592: variable "CMSG2" is used before its value is set

The source code is

    while (!IS_LISTEN_CONF(&CMSG2)) {

but

/usr/include/capiutils.h:#define IS_LISTEN_CONF(m) ((m)->Command==0x05 && (m)->Subcommand==0x81)

so it is clear that CMSG2.Command is being tested before it's value
has been set.

I'm not sure what the fix for this should be, but it is clear that code
rework is required. 

Maybe

	memset( &CMSG2, 0, sizeof( CMSG2));

would be enough ?

I've tried emailing the author [ kpj@junghanns.net ] , but got no answer.
Comment 1 Reinhard Max 2005-12-07 15:10:07 UTC
I don't see any chance to fix this without the help of the author, because it is not obvious (at least to me) what the code in this function is supposed to do, and there are no comments.

But I am about to update Asterisk and all related packages for 10.1 anyways. So let's see if this bug still exists in chan_capi-0.4.0, and if so, I'll try to contact the author. I've been in contact with him before.
Comment 2 Reinhard Max 2005-12-07 15:24:57 UTC
Hmm - after finding that this function hasn't changed in the latest version of chan_capi, and looking at the code of check_wait_get_cmsg(), I think that initializing CMSG2 with zero-bytes, as you suggest, should be OK.

Another solution would be to turn the loop into a bottom-controlled one, so that CMSG2 gets initialized with real data rather than nulls, before the first check happens.

    do {
        error = check_wait_get_cmsg(&CMSG2);
    } while (!IS_LISTEN_CONF(&CMSG2));

Of course, if you dislike bottom-controlled loops, you can also do it like this:

    error = check_wait_get_cmsg(&CMSG2);
    while (!IS_LISTEN_CONF(&CMSG2)) {
        error = check_wait_get_cmsg(&CMSG2);
    }
Comment 3 Reinhard Max 2006-01-23 14:37:30 UTC
Fixed for 10.1.