Pro*C 2.0 "char" bug

We've noticed an erroneous behavior with Pro*C 2.0 that doesn't seem to be present in versions 1.6 or 2.2. In version 2.0, if a CHAR(1) database column is SELECTed into a "plain old char" variable that's not an array (e.g. char one_char_var;), no error occurs, but the variable's contents ARE NOT REPLACED with what was (supposedly) pulled from the database! In version 1.6 and 2.2 things seem to work as expected; the character from the database ends up in the variable in the C program.

To demonstrate the symptoms, I wrote a trivial Pro*C program that selects a CHAR(1) column value into various kinds of host variables. Each of the variables is initialized and displayed before the SELECT and then displayed afterwards.

$ cat char.pc

	#include        <stdio.h>
	EXEC SQL BEGIN DECLARE SECTION;
	
	        char    uid[2] = "/";
	        EXEC SQL VAR uid IS STRING;
	
	        char    plain_old_char  = 'Z';
	
	        char    char_string[2]  = "S";
	        EXEC SQL VAR char_string IS STRING;
	
	        char    charf_char      = 'F';
	        EXEC SQL VAR charf_char IS CHARF;
	
	EXEC SQL END DECLARE SECTION;
	
	EXEC SQL INCLUDE SQLCA;
	
	main()
	{
	        EXEC SQL connect :uid;
	
	        printf( "Before: plain_old_char='%c'\n", plain_old_char );
	        printf( "Before: char_string=[%s]\n", char_string );
	        printf( "Before: charf_char='%c'\n", charf_char );
	        EXEC SQL
	                SELECT
	                        dummy,
	                        dummy,
	                        dummy
	                INTO
	                        :plain_old_char,
	                        :char_string,
	                        :charf_char
	                FROM
	                        dual
	                ;
	        printf( "sqlca.sqlcode=(%d)\n", sqlca.sqlcode );
	        printf( "After: plain_old_char='%c'\n", plain_old_char );
	        printf( "After: char_string=[%s]\n", char_string );
	        printf( "After: charf_char='%c'\n", charf_char );
	}

To hopefully exclude anything we're doing to screw things up, I compiled this program using ORACLE's demo makefile instead of our application-specific compile procedures. I've shown my results below.

Pro*C 1.6 (7.1.4) Compile command line and program output:

$ make -f $ORACLE_HOME/proc16/demo/proc16.mk char
$ mv char char.16
$ char.16

	Before: plain_old_char='Z'
	Before: char_string=[S]
	Before: charf_char='F'
	sqlca.sqlcode=(0)
	After: plain_old_char='X' <--This is what I expected!
	After: char_string=[X]
	After: charf_char='X'

Pro*C 2.0 (7.1.4) Compile command line and program output:

$ make -f $ORACLE_HOME/precomp/demo/proc/proc.mk EXE=char.22
OBJS=char.o

$ char.20

	Before: plain_old_char='Z'
	Before: char_string=[S]
	Before: charf_char='F'
	sqlca.sqlcode=(0)
	After: plain_old_char='Z' <--This oughta be an 'X'!
	After: char_string=[X]
	After: charf_char='X'

Pro*C 2.2 (7.3.2.3) Compile command line and program output:

$ make -f $ORACLE_HOME/precomp/demo/proc/proc.mk EXE=char.22
OBJS=char.o

$ char.22

	Before: plain_old_char='Z'
	Before: char_string=[S]
	Before: charf_char='F'
	sqlca.sqlcode=(0)
	After: plain_old_char='X' <--This is what I expected!
	After: char_string=[X]
	After: charf_char='X'

If you'll notice, with version 2.0 the initial value of "plain_old_char", 'Z', is still there AFTER the SELECT. I would have expected an 'X' since that's what's in the database and no error occurred. 1.6 and 2.2 returned an 'X', as expected. I've opened a TAR with ORACLE to find out if this is a known "bug" with 2.0 but am getting nowhere so far. The response on the CompuServe ORACLE Support forum was that "char in 1.6 is converted to CHARZ external datatype if mode=ansi and VARCHAR if mode=oracle. All 2.x (including 2.0 and 2.2) char is bound to CHARZ. ... contact the Language group in WW support ....", for whatever this is worth.

We usually use null-terminated "strings" (char arrays) or varchar, not "plain old char" or exactly-sized char arrays, but this situation scares me since I haven't seen it explicitly addressed and it doesn't necessarily cause a program to abend; it just makes it "wrong". We have been bitten a couple of times in Production by this and never knew anything funny happened until data got fouled up enough downstream to cause an error to occur or a person to notice.

If anyone has seen and/or struggled with this and has any more information about this "bug", I'd love to hear about it. Incidentally, we're on an NCR UNIX platform, but I'm not sure whether or not this problem is platform-specific.

Sorry this is so verbose. Thanks in advance for any feedback.

+================+========================================+
| Rick Wiggins   | Phone: (910)279-2270                   |
| Lead Developer | FAX:   (910)697-8021                   |
| AT&T HRISO     | Internet:   mailto:rickwiggins_at_att.com |
| Greensboro, NC | CompuServe: rick_wiggins               |
+================+========================================+