Notes on Writing Portable Programs in CWe will cal

文件名称: Notes on Writing Portable Programs in C

所属分类: C

开发工具:

文件大小: 228kb

下载次数: 0

上传时间: 2019-07-27

提供者: win****

下载 (228kb)

不能下载？报告错误

详细说明：We will call a program portable if adapting it to a new environment is easier than rewriting it for that environment. This document is mainly for those who have never ported a program to another platform — a specific hardware and software environment — and, evidently, for those who plan to write larC Portability Notes 10 VMS 19 10.1 File Specifications 19 10.2 Miscellaneous 20 11 General Guidelines 20 11.1 Types and pointers 20 11.2 Compiler differences 11.2.1 Conversion rules 22 11.2.2 Compiler limitations 22 11.2.3 ANSI C 11. 2. 4 Miscellaneous 23 11. 3 File 11.3.1 General Guidelines 11.3.2 Source file 25 11. 4 Miscellaneous 25 11.5 Writing Portable Code 26 12 Further Reading 26 13 Acknowledgements 27 1 4 Trademarks 27 1 Foreword We will call a program portable if adapting it to a new environment is easier thar rewriting it for that environment. This document is mainly for th Lose who have never ported a program to another platform a specific hardware and software environment-and, evidently, for those who plan to write large systems which must be used across different vendor machines. If you have already done some porting you may not find the information herein very useful We suggest that CEK+go be read in conjunction with this document. Posters to the newsgroup comp. langc have repeatedly recommended Hor90 and [ Koe89 (none of the information herein has been taken from those two references Disclaimer: We will attempt to keep the information herein updated, but it can happen that some of it may be incorrect at the time of reading The code fragments presented are intended to make applications"more portable, meaning that they may fail with some compilers and or environments This document can be obtained via anonymous FTP from sauna. hut. fi[130. 233. 251. in ftp/pub/Comp SciLab/doc. The files 'portableC tex,,'portableC sty,,portable. bib and 'portable ps Z are the IATEX source and style files, BIBTEX and the compressed POSTScrIPt, respectively. Alternatively, there is a site in the uS from which one can obtain all four files cs.washington. edu.95. 1.4 in'ftp/pub/cport tar. Z'. All files arc in the public domain Comments, suggestions, flames, eggs, and requests for copies via e-mail should be directed to adoosauna. hut, fi 2 Introduction The aim of this document is to collect the experience of several people who have had to write and or port prograns written in C to more than one platform In order to keep this document within reasonable bounds, we must restrict our selves to programs which must execute under Unix-like operating systems and those which implement a reasonable Unix-like environment The only exception we will consider isⅤMS a wealth of information can be obtained from programs that have been written to run on several platforms. This is the case of publicly available software such as that developed by the Free Software Foundation and the MIT X Consortium When discussing portability, one focuses on two issues The language, which includes the preprocessor and the syntax and the seman tics of the language The environment, which includes the location and contents of header files and the run-time library We include in our discussions the standardization efforts upon the language and the environment. Special attention will be given to foating-point representations C Portability notes X3J88-henceforth referred to as the Standard -are not extensively covered this document 2 3 Standardization efforts All standards have a good side and an evil side. Due to the nature of this document. we are forced to focus our attention on the latter The American National Standards Institute(ANSi has recently approved of a standard for the C programming language [X3J88. The Standard concentrates on the syntax and semantics of the language and specifies a. minimum environment (the name and contents of some header files and the specification of some run-time library functions Copies of the ANSI C Standard(ANSI X3. 159-1989)can be obtained from the following address American National Standards Institute les Department 1480 Broadway Now York. NY 10018 ( Voice)(212)6424900 (Fax)(212)302-1286 3.1 ANSI C 3.1.1 Translation limits We first bring to the readers attention the fact that the Standard states some environmental limits. These limits are lower bounds, meaning that a correct (compliant) compiler may refuse to compile an otherwise-correct program that exceeds one of those limits. 3 Below are the limits that we judge to be the most important. The ones related to the preprocessor are listed first 8 nesting levels of conditional inclusion 8 nesting levels for #inc ludedfiles 32 nesting levels of parenthesized expressions within a fall ecpression. This will probably occur when using macros 1024 macro identifiers simultaneously. Can happen if one includes too many header files 509 characters in a logical source line. This is a serious restriction if it ap plies after preprocessing. Since a macro expansion always results in one line this affects the maximum size of a macro it is unclear what the standard means by a logical source line in this context and in most implementations 6 significant initial characters in an external identifier. Usually this con straint is imposed by the environment, e.g., the linker, and not by the compiler 127 members in a single structure or union 81 parameters in one function call. This may cause trouble with functions that accept a variable number of arguments. Therefore, it is advisable that when designing such functions that either the number of parameters be kept within reasonable bounds or that alternative interfaces be supplied e.g., uSing arrays It is really unfortunate that some of these limits may force a programmer to code in a less elegant way. We are of the opinion that the remaining limits stated in the Standard can usually be obeyed if one follows"good"programming practices However, these limits may break programs that generate C code such as compiler compilers and many ct+ compilers 3.1.2 Unspecified and Undefined Behavior The following are examples of unspecified and undefined behavior The order in which the function designator and the arguments in a function call are evaluated 2. The order in which the preprocessor concatenation operators and ## are evaluated during macro substitution 3. The representation of foating-point types 4. An identifier is used that is not visible in the current scope 5. A pointer is converted to something other than an integral or pointer type The list is long. One of the main reasons for explicitl ly defining what is not covered by the Standard is to allow the implementor of the c environment to make use of the most efficient alternative 3.2 POSIX The objective of the POSIX working group P1003 1 is to define a common in terface for Unix. Granted, the ANSt C standard does specify the contents some header files and the behavior of some library functions but it falls short of defining a useful environment. This is the task of p10031 We do not know how far P1003 1 addresses the problems presented in this doc ument as at the moment we lack proper documentation. Hopefully, this will be corrected in a future release of this document C Portability notes 4.1 Command options The interpretation of the -I command option can differ from one system to an other. Besides, it is not covered by the standard. For example, the directive #include dir/file. h" in conjunction with -.. would cause most prepro cessors in a Unix-like environment to search for file.h'in"./dir,, but under VMS. 'file. h' is only searched for in the subdirectory 'dir' in the current work- ing director 4.2 #pragma and #elif Directives are very much the same in all preprocessors, except that some prepro- cessors may not know about the defined operator in a #if directive nor about the #pragma and #elif directives The #pragma directive should pose no problems even to old preprocessors if it comes indented. 4 Furthermore, it is advisable to enclose them with #ifdefs in order to document under which platform they make sense #ifdef pragma #endif Beware of #pragma directives that alter the semantics of the program and consider the case when they are not recognized by a particular compiler. Evidently, if the behavior of the program relies on their correct interpretation then, in order for the program to be portable, all target, platforms must recognize them properly 4.3 Concatenation Concatenation of symbols has two variants. One is the old K&R KR78 style that simply relied on the fact that the preprocessor substituted comments such as/**/for nothing. Obviously, that does not result in concatenation if the preprocessor includes a space in the output. The ANSI C Standard defines the operators## and (implicit) concatenation of adjacent strings. Since both styles are a fact of life it is useful to include the following in one's header files #ifdef STDC define GLUE (a, b)a##b #else define gLue (a, b) a/**/b #endif If needed, one could define similar macros to GLUE several arguments.6 Old preprocessors only take directives that begin with# in the first column Some have suggested using #if- STDC_- instead of simply #ifdef -STDC- to test if the 4.4 Token substitution Some preprocessors perform token substitution within quotes while others do not. Therefore, this is intrinsically non-portable. The Standard disallows it but provides a mechanism to obtain the same results. The following should work with ANSI-compliant preprocessors or with the ones that perform token substitution chin quote #ifdef STDC define MAKESTRINg(s)# felse define MAKESTRING(s) "s" fendi 4.5 Miscellaneous We would not trust the following to work on all preprocessors tdefine d define fd this that The Standard does not allow such a syntax(see $ 20 in X3. 88) Many preprocessors ignored, or still ignore, text after the #else, #elif, and #endif directives. However, the standard forbids anything but comments after these directive Some preprocessors will consider it an error to #undef something that has not been #defined, although it is allowed to do so Finally, we must add that the Standard has fortunately included a#error directive with obvious semantics. Indent the #error since old preprocessors do not recognize it 5 The Language 5.1 The Syntax The syntax defined in the Standard is a super sel of the one defined in k&RKR78 It follows that if one restricts oneself to the former, there should be no problems with an ANSI C-compliant compiler wnith respect to synta.C. The semantics are however, another problem altogether and is covered superficially in the next sec The Standard extends the syntax with the followin The inclusion of the keywords const, enum, signed, void, and volatile C Portability Notes 5. Trigraph notation for specifying otherwise-unobtainable characters in re stricted character sets We encourage the use of the reserved words const and volatile since they aid in documenting the code. It is useful to add the following to one's header files if the code must be compiled by a non-conforming compiler as well #ifndef STDC t define const define volatile fendi However, one must then make sure that the behavior of the application does not depend on the presence of such keywords.(Evidently, programs that contain dentifiers with those names nust be nodified to conform to the Standard. The trigraph notation can bring unexpected results when a program is compiled by an ANSI-compliant compiler. e. strings such as "?? will produce " Watch out! 5.2 The Semantics The syntax does not pose any problem with regard to interpretation because it can be defined precisely. However, programming languages are always described using a natural language, e. g. English, and this can lead to different interpretations of the same text Evidently, [KR78 does not provide an unambiguous definition of the C language otherwise there would have been no need for a standard. Although the standard is much more precise, there is still room for different interpretations in situations such as f(p=&a, p=&b, p=&c).Does this mean f( &a, &b, &c) or f(&c, &c, &c)? Even"simple?"cases such as a[i] =b[i++] are compiler-dependent CEK+90 As stated in the Introduction, we would like to exclude such topics. The reader is instead directed to the Usenet newsgroups comp. std c or comp.lang c where such discussions take place and from where the above example was taken. The Journal of c language Translation'could, perhaps, be a good reference. Another possibility is to obtain a clarification from the standards Committee and the address is X3 Secretariat, CBEMA 311 1st st nw ste 500 Washington DC, USA Finally, we mention that a complete list of the differences between"ordinary'C and ANSI C can be found in the Second Edition of K&r Kr88. a slightly less up-to-date list can also be found in [HS87 10 simplicity of its design and of its implementation.(It is written, of course, mostly C. However, these facts also contributed to everyone developing their own dialect. In particular, the University of Berkeley at California distribute the so-called BSDs Unix whereas at&T now distribute(sell) System V Unix. All other versions of Unix are descendants of one of these major dialects The differences between these two major favors should not upset most application programs. In fact, we would even say that most differences are just annoying BSD Unix has an enhanced signal handling capability and implements sockets However, all Unix flavors differ significantly in their raw I/O interface(that is the ioctl system call), and this should be avoided if possible The reader interested in knowing more about the past and future of Unix can consult [ Man89, Int 90 7 Header files Many useful system header files are in different places in different systems, or they define different symbols. We will assume henceforth that the application has been developed on a BSD-like Unix and must be ported to a System V-like Unix or VMS or a Unix-like system with header files that comply with the standard In the following sections, we show how to handle the most simple cases that arise in practice. Some of the code that appears below was derived from the header file 'Xos. h'which is part of the X Window System distributed by Mit. We have added changes, e.g., to support VMs any header files are unprotected in many systems, notably those derived from BSD version 4.2 and earlier. By" unprotected we mean that an attempt to include a header file nore than once will either cause compilation errors(e.g due to recursive or nested includes or, in some implementations, warnings from the preprocessor stating that symbols are being redefined. It is good practice to protect header files 7.1‘ ctype ctype. h' provides alnmost the same functionality on all systems, except that some symbols must be renamed #ifdef SYsv define -ctype_ -ctype define toupper-toupper f define tolower tolower #endif Under Sys V, toupper and tolower are also defined and will check the validity their arguments and perform the conversion only if necessary. Under BSD-derived

(系统自动生成,下载前可以参看下载内容)