Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!cme!libes From: libes@cme.nist.gov (Don Libes) Newsgroups: comp.lang.c Subject: Re: Help with C between 68000 & 80286 Message-ID: <5633@muffin.cme.nist.gov> Date: 7 Aug 90 03:54:26 GMT References: <1990Aug7.023429.19786@athena.mit.edu> Reply-To: libes@cme.nist.gov (Don Libes) Organization: National Institute of Standards and Technology Lines: 27 In article <1990Aug7.023429.19786@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes: >back) with scanf and/or atoi, atol, atof, etc. You may find yourself wishing >that the data files had been written in a text format originally (I certainly >would, if I were stuck with this problem). ASCII text data files are usually >preferable for this very reason (and for several other reasons). Some will >claim that ASCII storage, with its inherent formatting on output and parsing >on input, is too inefficient, but this is often not true in practice. >I think I'll add this to the FAQ list; it comes up all the time. (Worry not, >efficiency hackers, I'll try not to editorialize in favor of ASCII storage >too much.) Please add that there is an ISO standard for machine-independent data storage, namely 8825 (ASN.1 Basic Encoding Rules) and there is a public-domain implementation of it along with ASN.1 (ISO 8824) itself. In my experience, ASCII is ok only for the simplest of applications. As you say (and I agree), inefficiency is not the big problem. The big problem is that users have to rediscover using trial and error all the nonobvious problems that ASCII representation presents. Do you handle quotes? Whitespace? \0? Structs? Linked-lists? I'm not saying these are impossible to solve with ASCII. I'm just saying the likelihood is high that most people will produce ad hoc buggy solutions, and that leads to a waste of their time. Don Libes libes@cme.nist.gov ...!uunet!cme-durer!libes