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,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: kaz@helios.crest.nt.com (Kaz Kylheku) Subject: Re: Porting Experiences (was Ada and Pascal etc ) Date: 1997/11/05 Message-ID: <63qq9k$njt$1@helios.crest.nt.com>#1/1 X-Deja-AN: 288139708 References: <34557f2b.1934172@news.mindspring.com> <345E3ACD.A15@gsg.eds.com> <63mcmm$r3s$1@helios.crest.nt.com> <3460A7BB.3CCD27DC@hso.link.com> Organization: A poorly-installed InterNetNews site Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-05T00:00:00+00:00 List-Id: In article <3460A7BB.3CCD27DC@hso.link.com>, Samuel T. Harris wrote: >Reading the arguments between Kaz and others, I'm struck >with the realization that Kaz is missing a significant >point. As long as application code is not concerned >with the representation of variables, Kaz is correct >in his statements that a few simple guidelines insure >good type choices for portable C code. What Kaz has >failed to consider, but has been state by others, is >that sometimes the representation of the type IS >important to the application, or at least to the >context in which the application is running. Then the application is not portable, by definition. A portable program is one which is not concerned with the representation of a type. >The classic example here is a 32-bit integer. While >application usually are only concerned witht he RANGE >supported by the type (and Kaz's guidelines do insure >a proper choice of type) the context in which the Those are not only my guidelines, but have been reiterated by other comp.lang.c regulars. They are also reflected in the comp.lang.c FAQ. >app is running may force the use of a 32-bit integer, >especially when interfacing to hardware, COTS libraries, Interfacing to hardware is outside of the domain of a strictly conforming C program. A pure C language program communicates with the environment only through streams. There are ways, using C, to conform to external storage layouts in maximally portable ways which do not depend on the representation of types other than the type unsigned char. >or in a distributed environment where heterogenous >architectures must interface with each other. These I have programmed in such circumstances and managed to remain strictly conforming. Interfacing heterogeneous architectures can be solved by identifying a canonical external representation format and then writing maximally portable routines which encode data items to and from that format. In my experience, only floating point representations represent any significant difficulties in this area. >are common examples of the context forcing a representation. >C does not support forcing the representation in a >portable way. Ada does. The need for such cannot >be simply dismissed because the need is real. But C allows you to manipulate individual bytes, and therein lies the secret. >In fact, Ada provides me facilities to exactly map >the representation of a record right down to the >location and size of each field to conform to the >requirements of memory-mapped hardware registers. This is also possible with C in a portable way. It is not that convenient, of course, but we are discussing portability, rather than convenience. >This is very powerful and convenient. I can even I couldn't agree more, but please stick to the topic which is portability. >So, I can't say to Kaz that he is wrong, because >he is not, as far as he goes. What I do say to Kaz >is "You have only pricked the tip of the portability >iceberg." Portability involves much more than guaranteeing That's because I was only asked to scratch the surface, because the subject that arose was the choice of integral types to suit particular requirements. Now we are on the topic of conforming to external storage formats, which is something else. You haven't requested a discussion of this topic before. Conforming to external data layout can be done in a highly portable way in C. It can also be done in non-portable ways which are usually faster. Instead of useless talk, why don't we try the following game: you describe the storage layout, and I will demonstrate a maximally portable C example which can communicate with that layout. I will entertain you as long as you wish. Perhaps you will emerge out of this better armed for situations in which you have to use C rather than some other preferred tool such as Ada. >products with custom code. C simply does not have the >language features to support any but the most >rudimentary porting requirements of single-machine, >black-box applications that run by themselves or >with others in a strictly homogeneous environment >all of which are built with a strictly compatible >set of tools. That depends on what you mean by language features. If you mean that C doesn't have language features that are *specifically* designed to help you in this area, then you are right. -- "In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt." -- Blair P. Houghton