On portable C programming

[Jim Kuzdrall]

On Friday 09 January 2009 07:47, Jerry Feldman wrote:

> There are actually systems that do this such as ASN 1 == *X.680.
> Essentially, the way it works is that everything transmitted is in
> TLD (type, length data) format. An integer, for instance would have a
> type code (one for 16-bit, 1 for 32-bit, 1 for 64-bit, etc), followed
> by a 1 byte length, followed by several individual bytes representing
> the integer. Lengths longer than 127 would be represented in a
> multi-byte length. All data would be sent in big endian format.
> Endian is another problem with standard data. Integers and Doubles
> are in different formats on big endian machines like the Sun Sparc,
> and little endian in Intel x86 and Digital Alpha. Some chips, like
> the Intel IA64 and the later Alpha chips could be set to be either
> little or big endian.  Using any portable format for local use is
> costly from a performance standpoint, but absolutely necessary for
> interchange between computers of unlike types.  Additionally, the
> implementers of the C and C++ standards decided to use objects like
> size_t which may be 32-bits on a 32-bit architecture, 64-bits on a
> 64-bit architecture (LP64) where longs are 64-bit, and 32-bits where
> longs are 32-bits such as on Windows 64. Java certainly was written
> with portability in mind. Data base systems took all this into
> account many years ago. I once sat on the ANSI database committee and
> our biggest discussions had to do with how to describe numbering
> formats which are not only different on different architectures, but
> also on different programming languages (C, FORTRAN. COBOL, et. al). 
> So, portability is not just structs and alignments, but also endian
> and as mentioned numbering types if data is to be sent to a receiver
> with another programming language. *

    Yes, it has been quite a problem over the years.  I have been 
designing and programming computers since 1960, mostly at the ALU and 
binary data level, where format is critical.

    The functions I created addressed, in a very elegant way, the very 
problems you speak of.  They have been republished a number of times.  
They are extremely fast.

    The algorithm is elegant in that the C code for these functions is 
exactly the same regardless of what computer or compiler is used.  
There are no header entries or #ifdef telling the code that the host is 
big endian, or BCD, or 1's compliment, or IEEE float.  No knowledge 
about the host system's numeric format need be known.  None at all.  
Yet, the functions always compile and do their job correctly, whether 
storing the data or fetching the data.

    I was well aware of ASCII transfer and the algorithms for converting 
one stored format to another when I wrote the functions in the 1980's.  
I wanted code that my programmers didn't have to fiddle with when 
porting to one of the many new processors and systems emerging.  It 
also had to be lightning fast, because the data libraries were large 
and the processor MIPS were low.

    As with most programs that dig down so far into bit-wise formats, 
this one requires some background to understand.  It has been tested on 
many processors and operating systems, but it never had a big company 
behind it to push for more universal application.  To late now.

    (Incidently, the pointer array I mentioned in an earlier post is not 
needed.  The programs can read and write data directly to the host's 
structs.) 

Jim Kuzdrall