The C programming language

From: Sean 'Captain Napalm' Conner <spc_at_armigeron.com>
Date: Sat Mar 11 21:28:08 2000

It was thus said that the Great Allison J Parent once stated:
>
> < But I've been programming under multiple platforms in C for 10 years now.
> <I've learned a thing or two about writing portable code. It's surprising
> <how little effort it actually takes to write portable code, but it does tak
> <a different mind set that most programmers (in my experience) don't have.
>
> For the last 15-20 years I've been trying to resolve portability. Pascal
> and C were clear winners over BASIC always. Keep in mind the platforms
> I was trying to hit, CPM{z80}, RT-11 and VAX/VMS and for that carefull use
> of C (pay attention to what char, byte, long, double and float were) it was
> portable to the limit fo doing direct IO which is never portable. Pascal
> never failed to be portable as all objects were the same.

  With ANSI C (which is what I use, K&R being way to blecherous to even
consider), keep in mind that a character is 8 bits minimum, a short is 16
bits miminum, a long is 32 bits minimum (I don't recall the limits on floats
and doubles but I can look that up) and that an integer will be at least a
short in size, but never longer than a long, and a short is always shorter
than a long. There is no bitsize given for pointers, and you cannot mix
pointers except to/from void pointers (on certain PDPs I think a char
pointer has more information than a basic integer pointer).

  So, as long as you keep all that in mind, and realize that things WILL
CHANGE, you can write portable code. Remember, we're in a new transitional
phase right now to 64 bit systems (16 bit shorts, 32 bit ints, 64 bit
longs).

> This comes out of the tradidtion of C and unix and for that char is
> typically 7-9bits and is really an unsigned BYTE. The 8/16/32 world
> really forced a byte to conform to 8bits.

  But the C standard never talks about bytes, only characters and it's
implementation dependant on signage (is that even a word?).

> <Intel 386 class takes a penalty if you execute 16-bit instructions in a
> <32-bit segment (or vice-versa). So, to move a counted string, you have:
>
> Gee and HLLs were supposed to hide this... ;)

  C isn't exactly that HLL 8-)

> < You're not using C then. While it's possible to do:
> <
> < char *pd = destpointer;
> < char *ps = srcpointer;
> <
> < for (i = 0 ; i < sizeof(somestruct) ; i++)
> < *pd++ = *ps++;
>
> On some system this produses different code (usually bigger)
> on say z80 this will produce discrete code that is a monster.
>
> < That's going about things the hard way. Why not:
> <
> < memcpy(destpointer,srcpointer,sizeof(somestruct));
>
> Than this. Z80 library has enough smarts to use the LDIR/LDDR instruction
> that is fast and efficient.
>
> < Or even:
> <
> < *destpointer = *srcpointer;
>
> Unpredictable how the compiler will do it even if it works.
> This can be horrendus!

  That is not unpredictable (at least in ANSI C, K&R I won't guarentee).
The following is legal ANSI C:

        #include <time.h>
        #include <stdlib.h>

        int main(void)
        {
          struct tm one_tm;
          struct tm two_tm;
          struct tm *pone_tm;
          struct tm *ptwo_tm;

          pone_tm = &one_tm; /* assign address of one_tm to pone_tm */
          ptwo_tm = &two_tm;

          one_tm = two_tm; /* copy structure two_tm to one_tm */
          *pone_tm = two_tm; /* ditto */
          *pone_tm = *ptwo_tm;
          one_tm = *ptwo_tm;
          return(EXIT_SUCCESS);
        }

  The * operator in this case dereferences a pointer, so the last four
assignment statements do all the same thing, basically, copy the contents
in the structure two_tm to the structure one_tm.

  Granted, the whole C pointer thing could have been done better ...

> < One thing---I can't write Assembly on linus.slab.conman.org (an AMD 586)
> <and have it run on tweedledum.slab.conman.org (68040). C at least lets me
> <write code that will run on both machines.
>
> As would pascal, ADA, basic{maybe}, fortran and heaven help me COBOL.

  Would that be FORTRAN, FORTRAN-II, FORTRAN-III, FORTRAN77 or FORTRAN90?

  -spc (Remembers programming in FORTRAN77 ... )
Received on Sat Mar 11 2000 - 21:28:08 GMT