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



From: Barbara Morris

Joe Pluta wrote:

... But to be thorough, there is still the issue that large fields will
NOT
work with a hardcoded "2". If the field is ever changed to be longer
than
64K, then code that uses "2" will break.


True, but that would be the case no matter how the VARYING > 65535 was
handled.

Agreed. Just another reason why in my opinion hardcoding the "2" (or
messing around with the internals at all) is a bad idea. I consider the
whole idea of %addr(VaryingField)+2 to be dodgy at best, just for this
reason. It's a fragile technique, and isolating it as much as possible is a
good idea (to the point of using a named constant rather than "2").


The programmer who changes the length over the 65535 mark and
gets an immediate syntax checker or compiler diagnostic about VARYING(4)
being required has a better (imo) chance of spotting this problem when
they do their impact analysis. If the compiler silently defaulted to
VARYING(4), the programmer might be less aware of the extra impact
analysis required due to the change in both the length and the prefix
length.

But that goes back to the point of making a decision that favors the tiny
minority of people who code "%addr(VaryingField)+2" over the vast majority
who use VARYING fields without ever taking their address.

The whole issue came about because of a few programmers who, rather than
moving the data into a fixed length buffer and passing the address of that,
chose to fiddle with the internals and use the %addr()+2 technique. It's
understandable, I guess, from a performance standpoint, but that's their
choice and shouldn't affect all the other programmers who never use %addr in
their entire career.

I still think VARYING is VARYING regardless of the size of the field, and as
a programmer most of the time I shouldn't care what the size of the prefix
is, any more than I should have to care whether the system uses a hex C or a
hex F in the last nibble of a positive packed decimal number. The compiler
should handle it without me having to tell it anything. And for those rare
cases where I do care about the length of the prefix, then I should use a
BIF to get it.

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.