RE: API parameter lengths

The underlying question is whether null terminated C strings or C strings
that are simply strings of characters (e.g. OS/400 fixed length character
fields) are one or more parameters in a call, depending on how the string
is manipulated.

Basically, in C, a pointer is a parameter and any kind of string
(terminated by null or some other convention) will end up as a single
parameter (the pointer to it).  This is true of any C program that defines
character string parameters, whether "main" or not, because C has no real
String primative, but rather pointedly defines strings as arrays of
characters.

Likewise, when CL calls a C program, each parameter will end up being
passed "normally" to main except that the C "main" program, by C standard
conventions, expects everything to be a (null terminted) string.  If you
pass a decimal number in a raw call to ILE C, problems can therefore
result.

Every C program in every OS (not just OS/400) has a sort of "secret" bit of
code that gets control just before "main" gets control that does some
expected setup, easing the transition from the raw OS to the enviroment
defined by "main" for C.  Even in Unix systems, there is a little bit of
work that must be done before invoking "main".  In OS/400, IIRC, we do
things like turn the incoming input parameters into null terminated
strings.  Somewhere buried in the C manuals, I would presume the exact
conventions are documented and exactly what happens with various strings
you would input.  This would include whether or not the ILE C program is an
outright CALL xxx or initially invoked as an OS/400 command is involved
(IIRC, the command line process can sometimes clean things up a bit in
terms of fields of fixed length data being passed in shorter lengths).

It's been a while (and I'm jet lagged today) but I've had occassional
little glitches with all of this, especially if the program is invoked with
a direct CL CALL XXX and I am careless about the length of what I pass in.
Though, to be fair, I've had at least as much trouble with this in CL as in
C.  I've found it safest define a command to invoke either CL or ILE C if
there is any question about the size of the string.

However, the following deserves further comment since not everyone on this
list is expert in C:

>C doesn't really care about NULL terminated strings.  Some of its
>functions rely on the fact that an array of characters is terminated with
a
>NULL but there are many other functions that just don't care.  Whether or
>not your printf shows up to the NULL ("%s") or the entire buffer
("%10.10s")
>depends on how you code it.  In Barbara's example there are 2 parameters
and
>how long they are are determined by the calling program not what is
>contained in them.  You shouldn't rely on stuff passed to your C program
>being NULL terminated - unless you wrote the caller.

This is true from a strictly ANSI C point of view.  C as a language does
not care.

HOWEVER, there are literally millions of lines of code and hundreds of
utilities that expect and rely upon null terminated strings.  It is a de
facto standard.  In the C world, de facto standards are often the equal of
formally written ones.  The many string functions in the standard C
libraries have created an expectation, however unofficial, that null
terminated strings are commonplace.  And, this is met in practice in large
degree.

If nothing is said, one can, in fact, normally imply that null terminated
strings are provided in an interface.  Any interface that does not
rely/require this should document this fact unless otherwise obvious.

If memory serves, having fixed, null terminated strings (or not) is even an
option for the special ILE C SQL compilation process.

If we didn't live in an OS/400 world, all of this null termination stuff
would be normal and obvious.

But, we don't.  We have our own world and it has its own rules and ILE C
code must cope with the existing nonC view of the universe we have as well
as with what the rest of the world that codes C expects.

In our world, fixed length character strings not terminated by nulls are an
obvious and well-understood fact of life.  ILE C code that interoperates
with "normal" OS/400 environments (including inter-language calls) must
understand this.  In many cases (e.g. OS/400 System APIs) either a fixed
length or a size-field-plus-maximum-length-field strategy are common.  This
is because many (if not most) OS/400 APIs are language independent and
could not or should not invoke C norms.

By contrast, in the Unix world, variable length, null terminated strings
are the norm.  This predilection is also reflected in the Microsoft world
as well.  Both systems are written in C/C++ and expect to be invoked with C
norms, unlike our OS/400's language independent strategy.  Null terminated
strings will also be reflected in a great variety of APIs that will
eventually make their way into various iSeries products and even, in some
cases, OS/400 interfaces (since they come from the C/Unix world and must
preserve the expected C norms).  If one looks around, several are probably
already in place beyond the normal strcpy ones.

One should therefore examine the underlying context of an API to determine
if null terminated strings are expected or not.



Larry W. Loen  -   Senior Java and iSeries Performance Analyst
                          Dept HP4, Rochester MN


+---
| This is the MI Programmers Mailing List!
| To submit a new message, send your mail to MI400@midrange.com.
| To subscribe to this list send email to MI400-SUB@midrange.com.
| To unsubscribe from this list send email to MI400-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: dr2@cssas400.com
+---