Edward, the only time the compiler allocates memory for data automatically is when using strings literals (as stated by Rainer previously)
char *p = "Hola mundo." This is because strings are a special case. https://www.cs.uic.edu/~jbell/CourseNotes/C_Programming/CharacterStrings.html On Wed, Mar 30, 2016 at 4:16 AM, 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 > >
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
