That's an excellent answer Bernd! One of the reasons why I prefer C++
over C is that iostreams are not only typesafe but they handle variable
length parameter lists by simple function calls. The downside is that
the extra function call overhead is more expensive so it's a trade-off.
It's also significantly more verbose than a simple printf() but there
are decent alternatives
http://www.boost.org/doc/libs/1_60_0/libs/format/doc/format.html.
Just for fun http://www.horstmann.com/.
On 29/04/2016 8:42 PM, Bernd Oppolzer wrote:
There is no defined standard for marking the end of a variable
length parameter (address) list in C. The header <stdard.h>
includes functions that allow for variable number of parameters,
but then you have to have a first parameter (or first set of parameters)
that allows you to determine the number of parameters in the actual call,
for example printf - by parsing the first parameter you know the number
of parameters of the actual printf call
more simple:
void varfunc (int count, ...);
so there is no need to mark the last address or to put an
end-of-adresslist-marker behind the last address.
This is a sort of flaw of the C language definition, but on the other
hand,
it is not possible to add it, because parameters in C can be values,
not only
addresses, so you can have negative int by value parameters, which have
the first bit set (problem in the 31-bit case) or long ints with value -1
(problem with the solution suggested by Ed Jaffe).
By the way: in the moment when PL/1 allowed BYVALUE declarations for
parameters,
we introduced the same problem there.
That said:
BYVALUE parameters and marking the end of parameter address lists
don't go together. We must probably accept that the VL-bit is
(Fortran) history
and should not be used any more.
Some history of my own: I wrote an interface from PASCAL/VS to GDDM in
the 80s,
and the problem then was, that PASCAL/VS didn't set the VL-bit, but
GDDM needed
VL-bits on every call, because it used them to check for the correct
count of parameters.
So I had to insert an ASSEMBLER interface for every GDDM routine that
added the
VL-bit at the correct place. There you have the Fortran problem
(Pascal supported
BYVALUE, too; Fortran was the "normal" caller for GDDM). Same goes for
C and
today's PL/1.
Kind regards
Bernd
Am 29.04.2016 um 14:16 schrieb Rick Troth:
What I'm curious about is: _what does XLC do?_
-- R; <><
On 04/28/16 19:15, Charles Mills wrote:
As a C/C++ convert, I like 0_0 (NULL in C lingo) better than
FFFFFFFF_FFFFFFFF (only because it is a widely-used convention in
C). (OTOH FFF... is widely-used in CMS.)
Agree with Gil's "collateral boon."
IBM should definitely standardize *something*, before we have 27
competing "standards" out there.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List
[mailto:[email protected]] On Behalf Of Paul Gilmartin
Sent: Thursday, April 28, 2016 3:41 PM
To: [email protected]
Subject: Re: 64-bit caller and VL-bit
On Thu, 28 Apr 2016 14:23:14 -0700, Ed Jaffe wrote:
On 4/27/2016 8:25 PM, Phil Smith III wrote:
How does a 64-bit caller indicate the end of a variable parameter
list?
We tend to use FFFFFFFF_FFFFFFFF as the end of list indicator. Yes, I
realize it's _technically_ a valid 64-bit address, but it's extremely
unlikely -- nee impossible -- that we would ever want to place a valid
parameter at that particular byte location in virtual storage. And,
who
knows, maybe one day the z/OS guys will decide to make that last
(1M or
2G) page guaranteed invalid like they do with the 4K page at
7FFFF000...
This has the collateral boon that you can code an empty 64-bit
parameter list, something not possible with a 24-bit or 31-bit
parameter list.
But IBM should formalize the convention.
I believe it's part of the "C" standard that it should always be
possible to terminate a loop by testing for an address greater than
that of any possible physical object in storage.
And the UNIX argv[] vector is terminated by a NULL (0) pointer, not -1.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
