This is a multi-part message in MIME format.
--------------090706050506090405020205
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Aaron Sloman wrote:
>>This is important because some native pop
>>code in the Xt interface invokes external C procedures using the varargs
>>protocol, but possibly not via an actual C wrapper, so it wouldn't have
>>been caught by a global change to C files. If anyone thinks there's an
>>issue here, I could try and rediscover whether/where it happens in more
>>detail.
>>
>>
>
>Having rebuilt the system using stdargs I've run quite a lot of tests of
>X facilities (including XVed and rclib extensions, and some bits of
>TEACH propsheet, and it all seems to work). I've used grep to search
>for things that might use varargs. but without success.
>
>
My first reaction to this was to say 'ok if you've tested that much, it
must be alright'. But I decided to go and have a look at the X sources
and now I'm not so sure, because the varargs routines are a complete
parallel set of interfaces that you may well not be using at all. As far
as I can quickly judge, there are two main places where the X soruces
make an assumption about how varargs are handled - in the macro
XTX_VARARGS (x/src/xt_declare.ph) and the varargs coeercion code in
x/src/xt_call.p - these are then used in various places by the rest of
the code. (a *caseless* grep for 'varargs' picks up most of the stuff
one way or another).
This code assumes that a varags list is terminated by a null on the
stack (ie not passing the number of args, as I had previously suggested).
Roger
--------------090706050506090405020205
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Aaron Sloman wrote:<br>
<blockquote type="cite"
cite="mid200311102256.hAAMuaQi022717@acws-0051.cs.bham.ac.uk">
<blockquote type="cite">
<pre wrap="">This is important because some native pop
code in the Xt interface invokes external C procedures using the varargs
protocol, but possibly not via an actual C wrapper, so it wouldn't have
been caught by a global change to C files. If anyone thinks there's an
issue here, I could try and rediscover whether/where it happens in more
detail.
</pre>
</blockquote>
<pre wrap=""><!---->
Having rebuilt the system using stdargs I've run quite a lot of tests of
X facilities (including XVed and rclib extensions, and some bits of
TEACH propsheet, and it all seems to work). I've used grep to search
for things that might use varargs. but without success.
</pre>
</blockquote>
My first reaction to this was to say 'ok if you've tested that much, it
must be alright'. But I decided to go and have a look at the X sources
and now I'm not so sure, because the varargs routines are a complete
parallel set of interfaces that you may well not be using at all. As
far as I can quickly judge, there are two main places where the X
soruces make an assumption about how varargs are handled - in the macro
XTX_VARARGS (x/src/xt_declare.ph) and the varargs coeercion code in
x/src/xt_call.p - these are then used in various places by the rest of
the code. (a *caseless* grep for 'varargs' picks up most of the stuff
one way or another).<br>
<br>
This code assumes that a varags list is terminated by a null on the
stack (ie not passing the number of args, as I had previously
suggested).<br>
<br>
Roger<br>
<br>
</body>
</html>
--------------090706050506090405020205--
|