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
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
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: #ifdef va_copy va_copy(whatever) #else __va_copy(whatever) #endif 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    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf   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.