FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Michael Peppler [mailto:mpeppler AT bluewin.ch]
> Sent: July 22, 2003 8:51 AM
> > 
> > I associate "bus error" with 64-bit
> > architectures.  And I don't see anything wrong with the 
> > code.  Must be something else.  
> 
> Me I associate "bus error" with data alignment errors - comes from my
> days of programming on the Sparc architecture, which is really very
> sensitive of data alignment (doubles on 8 byte boundaries, etc)
> 
> Could it be something like that here?

Quite right, I didn't express myself clearly.  It so happens that my only
experience with data alignment errors is on DEC Alpha, which of course is
64-bit.  I think of it as a "64-bit" problem because 64-bit architectures
tend to expose data alignment errors in code developed on 32-bit platforms.
I've never seen it on I32.  

That said, here are the offending declarations and code:

typedef struct tdsnumeric
{
        unsigned char         precision;
        unsigned char         scale;
        unsigned char         array[33];
} TDS_NUMERIC;

         const TDS_NUMERIC * numeric
        const unsigned char *number;

        unsigned int packet[sizeof(numeric->array) / 2];
        unsigned int *pnum, *packet_start;
        unsigned int *const packet_end = packet + TDS_VECTOR_SIZE(packet);

        int num_bytes;
        unsigned int n;

        /* put number in a 16bit array */
        number = numeric->array;
         ^^^^^^ same type: unsigned char
        num_bytes = tds_numeric_bytes_per_prec[numeric->precision];

        n = num_bytes - 1;
             ^^^^^^^^^ should assert(num_bytes > 0);
        pnum = packet_end;
         ^^^^ same type: unsigned int

> Program received signal SIGBUS, Bus error. 
> 0x284cf2ad in tds_numeric_to_string (numeric=0x81b4564, 
> s=0xbfbfda00 ",ê\034\b") at numeric.c:279 
> 279       *--pnum = number[n - 1] * 256 + number[n]; 

I wonder if I'm looking in the wrong place, because that looks like perfect
C to me.  "256" is an integer constant; according to K&R A2.5.1 it's of type
int.  "number[n - 1]" is of type unsigned char; K&R A6.1 says it's promoted
to int if possible (it's possible).  Their product is of course of type int.
When "number[n]" is added to that, it will likewise be promoted to int.  We
wind up with *pointer-to-int = int * int + int.  I don't see an alignment
problem.  <shrug>

If either of my patches solves the problem, I'd be inclined to think we
found a compiler bug.  You?  

--jkl


-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.