Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Bo Persson Newsgroups: comp.lang.c++ Subject: Re: Examples of current platforms/architectures where sizeof(void*) > sizeof(int*) ? Date: Wed, 1 Sep 2021 10:28:07 +0200 Lines: 37 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net Gw8bG2Uyq84BhdrPm2c7PgMczMrZZBSlAR+godeo2wcZyuApMe Cancel-Lock: sha1:xVbALxGhTIEfhTNaj9kX3QUvtU0= User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 In-Reply-To: Content-Language: sv Xref: csiph.com comp.lang.c++:80950 On 2021-09-01 at 08:03, Bonita Montero wrote: > Am 01.09.2021 um 07:41 schrieb Christian Gollwitzer: >> Am 01.09.21 um 07:26 schrieb Bonita Montero: >>> Am 01.09.2021 um 06:42 schrieb Juha Nieminen: >>>> Bonita Montero wrote: >>>>> Am 29.08.2021 um 20:57 schrieb Alf P. Steinbach: >>>>>> Are there any examples of current platforms/architectures where >>>>>> sizeof(void*) > sizeof(int*) ? >>>>> >>>>> Why should there be such an architecture ? >>>>> On such an architecture you won't be able >>>>> to cast the result of malloc() to an int * >>>> >>>> Why not? If void* is larger than int*, why couldn't you cast a >>>> void* to an int*? >>> >>> Because it would drop information and f.e. you won't be able to >>> access the int-arrray behind the int *. >>> >> >> I think you misunderstand how that works. The int pointer would not >> count in bytes, but in ints. So if you do ptr++, then it would >> actually increase by 1 - not by 4 or 8 as it does on the usual >> platforms, where there is no difference between int*, char*, void* on >> the machine code level. > > Name an architecture of the last three decades that behaves like that. Not designed lately, but still in use. Unisys offered their Burroughs and Univac mainframes well into the 2010's. Here is a manual for their 36-bit C-compiler from 2014 https://public.support.unisys.com/2200/docs/cp16.0/pdf/78310422-012.pdf