Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: Is this really necessary Date: Sun, 06 Jun 2021 18:49:43 -0700 Organization: None to speak of Lines: 63 Message-ID: <87y2bmphoo.fsf@nosuchdomain.example.com> References: <87r1hevbc8.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="da0ef0006e1a2be3c584df7adb5e6866"; logging-data="8041"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/V6PVQdzIcutXNp77cV3mb" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:JIxEgd4umuMbb7bLB6tGPiTpMpQ= sha1:KyLcf5k4ROx1l18Jr8LtIEibS6M= Xref: csiph.com comp.lang.c++:80206 Richard Damon writes: > On 6/6/21 7:10 PM, Keith Thompson wrote: >> Paavo Helde writes: >>> 05.06.2021 16:06 Bonita Montero kirjutas: >>>>> No.  Subtraction of pointers is defined as the difference in their >>>>> indexes within a single array. >>>> >>>> That coudn't be true because you can cast any pointer-pair >>>> to char *, subtract them and use the difference for memcpy(). >>> >>> This holds only for linear memory model. While this is a dominant >>> memory model nowadays, the C++ language is old enough to take also >>> other memory models (like segmented ones) into account. In segmented >>> memory models, pointer arithmetic only works in a single segment, and >>> accordingly the arrays are limited to a single segment. There is no >>> such limitation for struct members. >> >> I believe there is. Without that limitation, the offsetof macro >> wouldn't work. >> >>> As an example, with Intel 386 you could have a 16-bit program working >>> simultaneously with at least 4 different 64 kB segments, which might >>> have been fully separate in the physical memory. Good luck with >>> forming a difference of pointers in a 16-bit size_t variable when the >>> segments are more than 64kB separate in the physical memory! >> > > Actually, one reason offsetof is a Standard Macro so it can be made to > use implementation dependent tricks to make it work here. > > The implementation has enough information to handle a bigger than a > segment structure if it wanted to. It might only be able to make it work > easily for 'real' mode where segments offset from the current segment > can just be computed, or it might need special support from the OS to > make multiple overlapping segments to build a net address space bigger > than one segment long. > > If you reference an member of the structure whose offset is big enough > that it won't fit in the first segment of the structure, the > implementation just needs to make a segment offset from the start of the > object that does hold that full member. > > I will say that I never heard of a compiler that did that for a > structure, there were implementation that did that for specified arrays, > but pointers to elements of that array had a non-standard type to keep > track of the fact that segment updates might be needed for pointer > arithmetic. These weree __huge__ arrays, with __huge__ pointers. Sure, and it can do the same thing for arrays. Both array objects and struct objects has to *act like* they occupy a contiguous range of memory addresses. If the implementation has to play some tricks to make it act that way, that's fine. And if it restricts object to a single segment, that's fine too (as long as the segment size is big enough -- 65535 bytes for hosted implementations, C99 and later). And if an implementation plays tricks for arrays but not for structures, that's probably fine too. The standard doesn't mention segments. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */