Re: null termination

From: Tim Smith <tssmith_at_netcom.com>
Date: Mon, 3 Oct 1994 00:12:50 GMT
Message-ID: <tssmithCx2LxE.GL_at_netcom.com>


bmay_at_novalink.com (Brett M May) writes:
>I've seen this talked about in the FAQ, but it it a little ambiguous, so
>I am repeating the following questions:

Well, it sure as hell is confusing. Most of the reason for this seems to me to be how Oracle tried to guess what the ANSI/ISO people would do in SQL92. Ken Jacobs, Merrill Holt, or Phil Shaw can provide the informed opinion on this.

All I can say, as a user/documenter, is this:

If you want backward compatibility with earlier versions of Pro*C (1.3, 1.4, 1.5, 1.6), or other Oracle precompilers, use VARCHARs. This (not very C-like) pseudotype lets you deal with strings up to 65K bytes in a Pascal-like way.

If you want to work in a C (or C++)-like way you have two options:

(1) for static allocation, use char x[n]s as host variables. The [n] lets the Oracle server know the length [n] and the datatype (charz == 97) of the host variable. What you get in that case is a type 97 thingie (blank-paddded up to n-1 bytes), with null-termination on n output (but blank-padding still, per ISO standards) on output.

(2) for dynamic allocation (e.g. char *'s), you have a problem on input, since you have tell the precompiler/server how many bytes you are sending. The precompiler determines this by doing an strlen() on input on your (possiblly malloc'ed()d) string, so make sure that this is set up OK. (Remember that strings are often set up the linker/loader as filled by '\0's).;

I'm in the process of rewriting the Pro*C (R2.1) manual to incorporate this stuff. So if you have questioms/issues/comments please make sure to email them to tssmith_at_oracle.com. Flames on the earlier versions are OK, but we did the very best job we could.

--Tim (tssmith_at_oracle.com) Received on Mon Oct 03 1994 - 01:12:50 CET

Original text of this message