×
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.
On 25/07/2008, at 12:32 AM, Lim Hock-Chai wrote:
Uuumm, may be the CL is the problem. I call the C program straight
from
command line and it works fine (no junk in stdout).
Which is exactly what I told you. As Scott pointed out in a more
verbose fashion: character literals are automatically null-terminated
by the CALL command (even if run from within a CL program--which I
admit I did not know but then I think I've never passed character
literals into a C program from a CL program) but when you pass
variables on the CALL **YOU** are responsible for ensuring
appropriate null-termination.
I guess the debugger lie to me.
No, it doesn't.
When I call the C program thru the CL program and do below in debugger
eval *argv[1] :s
it shows me
*argv[1] :s = "NOCC07QA "
I though :s tells debugger that the pointer is a null terminator
string.
How can debugger show correct data if there is no terminator on
position
30 of argv[1]?
The debugger defaults to showing only the first 30 bytes of string
data unless a null-terminator is encountered before that limit. It
does this for the very reason you have discovered: that if a
developer fails to correctly null-terminate a string the debugger
will not try to dump all of main storage (or maybe *only* 16MB). The
help text in the debugger under C/C++ string examples explains this.
It's probably in other documentation too but I can't be bothered
looking for it.
Next time you debug and have failed to properly null-terminate run:
EVAL *argc[1]:s 300
and see what happens.
Why did you see blanks after NOCC07QA instead of junk? Recall what
the CALL command does with character values and the magic limit of 32.
Doesn't really matter WHY. The problem is you failed to null-
terminate the input strings for C.
Anyway, I change the CL to be as below and it appears to correct the
problem.
That is the correct approach and it is shown in the examples in the C/
C++ Programmer's Guide in the sections discussing inter-program calls.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
