RE: Prototyping printf()

["Richard Jackson" <richardjackson@xxxxxxxxxxxxxxxxxx>]

Joel:

The issue is more like "strong vs weak typing".  RPG is strongly typed.  C
is weakly typed.  C++ is strongly typed ... is there a way to perform printf
in C++ that is analogous to what Simon wants to do in RPG?

Jon:

I don't think that this requires op codes if - and that is a very big "if" -
Barbara and her team can add a requirement into the program creation process
and program objects.

I am not confident that I understand the component names for everything that
happens during a compile so, for the sake of argument, I will call the
entire thing "the compiler" even though I know that it isn't.  I'll let the
people who own this code mentally assign the work to the right people.

The compiler (there it is!) could perform a static check for types and
lengths.

If the current program object definition doesn't include a
language-independent specification for the number, type, length, and decimal
positions for input parameters, it should be changed to include this data.
If this information is stored into the program or module objects, then the
compiler can statically validate parameters.

Exceptional situation -- the program or module is called via pointer or
dynamically using a variable-named program.  In this case, a compiler switch
could turn on or turn off dynamic parameter checking.

Ugly situation -- the programs may have different type semantics.  For
example, a C string isn't the same as an RPG character variable.  I see a
couple of choices here and one huge, very cool, opportunity.  Everyone can
see the choices but I want to describe the opportunity.  Suppose that
particular situations could trigger specific data conversions.  For example,
suppose that a rule exists that says, "if calling from RPG to C, make sure
that C gets a pointer to a null-terminated array of characters of length
either length(variable) or trim(variable)" then make it happen.  If the RPG
input string doesn't contain a null, copy the string and stick the null on
the end.

The rules would be defined in the ILE environment, not in each language.
The rule triggers at the static or dynamic check.  The rule may be
deactivated if the programmer knows (or thinks they know) what they are
doing.   The rules are an externally visible attribute of each module or
program and can be extracted using an API query.

I am confident that this suggestion contains countless flaws (like, "what
about prototypes?") but I am equally confident that until something like
this is put into place, we will continue to have program failures created by
parameter mismatch and by inconsistent type definitions.

This outta be good for a swarm of hate mail!

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Joel Fritz
Sent: Monday, September 25, 2000 9:57 AM
To: 'RPG400-L@midrange.com'
Subject: RE: Prototyping printf()


I may be missing something, but I think it hinges on the conveniently(?)
ambiguous way strings work in C  and printf()'s being a function with a
variable argument list.  Even though strings are pointers in C, there are
situations, like printf(), where you can use them like the numeric data
types.

I would be surprised and gratified if there were a way to do it, but I think
you've hit on something where there is no common ground between the two
languagages.

BTW, how are you using printf() in RPG?  Is it CGI?

> -----Original Message-----
> From: Simon Coulter [mailto:shc@flybynight.com.au]
> Sent: Saturday, September 23, 2000 5:46 PM
> To: RPG400-L@midrange.com
> Subject: Prototyping printf()
>
>
>
> Hello all,
>
> Now here's an interesting exercise that is rapidly becoming
> one of futility.
>
> printf() is a C function that expects a format string
> followed by zero or more
> substitution values.  The substitution arguments can be any
> of C's supported data types
> and are passed by value.  Prototypng it for known data types
> is easy but the real point
> is to create a single definition that can handle all data
> types.  A sample prototype of
> the form:
>
> D printf      PR                      10I 0  EXTPROC('printf')
> D  formatString                                 *    VALUE
> OPTIONS(*STRING)
> D  arg1                                       10I 0  VALUE
> OPTIONS(*NOPASS)
>
> will allow dynamic printing like:
>
> C             EVAL    rc=printf('The number is %i ' : anInt)
>
> however if I then want to print a string I need a separate
> prototype with arg1 defined
> appropriately.
>
> D printf      PR                      10I 0  EXTPROC('printf')
> D  formatString                                 *    VALUE
> OPTIONS(*STRING)
> D  arg1                                         *    VALUE
> OPTIONS(*STRING:*NOPASS)
>
> and then I can:
>
> C             EVAL    rc=printf('The string is %s ' : aString)
>
> and so we go on with additional prototypes for each possible
> variation of substitution
> arguments.
>
> My question (to which I think the answer is NO) is:  Is it
> possible to define an RPG
> prototype describing printf() in its native form?
>
> The difficulty seems to hinge on C's requirement for passing
> by VALUE and RPGs
> requirement for knowing the data type up front.  The closest
> I can come to allowing RPG
> to accept anything is by using a prototype like:
>
> D printf      PR                      10I 0  EXTPROC('printf')
> D  formatString                                 *    VALUE
> OPTIONS(*STRING)
> D  arg1                                         *    VALUE
> OPTIONS(*NOPASS)
> D  arg2                                         *    VALUE
> OPTIONS(*NOPASS)
> D  arg3                                         *    VALUE
> OPTIONS(*NOPASS)
> D  arg4                                         *    VALUE
> OPTIONS(*NOPASS)
>
> which allows RPG to successfully compile statements such as:
>
> C             for     count = 0 to 10 by 2
> C             EVAL    rc=printf('%s %i' : %addr(string) :
> %addr(count) )
> C             endfor
>
> When it runs the string is printed successfully but the
> integer is not because it is the
> VALUE of the ADDRESS of the integer that is being passed not
> the VALUE of the integer.
> And that leads us back to a prototype like:
>
> D printf      PR                      10I 0  EXTPROC('printf')
> D  formatString                                 *    VALUE
> OPTIONS(*STRING)
> D  arg1                                         *    VALUE
> OPTIONS(*STRING:*NOPASS)
> D  arg2                                       10I 0  VALUE
> OPTIONS(*NOPASS)
>
> Aaaarrrrrggghhhh!!!!
>
> Regards,
> Simon Coulter.
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---