[M3devel] Fwd: Re: Rd.GetText Question

Rodney M. Bates rodney_bates at lcwb.coop
Sat Jul 16 13:46:28 CEST 2011


Sorry for the delay.  I sent this several days ago, but it disappeared into email space
with neither  a bounce nor showing up in the mailing list.  I have had this problem
intermittently.



On 07/08/2011 09:44 PM, Ken Durocher wrote:
> The Rd interface defines GetText as GetText(rd: T; len: CARDINAL): TEXT;
>
> I've noticed in different values for len in different places.  Some use Rd.Length(rd) while others use LAST(CARDINAL).
>
> The latter would limit the text to about 2GB on a 32bit system, correct?

Yes.  AFAIK, all implementations of Text use variables of type CARDINAL or INTEGER
internally for lengths of TEXT values, so the 2GB length limit exists anyway on a
32-bit machine, in lots of places besides just Rd.GetText.

> But does Rd.Length() always know what the length will be?
>
> The interface for Rd states this for Rd.Length():
> "If len(rd) is unknown to the implementation of an intermittent reader, Length(rd) returns -1."
>
> So my question is, which should I use? Another option would be reading in some arbitrary amount and
> then looping until EOF. Which method is best?
>

For a robust program, not just a quick throwaway, I would say you should always test the
result of Rd.Length for -1 before passing it to Rd.GetText, unless you know your reader
is non-intermittent and -1 can't happen.  Perhaps this is the case in the examples you see
that pass it directly to Rd.GetText.  Or not.

As long as you don't hit the 2GB limit, using LAST(CARDINAL) would always work and be a lot
simpler than writing a loop.  If you want handle > 2GB on 32-bit machines, the loop will have
to handle the pieces some other way than just concatenating them, no doubt a lot more complicated.
But LAST(CARDINAL) would still work.

> Thanks.

Rodney Bates





More information about the M3devel mailing list