:: Re: [DNG] Making sense of C pointer…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Edward Bartolo
Date:  
À: Rainer Weikusat
CC: dng
Sujet: Re: [DNG] Making sense of C pointer syntax.
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 <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
>>
>