Xref: utzoo comp.lang.c:8648 comp.arch:4122
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Bit Addressable Architectures
Message-ID: <7578@brl-smoke.ARPA>
Date: 29 Mar 88 13:39:42 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> <504@sol.warwick.ac.uk>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 21

In article <504@sol.warwick.ac.uk> cudcv@cu.warwick.ac.uk (Rob McMahon) writes:
>I wonder how much code out there assumes that ...
>sizeof("constant string"), or sizeof(initialised_char_array)
>is the same as strlen(xx)+1 ?

There's a lot of code like that, no question.  It would continue to
work if sizeof(char) were allowed to be other than 1, on most current
systems, although it might not be portable to other systems or to
future compiler releases.

>Does malloc now take number of bits required, or char's ?

malloc() would be told the number of "bytes" required, where
sizeof(byte)==1.  By "byte" I mean the smallest addressable storage
unit, not necessarily 8 bits in size, nor 1 bit, nor big enough to
represent a character.  (In my proposal this was a "short char".)

Your concerns are legitimate, but so are those of programmers
who have to deal with so-called multi-byte character representations.
Anyway, X3J11 did not buy into the "short char" idea and I doubt they
will be willing to change to it now.