Re: RNF7535: varchar not compatible with options(*varsize)?

1) A temp of the full length will be created - so effectively the full length is copied (probably just the data and then blank padding but ...).

2) No - a copy is always passed if the base data type doesn't match. The "correct" proto in this instance is either Char(x) or Pointer by Value. Changing the proto to Varchar does not affect what the called routine expects - it just allows the wrong type (VarChar) to be passed without (apparent) error - but the called routine still expects a straight character string without the leading count.

3) Wrong - if _you_ were writing the routine and chose to use VarChar no separate length would be needed - but you can't arbitrarily change the rules as to what an IBM routines expects.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Mar 30, 2018, at 11:14 AM, mlazarus <mlazarus@xxxxxxxxxxxx> wrote:

Jon,

1) If the field is Varying, contents are 12 long, and Const is used does the entire length get copied or just the 12 (+2 for the length) ?

2) In this case, since there is no expression being passed, wouldn't it just pass the pointer to the original variable and not make a copy? I know it's not guranteed, since the compiler can choose what it wants to do for Const, but I'm curious if that would be true here.

3) Dan - since DataToHash is Varying, there is no need for the second parm at all, since the Varying variable already contains the length, which is passed to your procedure.

-mark

On 3/30/2018 10:45 AM, Jon Paris wrote:

I'm just starting my day and not really awake but ... it seems to me this is not a valid approach Dan.

By doing this you are including the two byte binary length of the varchar in the string to be hashed. So if you compared the hash value of (say) 'ABC' with the hashed value of 'ABC' made on another platform (or in the IBM i by a different piece of code) they will not match because including the count would not be normal practice.

Perhaps even more importantly you are not passing the correct length unless you are adding 2 to the %Len of the varchar. As a result the hash of '123' would be the same as the hash of '199' because what you are actually hashing by using a length of three is X'0003F1' whereas you should be hashing X'F1F2F3' and X'F1F9F9'.

To use a varchar with this API probably the best approach is probably to change the proto to use a pointer passed by value for the hash string and then pass %Addr(varchar: *Data).

As I say it is early in the day and I haven't tested this so ....

P.S. I would not recommend using Const to fix this as it will cause a copy of the data to be made and with such a large variable that will be slow if a lot of calls are made.


Jon Paris

www.partner400.com
www.SystemiDeveloper.com

On Mar 30, 2018, at 1:28 AM, Dan<dan27649@xxxxxxxxx> wrote:

Thanks Mark!

I changed the first parm in the prototype to varchar and now it works like
a charm.

On the inputlen statement, I simply got rid of the %trim altogether, since
DateToHash is varchar.

- Dan


On Fri, Mar 30, 2018 at 12:56 AM, mlazarus<mlazarus@xxxxxxxxxxxx> wrote:

Dan,

You're passing a varying character field to a fixed length parm, as
defined in the prototype. Options(*varsize) allows you to pass differently
sized variables of the same type, in this case it would be a fixed length
field, without the compiler complaining. An easy fix would be to add Const
to the prototype. Then the compiler would adjust it for you. Or make the
parm in the prototype varying (varchar).

Just a note on the other part of the code. This statement:

inputlen = %len(%trim( DataToHash));

gets the length of the fully trimmed variable, yet you're passing an
untrimmed version:

hash( DataToHash: inputlen );

So if you have leading blanks you'll get the hash based on a value with
leading blanks, but ignoring the trailing characters, for the number of
leading blanks. You're probably looking for %TrimR() instead of %Trim().

-mark

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link: http://amzn.to/2dEadiD