Conference turris::decc

Mark,
	I copied the source (commented out the include of snalu62df.h),
compiled it with V5.5-002 on OVMS on both Alpha and VAX, and I don't see the
problem when I run it:

� cc decc_2169.c

        src.dsc$a_pointer = ebc;
........^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "
ebc" is "unsigned char", which is not compatible with "char".
at line number 104 in file C4$:[HARRIS]DECC_2169.C;2

        dst.dsc$a_pointer = asc;
........^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "
asc" is "unsigned char", which is not compatible with "char".
at line number 109 in file C4$:[HARRIS]DECC_2169.C;2

        if (!(status & 1)) LIB$SIGNAL(status);
...........................^
%CC-I-IMPLICITFUNC, In this statement, the identifier "LIB$SIGNAL" is implicitly
 declared as a function.
at line number 116 in file C4$:[HARRIS]DECC_2169.C;2
� link decc_2169
%LINK-W-WRNERS, compilation warnings
        in module DECC_2169 file C4$:[HARRIS]DECC_2169.OBJ;2
� asc :== $c4$:[harris]decc_2169.exe;1
� asc 121212
char 12 leng  0
char 12 leng  1
char 12 leng  2

src name ebcdic
12 12 12

src name ascii
Status of asc_ebc = 1
12 12 12

What version of OVMS is the customer running?  Do they have any special link
procedure we should know about?
				-Kevin

        unsigned short loadhex(s, d)
        char	*s;
        unsigned char d[];
        {
        	unsigned char j;
        	unsigned short lg;
        
        	lg = 0;
        	s = spanc(s);
        	while ( *s) {
        		sscanf(s, "%2x", &j);
        		s = s + 2;
        		d[lg] = j;
        		printf("char %2x leng  %d\n", d[lg], lg);
        		lg = lg + 1;
        		s = spanc(s);
        	}
        	d[lg] = '\0';
        	lg = lg + 1;
        	return(lg);
        }
        
        
        You can't declare j to be an unsigned char there, because you
        are passing its address to sscanf with a format specifier "%2x"
        that requires the corresponding argument to be a "pointer to
        unsigned int".
        
        I.e., every call to sscanf in the loop is writing sizeof(unsigned int)
        bytes through &j, but sizeof j is just 1.  Depending on where
        j and lg are placed in memory, the call to sscanf might overwrite
        the value of lg.
        
        Try changing the declaration of j to be unsigned int.
        
        Dan

The customer is running on a VAX  OVMS 6.2 
I do include that snalu header and link as

link	prog,lu62/opt

where lu62.opt has
sys$share:snalu62h.exe <- or what ever the name is I'll be back there
shortly and verify with an instruction step what happens at this site and
report back here to night my time.

	Cheers
		Mark :)

ps.
	depending on what I find I will get a copy of the binary asc.exe 
from the site and try it else where.
[Posted by WWW Notes gateway]

Interesting idea about the unsigned short and sscanf I will look at this.
However the machine list showed that lg was held in r3 and was never temp
outside of the register set so I don't see how sscanf could ever over write
this one, except that maybe sscanf manages to write over the saved r3 on
its call frame hmm.
	The other problem is that it works on Unix and works on an old VAXC
and as reported in reply 1

	I'll update this note again this evening my time.

	Cheers
		Mark :)
[Posted by WWW Notes gateway]

The tricky thing was that cc/noopt fails because it used the stack to hold lg
which was adj to the auto variable j which was unsigned byte and had a long
written by sscanf where as /opt used a register for lg and so did not cop it
from
sscanf.
	I had a listing from yesterday showing the use of a register for lg 
which appeared to be failing. I must just be confused. 
	Thanks for the correct spot on sscanf and short/byte destination.

	Cheers
		Mark :)
[Posted by WWW Notes gateway]