Portability across architectures..

Scott Gulland scottg at hpiacla.HP.COM
Sat Sep 17 00:23:40 AEST 1988


/ hpiacla:comp.lang.c / dhesi at bsu-cs.UUCP (Rahul Dhesi) /  8:43 pm  Sep 13, 1988 /
>> In article <7038 at bloom-beacon.MIT.EDU> scs at adam.pika.mit.edu (Steve Summit)
>>writes:
>>[numerous arguments in favor of using ASCII text for portability]

> Counterarguments:
> 
> 1.   ASCII text is likely to be very bulky.

True, ASCII text may be very bulky, but isn't this just an efficiency issue.
When portability to many machine architectures is truly needed, most people
will gladly sacrifice efficiency for ease of portability in their data files.


> 2.   All modern hardware architectures can use 8-bit bytes, so ASCII
>      is unnecesssary except for older machines.  (Think "networks".)

I'm sorry, but I don't understand how this statement relates to portability
of data between heterogeneous architectures.  In any event, this is a simple
statement, NOT a counterargument.  How about explaining your rationale in 
a little more detail.

>
> I suggest encoding the data in bytes using a known byte order.

Bad idea !  Many architectures use different byte orderings for integers
, reals, etc.  This also does not seem to address differences between
floating point formats, sizes of integers, etc.  You also have to deal
with differences in representation of data types in the same language, but
on different architectures.  You will find that different implementations
of a language will store data in subtlely different ways.

**************************************************************************
* Scott Gulland	            | {ucbvax,hplabs}!hpda!hpiacla!scottg [UUCP] *
* Indus. Appl. Center (IAC) | scottg at hpiacla                      [SMTP] *
* Hewlett-Packard Co.       | (408) 746-5498                      [AT&T] *
* 1266 Kifer Road           | 1-746-5498                     [HP-TELNET] *
* Sunnyvale, CA  94086  USA | "What If..."                [HP-TELEPATHY] *
**************************************************************************



More information about the Comp.lang.c mailing list