× 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: bmorris@xxxxxxxxxx
  • Date: Thu, 28 Sep 2000 16:56:49 -0400
  • Importance: Normal


>Date: Thu, 28 Sep 00 21:04:35 +1000
>From: "Simon Coulter" <shc@flybynight.com.au>
>
>E
> ...
>Maybe I'm looking at this too specifically with regard to printf() but the
compiler
>should simply pass the BYTES.  It knows how many bytes declared variables
occupy so no
>issue there.  Choosing the numeric type is only an issue when the compiler
doesn't know
>the data representation.  The only case I can think of is when literals
are being used.
>With the current prototypes the compiler can cast the literal to the type
defined on the
>prototype.  With what we have been suggesting the compiler would need some
rules for
>handling literals.  Since there is already a precedent for passing numeric
literals as a
>15,5 packed decimal value I think the compiler should stick with that.
>...

R
Simon, what you are suggesting is basically a va_list-type solution.  I
don't think we should go  down that path.  And anyway, it only works for
some datatypes in ILE.  Some parameter types are passed sort of by
reference even when they are passed by value (I say "sort of" because I
don't really understand how it works - we don't generate anything
different, but something different happens).  You can see it at work when
you prototype say "sin" to take an 8A parameter instead of 8F.  An 8A is
passed somehow differently from an 8F, and "sin" doesn't get the parameter
as passed.

Aside from that, I just don't think "loose" parameter passing is a good
idea, nor do I think converting to one of 3 or 4 types is a good idea.  In
general, it would be better to pass what's coded AND have a way to tell the
called function what was passed.  It may be necessary for the system to
have its 32A 15P5 rule, but look at the problems that causes.  Anyway, 15P5
is no good because it doesn't cover 8-byte integers, floating point, or
even the whole range of packed.

There are several better ways to handle varying-type parameters.  Cross
your fingers - maybe something concrete will be on the next enhancement
survey.  (I don't know when it's going to be held.)

Barbara Morris, joining in the new trend to start a post with a single
elegant letter


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