|
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 mailing list archive is Copyright 1997-2025 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.