From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10261c,90121986704b5776 X-Google-Attributes: gid10261c,public X-Google-Thread: fdb77,4873305131bf4d94 X-Google-Attributes: gidfdb77,public X-Google-Thread: 10c950,90121986704b5776 X-Google-Attributes: gid10c950,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public From: seebs@plethora.net (Peter Seebach) Subject: Re: Portability: C, C++, Ada Date: 1997/11/01 Message-ID: <63e8n0$99h$4@darla.visi.com>#1/1 X-Deja-AN: 286329851 References: <34557f2b.1934172@news.mindspring.com> <3459AC95.1D75@dynamite.com.au> <63aodd$t55$1@helios.crest.nt.com> <345BA52D.56F1@dynamite.com.au> X-Complaints-To: news@visi.com X-Trace: darla.visi.com 878356000 9521 205.166.146.1 (1 Nov 1997 03:46:40 GMT) Organization: Plethora Internet Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.lang.java.advocacy,comp.lang.pascal.ansi-iso,comp.lang.pascal.misc Date: 1997-11-01T00:00:00+00:00 List-Id: In article <345BA52D.56F1@dynamite.com.au>, Alan E & Carmel J Brain wrote: >> C++ is not C however. What are your experiences with porting ANSI/ISO C code >> from one ISO compiler to another? >Fairly awful. You see, often there are compiler directives buried in >there that assume a pre-processor of a particular variety. Usually named >after a ruminant herbivore. Ahh! Then you weren't really porting "ANSI/ISO C code". You were probably porting GNU C, which is a very different beast, or worse, the sort of vague, ill-defined language that generally goes by "the C we used to have on that one computer when I was in college". >> C porting headaches usually stem from legacy ``classic'' C code, in which the >> chief difficulty is bugs uncovered when one adds function prototypes. Then >> there are dependencies of implementation characteristics: byte order, size of >> various types, and so forth. >Completely agree. Regardless of the reason though, C porting headaches >exist, as a general rule, do they not? Not very much any more. I have a couple of systems. They're classic portability hell - they use 64 bit file sizes, rename and/or redefine "classic" features (like 'sys_errlist'), and so on... I've recently been compiling a *lot* of software on them. The only package I've had any trouble with was last modified in 1993; it used 'sys_errlist'. That's it. Everything else has been nice and quiet. It's gotten a lot better over time; not just with the standard, but with the widespread availability of compilers done since the standard... gcc, for all its faults, has done a lot to make C more accessible. -s -- seebs@plethora.net -- Speaking for myself. No spam please. Copyright 1997. All rights reserved. This was not written by my cat. C/Unix wizard - send mail for help! -- - More Net, Less Spam!