Undelivered mail

[MAILER%ALASKA.BITNET at CUNYVM.CUNY.EDU]

Subject:  Re: Are the criteria for Unix and PC compilers different?

[Non-Deliverable:  User does not exist or has never logged on]

Reply-To: Info-C at BRL.ARPA

Received: From UWAVM(MAILER) by ALASKA with Jnet id 4971
          for SXJVK at ALASKA; Fri, 11 Mar 88 14:24 AST
Received: by UWAVM (Mailer X1.25) id 3283; Fri, 11 Mar 88 15:24:19 PST
Date:         Wed, 9 Mar 88 19:49:39 GMT
Reply-To:     Info-C at BRL.ARPA
Sender:       Info-C List <INFO-C at NDSUVM1>
From:         Ray Butterworth <rbutterworth at watmath.waterloo.EDU>
Subject:      Re: Are the criteria for Unix and PC compilers different?
Comments: To: info-c at brl-smoke.arpa
To:           Vic Kapella <SXJVK at ALASKA>

In article <22314ad9 at ralf.home>, Ralf.Brown at B.GP.CS.CMU.EDU writes:
> In article <1106 at silver.bacs.indiana.edu>, backstro at silver.bacs.indiana.edu
(Dave White) writes:
> }When will they
> }realize that some of us really want the option of using 32-bit ints to
> }port Unix-born code?
>
> #define int long
> Need I say more?

Yes.

I think "Unix-born" is a euphemism for "badly written" or "non-portable".

Code that assumes that "int" is 32 bits is usually written because
the programmer was lazy.  By making everything "int" he can avoid
having to make many declarations and having to include header files.

In particular, instead of having code like:
    extern int func1();
    extern int x;
    int func2(a) int a; { blah; blah; }
he will probably have:
    extern x;
    func2(a) { blah; blah; }
or maybe even
    x;
    func2(a) { blah; blah; }

"#define int long" won't help much with this code.