Xref: utzoo comp.lang.c:8619 comp.arch:4109
Path: utzoo!mnetor!uunet!mcvax!ukc!warwick!cudcv
From: cudcv@daisy.warwick.ac.uk (Rob McMahon)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Bit Addressable Architectures
Message-ID: <504@sol.warwick.ac.uk>
Date: 26 Mar 88 18:58:12 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <1988Mar6.002518.945@utzoo.uucp> <2760@mmintl.UUCP> <17458@watmath.waterloo.edu>
Reply-To: cudcv@cu.warwick.ac.uk (Rob McMahon)
Organization: Computing Services, Warwick University, UK
Lines: 23

Newsgroups: comp.lang.c,comp.arch
Subject: Re: Bit Addressable Architectures
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <1988Mar6.002518.945@utzoo.uucp> <2760@mmintl.UUCP> <17458@watmath.waterloo.edu>
Reply-To: cudcv@titania.warwick.ac.uk (Rob McMahon)
Distribution: 
Organization: Computing Services, Warwick University, UK

In article <17458@watmath.waterloo.edu> ccplumb@watmath.waterloo.edu (Colin Plumb) writes:
>Backwards compatibility?  With a C compiler insulating the user, the
>only change is that sizeof(char) is now 8.

Only change ?  Sounds like a big "only" to me.  I wonder how much code
out there assumes that sizeof(char) == 1, that sizeof("constant string"), 
or sizeof(initialised_char_array) is the same as strlen(xx)+1 ?  Does
malloc now take number of bits required, or char's ?  It's going to
break either "malloc(n * sizeof(s))" or "malloc(strlen(s) + 1)", or does
everybody but me write "malloc((strlen(s)+1)*sizeof(char))" ?

Rob
-- 
UUCP:   ...!mcvax!ukc!warwick!cudcv	PHONE:  +44 203 523037
JANET:  cudcv@uk.ac.warwick.cu          ARPA:   cudcv@cu.warwick.ac.uk
Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England