|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.