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: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/08 Message-ID: <4kcpgkINNcku@keats.ugrad.cs.ubc.ca>#1/1 X-Deja-AN: 146492924 references: <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> organization: Computer Science, University of B.C., Vancouver, B.C., Canada newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-08T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: >Peter said > >">Something which works only on some systems is >>not a portability problem *if there is no standard saying it works*. Likewise >> i = ++i; >>producing different results on different machines is not a "portability >>problem"." > >This is a perfect case of Peter saying: Language X ensures that all >portable programs are portable, therefore there are no portability >problems. This is of course vacuously true for all languages! I'm not sure that he means this vacuous truth. I think that Peter would say that a program is portable if it is strictly compliant to a standard. In the case of C that means it avoids invoking implementation-defined and unspecified behavior, and certainly undefined behavior. >By a "portability problem" most people mean that you take a program >written in language X, and try to move it to machine Y from machine Z, >and it does not work any more. Yes, according to your empirical/pragmatic conception of portabilitity. >Portability problems are most definitely caused by writing non-portable >code. In fact in the absence of errors in the compiler of environment >on machine Y or machine Z, this is the ONLY source of portability >problems. > >However, it is definitely the case that languages vary in the ease with >which people end up writing non-portable code deliberately or >accidentally. > >For example, in C, we can't declare an integer variable without >introducing a potential portability dpeendence on the range. Careful It's not that bad because there are those ``minimum maximums'' defined by the ANSI standard for . An int is at least -32767 to 32767, a long is at least -2^31+1 to 2^31-1, and an unsigned long at least 2^32-1. These ranges are guaranteed, and can be assumed by any portable program. >From Peter Seebach's FAQ: Herewith, some infrequently-asked questions and their answers: Section 1. Declarations and Initializations 1.1: How do you decide which integer type to use? A: Use ``short'' when you need to avoid values over 32,767, ``int'' when you want to store integers, ``long'' for long numbers (more than 6 digits), and ``float'' for numbers over 4 billion. 1.2: What should the 64-bit type on new, 64-bit machines be? A: int. 1.3: If I write the code int i, j; can I assume that (&i + 1) == &j? A: Only sometimes. It's not portable, because in EBCDIC, i and j are not adjacent. Pretty easy, if you ask me! --