|
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.