|Summary:||ASTERISK-05998: [patch] va_copy not existing on FreeBSD|
|Reporter:||Luigi Rizzo (rizzo)||Labels:|
|Date Opened:||2006-01-06 13:14:47.000-0600||Date Closed:||2006-01-14 23:26:19.000-0600|
|Environment:||Attachments:||( 0) 6155.patch|
|Description:||as the subject says, the recently introduced utils.c::__ast_string_field_index_build()|
uses va_copy() which however does not exist on FreeBSD and maybe other
systems. As a workaround, you can use
- va_copy(ap2, ap1);
+ va_start(ap2, format);
Actually, you can also move the va_start/va_end around the vsprintf(),
and just use them on variable 'ap1' which is unused at that point.
****** ADDITIONAL INFORMATION ******
I note that there is another use of va_copy in asterisk, but it is for
those systems that do not have vasprintf() so it does not hit freebsd.
|Comments:||By: Tilghman Lesher (tilghman) 2006-01-07 00:18:47.000-0600|
I'm surprised that FreeBSD does not have va_copy(). It's required by C99 and it's included in gcc 3.
By: Luigi Rizzo (rizzo) 2006-01-07 03:24:10.000-0600
yet... this is FreeBSD 4.11 and gcc 2.95.4, still widely used
in production environments. besides, there is little if any point
here in using va_copy when the alternative above is perfectly fine.
By: Tilghman Lesher (tilghman) 2006-01-07 07:32:47.000-0600
You need special approval from kpfleming or kram to make this change, as it clearly says in UPGRADE.txt (for 1.2) that a C99 compiler is required.
By: Luigi Rizzo (rizzo) 2006-01-07 16:54:02.000-0600
ok i suppose you have asked them feedback (because i am not entitled
to make the change anyways) ?
By: Matt O'Gorman (mogorman) 2006-01-13 14:28:44.000-0600
do we want to make an exception for this? I realize we werent intending to support anything less than gcc 3
By: Russell Bryant (russell) 2006-01-13 14:41:23.000-0600
Well, I think the idea is that we made that policy so that if we ever wanted to, we don't have to go too far out of our way to support older compilers. However, if there is an easy fix, such as in this case, it should be fine.
By: Tilghman Lesher (tilghman) 2006-01-13 15:05:14.000-0600
Hmm, it appears that gcc 2.95 defines __va_copy(), so that should work everywhere. And since both are defined as macros, we could simply do:
That should take care of all the exceptions.
By: Luigi Rizzo (rizzo) 2006-01-13 17:29:59.000-0600
1. i fetched the standard at
and it says (annex J pg 490) that whether va_copy is a macro
or a function is unspecified, so the #ifdef va_copy approach
may fail - you'd need some autoconf-like trick to detect
what is available and in what form.
2. in any case __va_copy() is not available in the gcc.2.95.4 in
freebsd 4.11 so it does not fix the portability problem i reported;
3. i don't understand why the __va_copy idea is coming out at all.
If you want to stick to your policy of requiring gcc >= 3 (and
everything that comes with it), then there is no reason to look for
alternatives, and let the freebsd people handle this in their
ports tree with a specific patch;
if you decide that you want to be flexible, then there isn't
anything simpler than what i proposed, and nobody is complaining
about the other usage of va_copy, so why do you care about that
one at all ?
By: Russell Bryant (russell) 2006-01-13 18:45:51.000-0600
I have posted a patch. I honestly am not familiar enough with how to safely use va_* to comfortably commit this.
By: Tilghman Lesher (tilghman) 2006-01-14 23:26:19.000-0600
I agree with rizzo that we should let FreeBSD handle this in their ports tree. Given the recent availability of gcc 4, there's little reason for us to try to go through the wringer about gcc 2 compromises, and that's exactly what the policy established by Kevin and Mark attempted to avoid. Closing issue.