From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3) with ESMTP id VAA18281 for <mason@werple.mira.net.au>; Tue, 28 May 1996 21:58:51 +1000 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id HAA09217; Tue, 28 May 1996 07:46:39 -0400 (EDT)
Resent-Date: Tue, 28 May 1996 07:46:39 -0400 (EDT)
From: Zoltan Hidvegi <hzoli@cs.elte.hu>
Message-Id: <199605281144.NAA19014@turan.elte.hu>
Subject: Re: zsh and portability
To: coleman@math.gatech.edu (Richard Coleman)
Date: Tue, 28 May 1996 13:44:04 +0200 (MET DST)
Cc: zsh-workers@math.gatech.edu
In-Reply-To: <199605272316.TAA12028@redwood.skiles.gatech.edu> from Richard Coleman at "May 27, 96 07:16:33 pm"
Organization: Dept. of Comp. Sci., Eotvos University, Budapest, Hungary
Phone: (36 1)2669833 ext: 2667, home phone: (36 1) 2752368
X-Mailer: ELM [version 2.4ME+ PL15 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"2zf2X2.0.xF2.UUkgn"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/1210
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

> There been a lot of talk in the last couple of days about
> various assumptions that zsh makes (NULL has all zero bits,
> or char has 8 bits, etc..).
> 
> My suggestion would be to not worry too much about such things unless
> they become a problem.  I want zsh to be portable as well, but not at
> the expense of needlessly complicating the code for machines that zsh
> will probably not run on anyway.
> 
> In any portable unix software, you must make assumptions that are not
> guaranteed by any standard (ANSI C, POSIX, whatever).  I don't think
> anything is wrong with this (withing reason).  If the code is kept
> clean and well documented, and someone REALLY wants to run zsh on an
> OS that goes against these assumptions, then they could can port it
> themselves without too much trouble.
> 
> I think time could be better spent documenting the assumptions that
> are made, rather than adding more complexity in the name of
> portability.
> 
> Remember.  Keep things as simple as possible.  I will of course,
> repeat this mantra on a regular basis.

I agree, but if a change is simple and trivial, and improves portability
than it would be usefull to add.

Also I think that in the near future there will be systems where
sizeof(long) > sizeof(void*).  The other problems will probably not come up
on modern systems but this one has to be handled somehow.  In other words
we need a portable method to initialise a union.

Zoltan