Upgrade query for c business function

avishek

Active Member
Hi all,
We have upgrade our system from XE to 9.1 and apply CodeChangeCom to c business function. However, while building 2 of our business function, we are getting the error 'line 201.59: 1506-019 (S) Expecting an array or a pointer to object type'. We go to the line and change DIM to sizeof. The error disappears.
1. Can you please let me know if the approach is good?
2. Can you also let me know if string length of '1234' is 4 or 8 after using codeChangeCom
 
Several thoughs:


1. CodeChangeCom will NOT get everything. It does a surprisingly good job, but you still need to review all custom C code INCLUDING THE STUFF THAT COMPILES CLEANLY. It WILL miss some things (all jdeCache initialization code should be reviewed for example) and other things it may change incorrectly.

2. You can't blindly change DIM to sizeof just because it compiles. You really need to evaluate each of these individually. Just because you no longer get a compiler error or warning does NOT mean that it is correct. The following compiles just fine but is 100% wrong:

<font class="small">Code:</font><hr /><pre>
JCHAR szBusinessUnit[13]={0}, *pszBusinessUnitPtr=(JCHAR *)NULL;
...
jdeStrncpy(pszBusinessUnitPtr, szBusinessUnit, sizeof(pszBusinessUnitPtr));
</pre><hr />

With regards to your question you will probably need to post the code in question to get a correct answer.

When we did our Xe to 9.0 conversion we converted somewhere in the neighborhood of 250k-300k lines of custom C code if I remember correctly. After a while I had a list of things I checked but basicaly I checked every line that had the DIM macro, I checked every line that had a sizeof key word, I checked every routine that contained "jdeCacheInit..." and quite a few other things that I have since forgotten. I basically had a checklist of things I would check, and when I missed something it got added to my list. It was very slow at first but after about 40 hours I could open up a C BSFN and pretty quickly review it for any obvious errors.
 
String length of "1234" will still be 4 after codeChangeCom.

Use Ctrl + Shift + F in Visual Studio to find lines like this in all your custom business functions quickly.
 
Hi Brian,

Please find the code line which gives error when build:

jdeStrncpy(szDecimal, (const JCHAR *)&lpDS->mnAmountField.String[lpDS->mnAmountField.nLength - lpDS->mnAmountField.nDecimalPosition],DIM(lpDS->mnAmountField.nDecimalPosition - 1));

The error is:
error C2109: subscript requires array or pointer type
error C2198: 'jdeStrncpy' : too few arguments for call
 
[ QUOTE ]

Please find the code line which gives error when build:

jdeStrncpy(szDecimal,
(const JCHAR *)&lpDS->mnAmountField.String[lpDS->mnAmountField.nLength - lpDS->mnAmountField.nDecimalPosition],
DIM(lpDS->mnAmountField.nDecimalPosition - 1));


[/ QUOTE ]


A better question might be what is this line of code trying to accomplish. It's kind of hard to know where to begin. I am curious what the original, Xe version of the code looked like.

It looks like you are either trying to get the integer portion of a number, the fractional portion of the number or possibly both. If that is the case I would STRONGLY suggest re-writng this and using the various MATH_NUMERIC API calls to get the number(s) or info that you need and then, if you still need the result as a string, formatting the MATH_NUMERIC API result(s) as a string(s). Working directly with the MATH_NUMERIC struct members in the manor shown above is usually a recipe for disaster. In fact the "String" member of MATH_NUMERIC is NOT unicode, so your use of unicode API is going to fail anyway. Even if I could get your statement above to compile, or even close to syntatically correct it is still probably not going to work.


From a simple compilation standpoint it wont compile because of how you are using the DIM macro. DIM expands to the following:

#define DIM(x) (sizeof(x)/sizeof(x[0]))

The DIM macro works on a fixed array of any data type (it can't be used on a pointer). As used in the line of code above... it's really not even close. When used in the context of a string function like jdeStrncpy it is usually used on the destination string (which is just a JCHAR array) as in:

<font class="small">Code:</font><hr /><pre>
jdeStrncpy(szDest, szSrc, DIM(szDest)-1);
</pre><hr />

This useage really just prevents buffer overruns. If you truly want to copy just a portion of szSrc you probably wouldn't be using the DIM macro but instead the number of characters from szSrc you want to copy.

So in your code above DIM is
(1) not being used on an array.
(2) the "-1" should not be part of the parameter expression passed to DIM... you probably wanted it on the outside, which is a moot point because of of point(1).
(3) jdeStrncpy is a unicode call, lpDS->mnAmountField.String is NOT a unicode string.


Again, if you get this line of code to compile I am almost 100% certain that it is still wrong.
 
Back
Top