[asterisk-bugs] [Asterisk 0010390]: AST_LIST_REMOVE problems

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10390 
====================================================================== 
Reported By:                mihai
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10390
Category:                   General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.9  
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-06-2007 10:16 CDT
Last Modified:              08-06-2007 11:31 CDT
====================================================================== 
Summary:                    AST_LIST_REMOVE problems
Description: 
in linkedlists.h, at or around line 744 we have:

__res = curelm;

This will return the incorrect element (the one before the correct
element). The correct code would be:

__res = curelm->field.next;

Up until now, the return value of AST_LIST_REMOVE was not used anywhere in
Asterisk.  However, Russell's latest patch to 10289 makes use of that
return value

Also, if elm is NULL, then AST_LIST_REMOVE will crash.  Not checking for
NULL arguments is a more generic problem that is present in other list
related macros as well.
====================================================================== 

---------------------------------------------------------------------- 
 russell - 08-06-07 11:31  
---------------------------------------------------------------------- 
I think it's safe to assume that elm should never be NULL.  Like you said,
it's an assumption made in a lot of the macros.  But, if you wanted to
write a patch for it, I would probably apply it anyway, since it can't
hurt. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-06-07 11:31  russell        Note Added: 0068495                          
======================================================================