× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Prototyping printf()
  • From: "Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>
  • Date: Tue, 26 Sep 00 12:42:02 +1000


Hello Jon,

You wrote:
>In part this is what I meant by the comment about descriptor support. This
>is exactly the use to which it would be put. The descriptors are supposed
>to be the glue that allows complete inter language parameter passing
>flexibility but .....  trouble is Rochester still haven't seen fit to even
>giving us a halfway decent subset of the standard data types.  I could live
>with a set that only supported limited numeric types for example, but
>there's still no sign of them doing anything.

Since that would be useful to IBM sites as well as to customers what is the 
problem.  Why 
won't they fund it?  Do they seriously think all AS/400 code will move to Java 
and 
therefore there is no need to provide machine support for non-Java stuff?

>Even with full descriptor support, I might still want to see some op-code
>support.  Look at the situation in printf.  It is the _content_ of the
>format parameter that determines how many and what size, and shape the
>subsequent parameters are.  The called routine doesn't know what it will
>receive and therefore the compiler can't anticipate it.  The parms (in an
>RPG context) have to be unloaded into specific variables of the correct
>type/size.  The compiler generated code could - using the descriptors if
>they existed - unload the parms into temp storage and pass a list of
>pointers together with size/type.  In the end though, my code would have to
>dereference it anyway so an RPG "pop" op-code seemed to be a reasonable
>approach even if not strictly required.

The C compiler does nothing to verify variable argument lists.  It does not 
analyse the 
format string to check types or even that the number of supplied arguments 
matches the 
substituiton parameters in the format string.  The following is a legal C 
program which 
will compile but fails at run time.  The type of failure will vary according to 
memory 
contents at run-time.

#include <stdio.h>
int main (void)
{
        char aChar = 41 ;
        int anInt = 12;
        char * aString = "Hello World!";
        double aDouble = 1234;
        printf("This should break %c %s %i %f\n", aChar, aString, anInt);
        printf("This will work %c %s %i %f\n", aChar, aString, anInt, aDouble);
        printf("This might break %s %i %f\n", aDouble, aString, anInt);
}

All the compiler does is build an argument list that reflects the declared 
types of the 
variables and hopes the programmer got it right.  I see no reason why the RPG 
compiler 
couldn't do the same -- since that is much like the behaviour of unprototyped 
dynamic 
calls.

>The compiler folks have given us some wonderful C interface capabilities
>with Options(*String) and %Str but I fear they can't do it all alone.

I think this particular problem (varying argument list) could be handled 
entirely by the 
compiler -- but then I've only been thinking about it for 20 minutes ....

>Perhaps the decision not to enhance descriptor support was made by the same
>Rochester development manager who thinks we all code in C and C++ and
>therefore only need manual examples in those languages!

Is that the same weenie who is sleeping with you-know-who from Redmond and 
signing all 
those agreements to the effect that if Rochester want early-release windoze 
code they 
have to promise not to support OS/2?   (I quote: " There are technical and 
business 
reasons OS/2 is not supported by NetServer"  -- Yeah, and my bum's a red 
cabbage!)

Actually it is probably because of Rochester's receipt of early windoze code 
that they 
are so enamoured of it.  By the time it gets released to the public it is so 
much better 
than the crap they've had to work with they actually think its good!

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:
 +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
+---
| 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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.