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


  1.  Home
  2. RPG400-L
  3. August 2006

RE: Allocate field with options(*nopass :*omit)



1) I don't think you can do that on a const variable.
You *can* do it on a CONST variable. I don't think you SHOULD, but you CAN.
The problem with CONST is that it's supposed to be "read only". In other words, it's not possible to change it in your procedure. If you can get a pointer to the data, you can change the data -- so it won't let you assign the address of a CONST field to a pointer.
However, It's only the compiler that verifies that you never change a field. It's not checked at runtime. This means that if you can trick the compiler (and, believe me, tricking the compiler isn't hard to do) then you can get the address of a CONST field. (And, if you want to, change it.)
Again, I'm certainly not suggesting that you should do this. Just telling you that it's possible.
I use this technique myself from time to time. I do a fair amount of network programming, and one of the things you need to do in that scenario is convert the data to ASCII or Unicode. So I have procedures that take a CONST field, in EBCDIC, and need to use it as input to the iconv() API.
In order to call iconv(), you need to pass a pointer to the input. That pointer has to be passed by reference, because iconv() will change it. There's no way to pass a CONST field to iconv(). So I solve this problem by tricking the compiler to get a pointer to the field, and then I call iconv() with that pointer. I'm careful not to change the field -- but I could if I wanted to, so technically I'm breaking the rules. 


2) As mentioned before, this method get a bit messy when there are a lot
of parms and you need to use them to pass to another procedure.
It's only a little messier than the alternatives. It's not so bad -- especially if you put it in it's own subprocedure.

As an Amazon Associate we earn from qualifying purchases.

This thread ...
Follow-Ups:
Replies:
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.