markl@vecpyr.UUCP (Mark Patrick) (05/10/86)
Is the following program portable to any machine which provides a
(reasonable) implementation of C.
#include <varargs.h>
fred(ap)
va_list ap ;
{
int i ;
for ( i=0; i < 52 ; i++ ) {
if ( (i%2) == 0 )
printf("%d\n",va_arg(ap, int)) ;
else printf("%f\n", va_arg(ap, double)) ;
}
}
joe(va_alist)
va_dcl
{
va_list ap ;
va_start(ap) ;
fred(ap) ;
va_end(ap) ;
}
main()
{
joe( 1,2.5,3,4.5,5,6.5,7,8.5,9,10.5,11,12.5,13,14.5,15, 16.5, 17,
18.5, 19,20.5,21,22.5,23,24.5,25,26.5,27,28.5,29,30.5,31,32.5,33,34.5,35,36.5,
37,38.5,39,40.5,41,42.5,43,44.5,45,46.5,47,48.5,49,50.5,51,52.5) ;
}
--
Mark Patrick
...{lll-crg, amd, dual}!vecpyr!markl
Visual Engineering Corp, San Jose, CAgwyn@brl-smoke.ARPA (Doug Gwyn ) (05/15/86)
In article <279@vecpyr.UUCP> markl@vecpyr.UUCP (Mark Patrick) writes: >Is the following program portable to any machine which provides a >(reasonable) implementation of C. > ... > joe( 1,2.5,3,4.5,5,6.5,7,8.5,9,10.5,11,12.5,13,14.5,15, 16.5, 17, >18.5, 19,20.5,21,22.5,23,24.5,25,26.5,27,28.5,29,30.5,31,32.5,33,34.5,35,36.5, >37,38.5,39,40.5,41,42.5,43,44.5,45,46.5,47,48.5,49,50.5,51,52.5) ; No, because you have exceeded the VAX's 255-byte argument limit.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/16/86)
> No, because you have exceeded the VAX's 255-byte argument limit.
Oops, the VAX allows 255 longwords, not 255 bytes. Sorry!
However, this is a problem to watch out for, if you pass
structs by value.ark@alice.UucP (Andrew Koenig) (05/23/86)
>>Is the following program portable to any machine which provides a >>(reasonable) implementation of C. >> ... >> joe( 1,2.5,3,4.5,5,6.5,7,8.5,9,10.5,11,12.5,13,14.5,15, 16.5, 17, >>18.5, 19,20.5,21,22.5,23,24.5,25,26.5,27,28.5,29,30.5,31,32.5,33,34.5,35,36.5, >>37,38.5,39,40.5,41,42.5,43,44.5,45,46.5,47,48.5,49,50.5,51,52.5) ; > >No, because you have exceeded the VAX's 255-byte argument limit. Putting it another way: some compilers may be broken. It is the compiler's job to shield users from silly restrictions in the hardware. Of course, some compilers fall down on the job.
g-rh@cca.UUCP (Richard Harter) (05/25/86)
In article <> ark@alice.UucP (Andrew Koenig) writes: >>>Is the following program portable to any machine which provides a >>>(reasonable) implementation of C. >>> ... >>> joe( 1,2.5,3,4.5,5,6.5,7,8.5,9,10.5,11,12.5,13,14.5,15, 16.5, 17, >>>18.5, 19,20.5,21,22.5,23,24.5,25,26.5,27,28.5,29,30.5,31,32.5,33,34.5,35,36.5, >>>37,38.5,39,40.5,41,42.5,43,44.5,45,46.5,47,48.5,49,50.5,51,52.5) ; >> >>No, because you have exceeded the VAX's 255-byte argument limit. > >Putting it another way: some compilers may be broken. > >It is the compiler's job to shield users from silly restrictions >in the hardware. Of course, some compilers fall down on the job. This is, of course, not a hardware restriction but instead is a software implementation restriction. More importantly, by this kind of reasoning, almost every C compiler and almost every implementation of Unix is "broken". Any time you code system software with hard table sizes you are creating "broken" software which fails in one way or another when the table size limits (all too often hidden from the user) are exceeded. Richard Harter, SMDS Inc.
ark@alice.UucP (Andrew Koenig) (06/02/86)
> This is, of course, not a hardware restriction but instead is a > software implementation restriction. Yes and no. Most C compilers on the VAX use the built-in subroutine instructions for C subroutines. These instructions limit the argument list to 255 words. That is indeed a hardware limitation. Now, you may wish to consider it as an implementation restriction that the compiler does not use some other method of dealing with big argument lists. Indeed, you may be right. My original point, though, was that the problem arose because of a hardware restriction.
chris@umcp-cs.UUCP (Chris Torek) (06/03/86)
In article <5576@alice.uUCp>, ark@alice.UucP (Andrew Koenig) writes: >... Most C compilers on the VAX use the built-in subroutine >instructions for C subroutines. These instructions limit the argument >list to 255 words. If you refer to the fact that the `ret' instruction will pop at most 1023 bytes from the stack, well, gawsh, Robert Elz and someone whose initials are `wah' had that fixed a long time ago (4.1BSD?) . . . . It is not hard to work around: just generate an `extra' `addl2' after a subroutine call that pushes that much data. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu