gcc varargs problem

[Bill Davidsen]

whoosh wrote:
> On 01-Aug-08 17:36:50 Bill Davidsen wrote:
>> whoosh wrote:
>>> all gcc's so far have accepted the following code,
>>>
>>> until now using gcc on Fedora 9:
>>>
>>>
>>> void f( va_list *pargs )
>>> {
>>> va_list args = *pargs ;
>>> ...
>>> }
>>>
>>> 64 bit Fedora 9's gcc regards this as an error, all the other gcc's eg 
>>> on 32 bit Fedora Core 3 have no problem with this.
>>>
>>>
>>> I use this a lot in order to pass var args to another function.
>>> eg I have recursive functions which take variable numbers of args
>>> and redirect to user supplied functions to process those args.
>>>
>>>
>>> for porting code I dont want to have to rewrite everything,
>>>
>> Yes, that is an issue, and even using the compatibility RPMs the new 
>> includes seem to be used and old code doesn't compile properly. I have 
>> set up a virtual machine using an old version (RH9 or FC1) so I can 
>> compile what I need and link static so I can use the code I need.
> 
> if the code is in an rpm and via a make file and sed and awk etc
> 
> then it is NEAR IMPOSSIBLE to change it!
> 
> perhaps the answer is to have an alternative implementation of varargs
> 
> which is backwards compatible. eg if you just use the stack for function
> 
> args then varargs should ALWAYS be straightforwardish.
> 
> 
> stack args are a bit slower but its not a big deal!
> 
> 
> from a development point of view it is always more efficient to 
> workaround the compiler than to workaround the source.
> 
In may case I have a large app maintained by a university. If I start 
changing the source I own it and get to retrofit all future changes. 
Therefore I do *not* even think about doing that, some day they will 
upgrade using grad students and calling the project a "lab course."

-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot