Summary:ASTERISK-05998: [patch] va_copy not existing on FreeBSD
Reporter:Luigi Rizzo (rizzo)Labels:
Date Opened:2006-01-06 13:14:47.000-0600Date Closed:2006-01-14 23:26:19.000-0600
Versions:Frequency of
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.


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

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.