Re: Porting Experiences (was Ada and Pascal etc )

[kaz@helios.crest.nt.com (Kaz Kylheku)]

In article <3460A7BB.3CCD27DC@hso.link.com>,
Samuel T. Harris <s_harris@hso.link.com> 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