|
On 22-Aug-2016 12:35 -0700, Vernon Hamberg wrote:
Back to a possible solution - and I know there will be issues with
this - I'd offered the idea of using pointers to the values to be
compared - here is some code for a min() procedure and tests that
include 2 packed values and 2 character values.
The result is meaningless if data types don't match (other than
zoned and character, maybe), since it is a hexadecimal comparison.
Basically, all data types should be the same.
More appropriately than "should be", I would suggest, is that the data-type and [notably length\scale] attributes *must* be _identical_ for the two arguments. Otherwise, there is no way to ensure the effective accuracy ["effective", per being a binary vs typed compare] for the less-than-or-equal predicate. For anything other than identically defined arguments coded, an example showing incorrect\garbage output, surely could be contrived; e.g.:
• a packed(5:0) inz(2333) as an argument could be shown to be the MIN() when a packed(5:2) inz(111.22) is the other argument
• a char(7) inz('thisone') as an argument could be shown to be the MIN() when a char(4) inz('this') is the other argument -- this is a less conspicuous effect, born of the possibility for the underlying storage used for the char(256) based-storage, containing anything greater than 'one' [0x969585] after the fourth byte.
<<SNIPped code exampleusing 256 bytes of essentially random
based-storage that is prefixed by some unknown [to the invoked
procedure] amount of data that should be compared as /image/>>
If one were to accept a binary-data comparison, then at least there should be a requirement to compare only the relevant length of the data; minimally, either the length+scale must be passed as additional information, or the routine [coder] and invoker must be satisfied that there is an implied _assumption_ that the invoker will only ever be passing argument-values of the identical type and attributes.
As an Amazon Associate we earn from qualifying purchases.
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.