[asterisk-bugs] [JIRA] (ASTERISK-19451) va_start/va_copy and va_end do not always match up

[Walter Doekes (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-19451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Walter Doekes updated ASTERISK-19451:
-------------------------------------

    Status: Waiting for Feedback  (was: Waiting for Feedback)

Looks correct. But I did notice potential calls to va_arg after a SENTINEL had been encountered. I corrected those. (They can produce segfaults or possibly undefined behaviour in the rarest of cases.)

P.S.1. The value va_arg call is in most cases not checked for NULL. But if that fails, you get a clean segfault when accessing NULL and not random undefined behaviour. I left that as-is.

P.S.2. Even though config.h mandates that we pass SENTINEL around, the code using the va_list always checks against NULL instead. That's not nice, although it's probably never wrong.
                
> va_start/va_copy and va_end do not always match up
> --------------------------------------------------
>
>                 Key: ASTERISK-19451
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-19451
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: General
>    Affects Versions: SVN
>            Reporter: Walter Doekes
>            Assignee: Walter Doekes
>            Severity: Minor
>         Attachments: ASTERISK-19451-1.8--2.diff, ASTERISK-19451-1.8.diff
>
>
> {noformat}
>    va_end()
>        Each invocation of va_start() must be matched by a corresponding invo‐
>        cation of va_end() in the same function.  After  the  call  va_end(ap)
>        the  variable  ap is undefined.  Multiple traversals of the list, each
>        bracketed by va_start() and va_end() are possible.  va_end() may be  a
>        macro or a function.
> {noformat}
> and
> {quote}[...] on systems where arguments are passed in registers, it may be necessary for va_start() to allocate memory, store the arguments there, and also an indication of which argument is next, so that va_arg() can step through the list. Now va_end() can free the allocated memory again.{quote}
> This is not always done right:
> - there is a va_end too many in main/utils.c
> - there are a couple too few in res/res_config_odbc.c and then lots of va_copy's aren't closed on early failure-return
> - res/res_config_pgsql.c and res/res_config_curl.c have lots of va_ends but does not start/copy any (they shouldn't va_end, the callers of ast_load_realtime_helper handle both va_start/va_end)
> And possibly a few more.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira