malloc for struct

[Madhu]

My question is quite basic. I have a function "ds707_async_orig_hdlr"
which gets called by another module.

cm_cdma_orig_params_s_type : is a struct defined in teh same file
as this function.

Now, when the entire code (with all other files) is run, I get a lint
error that points to the possibility of assignment to a NULL pointer in
the lines assigning values to the pointer to struct -
cdma_orig_params_ptr.
The code compiles and runs fine. Only lint is giving trouble. (Error
613 in Gimpel)

Is it because I haven't done a malloc here for cdma_orig_params_ptr ?
What is the problem ?

void ds707_async_orig_hdlr
(
const byte *dial_string,
int dial_string_len,
cm_cdma_orig_params_s_type *cdma_orig_params_ptr
)
{
cdma_orig_params_ptr->srv_opt = uint16 orig_so;
cdma_orig_params_ptr->activate_code = CM_OTASP_ACT_CODE_NONE;
cdma_orig_params_ptr->drs_bit = 1; /* maybe NA in async
*/
cdma_orig_params_ptr->sr_id_included = FALSE;
cdma_orig_params_ptr->qos_parms_incl = FALSE;
cdma_orig_params_ptr->last_act_data_net = SYS_SYS_MODE_NO_SRV;
*cdma_params_changed = TRUE;
*cm_srv_type = CM_SRV_TYPE_CDMA_SPECIFIC;

}

[Michael Mair]

Madhu schrieb:

My question is quite basic. I have a function "ds707_async_orig_hdlr"
which gets called by another module.

cm_cdma_orig_params_s_type : is a struct defined in teh same file
as this function.

Now, when the entire code (with all other files) is run, I get a lint
error that points to the possibility of assignment to a NULL pointer in
the lines assigning values to the pointer to struct -
cdma_orig_params_ptr.
The code compiles and runs fine. Only lint is giving trouble. (Error
613 in Gimpel)
Note: The code compiles and _seems_ to run fine.
This is an important difference -- the code may "run fine"
for your tests and may run into an access violation/segmentation
fault at other times.
Is it because I haven't done a malloc here for cdma_orig_params_ptr ?
No. It is because you do not check for null pointers.
What is the problem ?

void ds707_async_orig_hdlr
(
const byte *dial_string,
int dial_string_len,
cm_cdma_orig_params_s_type *cdma_orig_params_ptr
)
{
if (NULL != cdma_orig_params_ptr) { cdma_orig_params_ptr->srv_opt = uint16 orig_so;
cdma_orig_params_ptr->activate_code = CM_OTASP_ACT_CODE_NONE;
cdma_orig_params_ptr->drs_bit = 1; /* maybe NA in async
*/
cdma_orig_params_ptr->sr_id_included = FALSE;
cdma_orig_params_ptr->qos_parms_incl = FALSE;
cdma_orig_params_ptr->last_act_data_net = SYS_SYS_MODE_NO_SRV;
*cdma_params_changed = TRUE;
*cm_srv_type = CM_SRV_TYPE_CDMA_SPECIFIC;
} else {
/* Deal with the error here */
}
}

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Vladimir S. Oka]

Madhu opined:

My question is quite basic. I have a function "ds707_async_orig_hdlr"
which gets called by another module.

cm_cdma_orig_params_s_type : is a struct defined in teh same
file
as this function.

Now, when the entire code (with all other files) is run, I get a lint
error that points to the possibility of assignment to a NULL pointer
in the lines assigning values to the pointer to struct -
cdma_orig_params_ptr.
The code compiles and runs fine. Only lint is giving trouble. (Error
613 in Gimpel)

Is it because I haven't done a malloc here for cdma_orig_params_ptr
?
What is the problem ?

void ds707_async_orig_hdlr
(
const byte *dial_string,
int dial_string_len,
cm_cdma_orig_params_s_type *cdma_orig_params_ptr
)
{
cdma_orig_params_ptr->srv_opt = uint16 orig_so;
cdma_orig_params_ptr->activate_code = CM_OTASP_ACT_CODE_NONE;
cdma_orig_params_ptr->drs_bit = 1; /* maybe NA in async
*/
cdma_orig_params_ptr->sr_id_included = FALSE;
cdma_orig_params_ptr->qos_parms_incl = FALSE;
cdma_orig_params_ptr->last_act_data_net = SYS_SYS_MODE_NO_SRV;
*cdma_params_changed = TRUE;
*cm_srv_type = CM_SRV_TYPE_CDMA_SPECIFIC;

}

Your code is quite a mouthful, but I guess Lint is, quite rightly IMHO,
complaining about you not checking whether `cdma_orig_params_ptr` is
non-NULL before trying to dereference it. Try:

if (cdma_orig_params_ptr)
{
/* your code here */
}
--
BR, Vladimir

No one may kill a man. Not for any purpose. It cannot be condoned.
-- Kirk, "Spock's Brain", stardate 5431.6

[Madhu]

Thanks Vladimir and Michael. That was the fix.

may run into an access violation/segmentation
fault at other times

Totally. esp. in the app I'm programming for, it could be critical.

Its been a long while since I walked in pointer territory. If you can
clarify this, that would be great:
int *a; *a = 100; => error because pointer was not assigned an address
int *a; a = &b; *a = 100; => will work

In the case of ptr to struct why isn't there a need to malloc?

[Madhu]

Oh. Come to think of it, I have a guess.
there is no need for address assignment because this code is in a
function definition? i.e. Has the requisite space and addresses been
allotted already since the function parameters specify their type and
when the function is called, the address space is made ready?

[Vladimir S. Oka]

Madhu opined:

Thanks Vladimir and Michael. That was the fix.

may run into an access violation/segmentation
fault at other times Totally. esp. in the app I'm programming for, it could be critical.

Its been a long while since I walked in pointer territory. If you can
clarify this, that would be great:
int *a; *a = 100; => error because pointer was not assigned an
address
int *a; a = &b; *a = 100; => will work

Yes. The first line has `a` uninitialised, so dereferencing it is not
on. In the second line, `a` is initialised to the address of a
variable `b`, so 100 gets stored there. Whether storing an `int` in
`b` is OK, depends on what `b` is (which you didn't show).
In the case of ptr to struct why isn't there a need to malloc?

I'm not sure I understand this.

--
BR, Vladimir

A bug in the hand is better than one as yet undetected.

[Madhu]

> In the case of ptr to struct why isn't there a need to malloc?

I'm not sure I understand this.

That was just a weird question that came up in my head once you guys
told me the fix. I was wondering why I did not need to explicitly allot
space for the struct "cdma_orig_params_ptr" in my code and how I could
directly derefernce its members as in
cdma_orig_params_ptr->sr_id_included = FALSE;

while in the int example (with a and b) a first had to be assigned an
address.

I then figured it must be because all the coding in this particular
case is in a function where the pointer to the structure is a parameter
passed to the function; that the compiler takes care of alloting
requisite space since teh function defn is known previously.
Is that right?

Does my question make sense now? o/w forget it. its no big deal.

Thanks,
Madhu

[Michael Mair]

Madhu schrieb:

In the case of ptr to struct why isn't there a need to malloc?

I'm not sure I understand this.

You messed up the quoting levels and snipped the attributions;
this makes it hard to understand that the upper is by you and
the lower has been written afterwards.

With Vladimir S. Oka wrote

Madhu wrote

In the case of ptr to struct why isn't there a need to malloc?
I'm not sure I understand this.

this is much clearer.

That was just a weird question that came up in my head once you guys
told me the fix. I was wondering why I did not need to explicitly allot
space for the struct "cdma_orig_params_ptr" in my code and how I could
directly derefernce its members as in
cdma_orig_params_ptr->sr_id_included = FALSE;

while in the int example (with a and b) a first had to be assigned an
address.

I then figured it must be because all the coding in this particular
case is in a function where the pointer to the structure is a parameter
passed to the function; that the compiler takes care of alloting
requisite space since teh function defn is known previously.
Is that right?

Does my question make sense now? o/w forget it. its no big deal.

Yes. Someone has to provide the memory the pointer points to,
either the library or you. Make sure that you understand whether
this storage should be provided directly or indirectly by you.

If the pointer has a random value, i.e. points randomly somewhere
in memory, the whole thing still can seemingly work for a
time and then run amok, overwriting essential data elsewhere.

To conclude: A structure type is not handled differently from
a simple int in this respect.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.