× 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 Wednesday, March 3, 2004, at 02:29 AM, James H. H. Lampert wrote:


Yes, and since it makes no allowances for the way C handles character
strings (which, I freely admit, is more than a little bit meschuga, but
PL/I would be my language of choice), you try to look at a character
string variable, and you've got to go through all sorts of rigmarole to
do it.

PL/1 is my choice too.


While I'm not defending the the ILE debugger it is much easier to use once you realise that it tries to behave like the underlying language therefore it does make allowances for C's admittedly crappy idea of strings.

Since C has no concept of character variables (if you discount the stupid idea that a char is numeric data type) and uses null-terminated arrays to represent them, and that in C arrays and pointers are the same thing (another stupid idea), then the debugger's contortions are understandable.

To reference the contents of a characters string in C you must either use array subscripting or pointer de-referencing. Thus:
EVAL *string
in the debugger will do exactly what *string does in C, that is de-reference the pointer and access the first character. So too,
EVAL *string:s
will treat the stuff pointed to by string as a null-terminated string (because of the :s) and show all characters up to the first null (x'00). This behaviour seems to be what a C programmer would expect.


Since it is common for programmers to make errors the debugger will only show the first 30 bytes of a C-style string--in case there isn't a null. You wouldn't want the debugger to attempt to dump all storage from the pointer address in the hope that a null might appear would you? Thus:
EVAL *string:s 100
will show the all characters up to the first null, or the first 100 bytes of whatever string points to if a null is not encountered, in character form.
EVAL *string:x 100 will show the first 100 bytes regardless of any nulls in hexadecimal output.


There is also the :f form which will display formatted strings by evaluating embedded directives like \n.

Using the affinity between pointers and arrays allows you to also do things like:
EVAL string[0]
which is equivalent to
EVAL *string
or
EVAL string[10]
which is equivalent to
EVAL *(string+10)
Again this seems to be what a C programmer would expect.


The one missing thing is displaying array ranges. In non-C source you can do:
EVAL array(10..20)
to display the array elements 10 to 20 inclusive. I haven't found any way to do the same in the ILE debugger. EVAL array[10.20] results in "Syntax error occurred".


Regards,
Simon Coulter.
---------------------------------------------------------------------
Arterial Software
IBM Tower
Level 3, 60 City Road
Southgate Victoria 3006
Australia
http://www.arterialsoftware.com
+61 3 9421 5911 (Phone)
+61 3 9428 3729 (Fax)
---------------------------------------------------------------------
This message together with any attachment is intended for the use of
the person to whom it is addressed and contains information that is
privileged and confidential.  If you are not the intended recipient,
or the employee or agent responsible for its delivery to the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of it is strictly prohibited. Please notify us if you have
received it in error, and otherwise take all necessary steps to delete
it from any transient or permanent storage device or medium and notify
us by e-mail at "support@xxxxxxxxxxxxxxxxxxxx".

Any views expressed in this e-mail and any files transmitted with it
are those of the individual sender, except where the sender
specifically states them to be the views of Arterial Software.

Arterial Software does not represent or warrant that the attached files
are free from computer viruses or other defects. The user assumes all
responsibility for any loss or damage resulting directly or indirectly
from the use of any attached files.
----------------------------------------------------------------------



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2023 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.