Conference turris::decc

Stranger and stranger...

The error was generated on UNIX, and also on VMS where you can find it
documented: error code ARGSIZE.

$ HELP cc/decc messages ARGSIZE

        Message        <Context> the size of "<expression>" exceeds the
                       implementation's limit of 32767 bytes on the size of
                       a function argument.

So there must be somewhere (sometimeS ?) an limit ?!

Mich�le.

Original report in .0 was against old C compiler on UNIX.  Replies indicate
no limit in current UNIX C compiler.  The old C compiler on UNIX had a
particular implementation limit involving the addressing of arguments
passed on the stack that was not in the DEC C compiler on UNIX.

But .4 is a reference to a VMS help file.  Things are different on VMS,
where if nothing else there is an argcount register that has one byte
allocated to hold the number of arguments actually passed to a function.

Some older VMS DEC C compilers complained about large arguments, but
the diagnostic was not accurately based on the actual problem-causing
limitation.  On VAX, it would complain if there were more than 255
arguments, or if a single argument was larger than 32767 bytes.  But
in fact problems would occur on VAX if there were more than 255 arguments
or if the sum of the sizes of all the arguments exceeded 1024 bytes.
The former situation would result in incorrect values of va_count,
the latter would result in the function return incrementing the
stack pointer by the total argument size mod 1024, effectively producing
a memory leak in the program's stack.

Starting with V5.2, the VMS DEC C compilers diagnose the problem more
accurately: both Alpha and VAX produce an informational when the
number of arguments exceeds the calling standard max of 255.  And on
VAX only, an extra warning is given when the total size of all arguments
would cause code to be generated that would leak stack space.

Hi Rich,

Thanks for you explanation, but it doesn't explain everything.

1. On one hand there is a problem with the UNIX old C. It is QARed (#51143) and 
   I still hope to ever get an answer to it.

2. On the other hand, I test the program compilation using the DEC C compiler. 
   This sometimes help. Under OSF V3.2D, the compilation fails with the ARGSIZE 
   error message. Which is only documented in the VMS doc ! I couldn't test the 
   program under VMS: to much includes which doesn't exist.

   Under OSF V4.0, the compilation in DEC C is OK: no error generated.

3. From your answer, I understand that this error should only be reported from
   VAX compilation. How can it be issued by OSF one ?

4. You said �The old C compiler on UNIX had a particular implementation limit 
   involving the addressing of arguments passed on the stack that was not in 
   the DEC C compiler on UNIX.� This seems to be the answer to point 1 but I 
   could find any such information. Is it documented somewhere ?

Thanks in advance,
Mich�le.

> 3. From your answer, I understand that this error should only be reported from
>    VAX compilation. How can it be issued by OSF one ?

Due to an unintentional feature in that version of compiler.

> 4. You said �The old C compiler on UNIX had a particular implementation limit 
>    involving the addressing of arguments passed on the stack that was not in 
>    the DEC C compiler on UNIX.� This seems to be the answer to point 1 but I 
>    could find any such information. Is it documented somewhere ?

Like much information about the detailed behavior of the -oldc compiler,
this is by observation, not by documentation.