malloc for struct

M

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;

}
 
M

Michael Mair

Madhu said:
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
 
V

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 */
}
 
M

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?
 
M

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?
 
V

Vladimir S. Oka

Madhu opined:
Thanks Vladimir and Michael. That was the fix.

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.
 
M

Madhu

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

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
 
M

Michael Mair

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
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

malloc 40
struct/malloc failure 3
Malloc question 9
malloc 11
malloc for struct 7
Chatbox for website 0
struct inside struct 5
malloc and maximum size 56

Members online

No members online now.

Forum statistics

Threads
474,176
Messages
2,570,947
Members
47,498
Latest member
log5Sshell/alfa5

Latest Threads

Top