Hi, I can also understand that typecasting, that is, bypassing strict type checking, a void pointer without checking for architecture is like a time bomb. Addresses on different architectures can be different sizes and a typecast of void from an integer requires some conditions that must be true. Both void* and integer must have the same size on the target machine or code is written in a way to make sure a difference in architecture does not result in code being broken.
Edward On 30/03/2016, Edward Bartolo <edb...@gmail.com> wrote: > Hi and many thanks for the replies, > > I can understand that a pointer being an address depends heavily on > machine architecture which means, on 32 bit machines it is 4 bytes > long and on 64 bit machines it is 8 bytes long. I also understand that > a pointer variable is essentially made of two parts as illustrated > below: > > address [always allocated] ------------------> data [not allocated > automatically] > > The address does depend on architecture but the data? And what else > can enter into a pointer's definition other than what I illustrated? > > Compound/complex pointer definitions like data_type** U, work as > follows as far as my intellect can reason and deduce from what I > studied and from my now long experience coding. > > address1[allocated] -----> address2[NOT allocated] -----> > data_type[not allocated] > > My mistake was to assume in the case of data_type** U the compiler > would allocate the two addresses and link them, that is, store the > address of address2 in address1. The latter is not the case and a > coder is required to first allocate space for the 2nd address. In > fact, allocating space for void** ptr, in a sample program worked > without issues. I am attaching this sample program. > > Edward > > On 29/03/2016, Rainer Weikusat <rainerweiku...@virginmedia.com> wrote: >> Hendrik Boom <hend...@topoi.pooq.com> writes: >>> On Tue, Mar 29, 2016 at 02:46:50PM +0100, Rainer Weikusat wrote: >>>> This is a wrong assumption and it relies on behaviour the C standard >>>> doesn't guarantee. Any pointer may be converted (it's even converted >>>> automatically as required) to a void * and back and >>>> >>>> "the result shall compare equal to the original pointer" >>>> >>>> But a pointer to a void * is an entirely different animal and no such >>>> guarantees are made for that. This will work in practice if there's >>>> only >>>> one 'machine pointer type' anyway, though. But using it is not >>>> necessary >>>> as void * is sufficient. >>> >>> Last time I looked at the C standard (which was a while ago, things may >>> have changed) function pointers were not guaranteed to be >>> interconvertable with data pointers. >> >> Indeed. I didn't remember this while writing the text. >> _______________________________________________ >> Dng mailing list >> Dng@lists.dyne.org >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng