:: Re: [DNG] Making sense of C pointer…
Top Page
Delete this message
Reply to this message
Author: Emiliano Marini
Date:  
To: Edward Bartolo
CC: dng
Subject: Re: [DNG] Making sense of C pointer syntax.
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 <edbarx@???> 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 <rainerweikusat@???> wrote:
> > Hendrik Boom <hendrik@???> 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@???
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >
>
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>