Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!nrl-cmf!ukma!cwjcc!hal!nic.MR.NET!shamash!nis!ems!questar!midgard!dal
From: dal@midgard.UUCP (Dale Schumacher)
Newsgroups: comp.os.minix
Subject: Re: Minix/ST <stdio.h> problems.
Summary: X3J11 discusses this problem
Message-ID: <486@midgard.UUCP>
Date: 31 Oct 88 17:34:08 GMT
References: <249@cstw01.UUCP> <7683@boring.cwi.nl>
Reply-To: dal@syntel.UUCP (Dale Schumacher)
Organization: The Midgard Realm, St Paul MN
Lines: 23

In article <7683@boring.cwi.nl> siebren@cwi.nl (Siebren van der Zee) writes:
|In article <249@cstw01.UUCP> meulenbr@cstw01.UUCP writes:
|>Hi!
|>
|>I've encountered a number of problems using Minix/ST <stdio.h>.
|>The major problem is that it defines NULL as 0.
[...]
|>This is a killer on an ST since sizeof(char *) == 32 and sizeof(int) == 16.
|>Solution: change the 0 in (char *)0
|
|It has been a killer ever since 32-bit architectures showed up

The X3J11 C standard proposal discusses this problem.  It states that NULL
may be defined as 0, 0L or ((void *) 0) as needed by an implementation.
Therefore, is makes sense for NULL to be 0 (maybe) on the PC version, and
0L on the ST.  Other liberties, like assuming sizeof(int)==sizeof(char *)
and failing to declare pointer return values, are simply NON-PORTABLE and
should not be used in Minix-related code or anything else pretending to be
portable.  I think it is very desirable to have code which compiles under
Minix-PC work properly under Minix-ST with NO CHANGES, and visa-versa.  I
don't think this is unreasonable to expect.

P.S.:  When we get a more ansi-conformal compiler for Minix, possibly from
Sozobon, NULL would change to the ((void *) 0) that it SHOULD be.