Re: [DNG] Making sense of C pointer syntax.

[Ulf-Rainer Tietz]

On 2016-03-28 06:50:38 +, Edward Bartolo said:


Hi,

As the title of the email indicates, I am doing some exercises to make
sense out of C pointer syntax. I have been using pointers for as long
as I have been programming without issues, apart from the usual
initial programmatic errors when new code is run for the first time.
However, C pointer syntax is proving to be as unintuitive as it can
be. For this reason, I am doing some exercises regarding C pointer
use.

I am attaching two short C programs that I created and which I tested
to work although the mechanism by which they work is still somewhat
hazy to me. Both programs use a function to change the value of a
parameter. I want to understand, as opposed to knowing by rote, the
mechanism why they work. Please note that I didn't consult any books
to create the pointers. This is because I have already the concepts,
but I cannot make sense, as in deeply understanding the details, of
pointer syntax as used in C.

Edward

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Hi,
If you read the Usenet time Comp Lang C FAQ by Steve Summit you will 
find many answers and learn a lot about the C language. This helped me 
plenty coming from many asm languages.

https://www.eskimo.com/~scs/___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Rainer Weikusat]

Edward Bartolo  writes:

> Hi, thanks for your help.
>
> So: [ I am recalling this from memory to test where I am ]
> a)  type* pp; // declare a pointer pp
> b) *pp = RHS; // assign RHS to the data pointed to by pp
> c) type **ss; // declare a pointer to pointer. System only allocates
> space for one address

(1) Background
--

The C type system is built around the idea that certain kind of types can be
derived from already existing types. These are pointers, arrays (and
functions, but I'm going to omit them for simplicity). Eg, assuming type
identifies and existing type,

type *pt

declares a pointer to objects of type type and

type at[3];

declares an array of objects of type type. When an object is defined,
the system allocates storage for it in some suitable location, eg, on
the stack or by reserving a register.

(2)Typedef names


It's possible to create a new name for an existing type with the help of
typedef, eg, after

typedef int *pint;

pint can be used as type name to mean 'pointer to int'. Eg,

pint pi;

would define an object of type 'pointer to int' (the compiler will
allocate storage for).

Pulling this together
-

Assuming pint is declared as above. As per (1), new types can now
derived from it, eg,

pint *ppi; /* "Dear customer ..." */

This defines a "pointer to pint", hence, the system allocates storage
for one. But that's really the same as

int **ppi;

which is handled in exactly the same way: An object with a pointer type
derived from some existing type is defined. Hence, storage for a pointer
is reserved. That the existing type is itself a pointer type doesn't
matter, for the given purpose, it's just 'some type'.


> f) strings are character arrays, so they obey the rules governing arrays

They're really pointers to character arrays. Because an array is
converted to a pointer to its first element most of the time, a
character array, say

char chars[] = "12345";

can be used as if it had been declared as a pointer. There's one
important difference:

char chars[] = "12345";

cause the compiler to reserve six bytes (five chars + terminating 0) in
some location the program can write to. Afterwards,

*chars = R;

could be used to change the string to R2345. In contrast to this.

char *chars = "12345";

causes the compiler to allocate storage for a writable char * and
initialize that with the address of a string literal which is not
required to be (and usually won't be) writeable.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Edward Bartolo]

Hi, thanks for your help.

So: [ I am recalling this from memory to test where I am ]
a)  type* pp; // declare a pointer pp
b) *pp = RHS; // assign RHS to the data pointed to by pp
c) type **ss; // declare a pointer to pointer. System only allocates
space for one address
d) *ss = RHS; // assign RHS to the pointer pointed to by ss.
e) const char* and char* are not the same ie treated differently by the compiler
f) strings are character arrays, so they obey the rules governing arrays
g) strings are terminated by a null character which is a byte with eight zeros
h) extra care must be taken when copying strings not to write beyond
the end of allocated memory. This can result in buffer overflows that
may cause execution of arbitrary code
i) some built in string function provided by C, especially vintage
string functions, suffer from the buffer overrun bug. Guard against
that by making sure there is enough memory allocated.
j) When calling backend CLI programs make sure, the input to the
calling function cannot be maliciously modified to allow execution of
arbitrary commands. Functions like execl can be abused so extra care
to block abuse must be taken.

Edward

On 30/03/2016, Steve Litt  wrote:
> On Wed, 30 Mar 2016 08:23:16 -0300
> Emiliano Marini  wrote:
>
>> 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."
>
> Also when you have a struct as a local variable:
>
> struct my_cool_struct mystruct;
>
> Like the char pointer, it comes off the stack, not the heap it would
> come off if you used malloc().
>
> Actually, any local variable allocates memory off the stack. Consider:
>
> int number_of_people;
>
> The preceding allocates sizeof(int) bytes, for number_of_people, off
> the stack.
>
> SteveT
>
> Steve Litt
> March 2016 featured book: Quit Joblessness: Start Your Own Business
> http://www.troubleshooters.com/startbiz
> ___
> 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] https://files.devuan.org/

[p]

Hi,my web browser can't establish a connection to the server at files.devuan.org.
 
thank,
p

 


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Steve Litt]

On Wed, 30 Mar 2016 08:23:16 -0300
Emiliano Marini  wrote:

> 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."

Also when you have a struct as a local variable:

struct my_cool_struct mystruct;

Like the char pointer, it comes off the stack, not the heap it would
come off if you used malloc().

Actually, any local variable allocates memory off the stack. Consider:

int number_of_people;

The preceding allocates sizeof(int) bytes, for number_of_people, off
the stack.

SteveT

Steve Litt 
March 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Red pill for me, & thx!

[Steven W. Scott]

Greets all,
 After experiencing a serious disk failure on my server's os drive, I
decided it was time for Devuan - Alpha2 worked flawlessly for me as a vm,
so I grabbed the Aplha 4 net install iso and went to work.

  I personally liked the red install screen, a nice contrast to the
him-drum placid blue from upstream. As my usual approach, I dont install
anything beyond sshd, apache, mysql, and build tools, but since I run with
numerous additional drives, I have some pretty specific partitioning &
mounting requirements.

  Install was again, flawless for me. Up and running in less than 30 min,
Virtualbox and VMs all going in another 15, even managed to get Plex media
server running from a dissected Ubuntu .deb with a little help from this
init.d script on the Plex forums -
https://forums.plex.tv/discussion/51427/plex-media-server-for-debian

  It's been running for a couple of weeks now without issue, please
consider me a very satisfied customer.

  I also have some cloud resources I would love to go red on, but I dont
think the provider will consider adding Devuan to their available builds if
its not an official release. Does anyone have some insight as to when that
might occur?

So nice not to see all that systemd bloat. Many thanks and prosperity
to all!

SWS
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] files.devuan.org not working

[Go Linux]

On Tue, 3/29/16, Linux O'Beardly  wrote:

 Subject: Re: [DNG] files.devuan.org not working
 To: "Jaromil" 
 Cc: "dng" 
 Date: Tuesday, March 29, 2016, 6:01 PM
 
Do we know when this will be fixed? It's really hard to spread the gospel of 
Devuan if my disciples can't get to the source of enlightenment.

Linux O'Beardly
@LinuxOBeardly
http://o.beard.ly
linux.obear...@gmail.com



This link is informative:

https://community.letsencrypt.org/t/rate-limits-for-lets-encrypt/6769

Seems there should be a way to work this out with Let's Encrypt.   I don't know 
much about certificates but I do know a thing or two about consumer action . . 
.   ;)

golinux

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Hendrik Boom]

On Wed, Mar 30, 2016 at 09:16:22AM +0200, Edward Bartolo 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?

Some machines (I'm thinking of, say, the PDP-10, which had a 36-bit 
wors soze, and, if I remember correctly, eighteen-bit addresses) found 
that it was good to stuff many characters into a single addressible 
machine word.  I think the PDP-10  stuffed five seven-bit characters 
into a word, leaving the sign bit unmolested.  But sometime it was 
necessary to address intividual characters within a word.  To this 
eend, they made special character pointers, which were a few bits 
longer than a regular address.  So character pointers were not the same 
size as regular pointers.

There are have also been systems where a function pointer has two 
compononts -- the address of the code to be executed and the address of 
the environment the function is to operate in.  There are historical 
reasos for that (mostly having to do with programming language that are 
not C), but on machines designed for that, function pointers will be 
bigger than  data pointers.

But C is part of the legacy of 8-bit bytes and byte-addressable 
machines.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] files.devuan.org not working

[hellekin]

On 03/30/2016 02:46 PM, parazyd wrote:
> 
> For what it's worth, it is now upped to 30 certs.
> 

Yes, it upped just after--like hours after--the first generation of our
certificates :(

==
hk

-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] files.devuan.org not working

[parazyd]

On Wed, 30 Mar 2016, Jaromil wrote:

> On Tue, 29 Mar 2016, Linux O'Beardly wrote:
> 
> >Do we know when this will be fixed? It's really hard to spread the gospel
> >of Devuan if my disciples can't get to the source of enlightenment.
> 
> yes its a matter of days
> 
> let's encrypt doesn't emits more than 5 certificates for vhosts of the
> same domain each week...

For what it's worth, it is now upped to 30 certs.


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] files.devuan.org not working

[Jaromil]

On Tue, 29 Mar 2016, Linux O'Beardly wrote:

>Do we know when this will be fixed? It's really hard to spread the gospel
>of Devuan if my disciples can't get to the source of enlightenment.

yes its a matter of days

let's encrypt doesn't emits more than 5 certificates for vhosts of the
same domain each week...

ciao

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Emiliano Marini]

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  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  wrote:
> > Hendrik Boom  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

Re: [DNG] Making sense of C pointer syntax.

[Emiliano Marini]

+1

On Wed, Mar 30, 2016 at 5:04 AM, KatolaZ  wrote:

> On Wed, Mar 30, 2016 at 09:16:22AM +0200, Edward Bartolo 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?
> >
>
> Hi Edward,
>
> sorry but your description is incorrect. A pointer in C is just a
> variable large enough to contain a memory address. Period. There is no
> explicit or implicit linking between a pointer (which is a variable
> large enough to contain a memory address) and the area of memory it
> points to. You may have several pointers pointing to the same memory
> area. You can have the same pointer (i.e., the same named variable
> able to contain a memory address) pointing to different memory areas
> at different times. You can use a pointer to wander around an
> allocated memory area at your will, changing its value by using the
> powerful pointer arithmetic provided by C. You can also have some
> allocated memory area for which you don't have any pointer at all (and
> this is what is called a "memory leak", and you should avoid it).
>
> Also, memory areas are not "typed" in C, meaning that you can in
> principle access a correctly allocated memory area with pointers of
> any type, the only problem being the semantics of pointer arithmetics,
> which is entirely left to the programmer.
>
> But please forget any implicit linkage between a pointer (the
> variable) and the memory area it points to (i.e., the address
> contained in that variable), as you don't assume any intrinsic link
> between an integer variable and the possible values that the variable
> can contain. If you don't break this spell, you will never get around
> with C pointers.
>
> Pointers are just variables which are able to contain memory
> addresses. What you put in those variables does not bother them in any
> discernible way. And shouldn't bother you either, as long as you be
> careful in using them to refer to correctly allocated memory. SIGSEGV
> is the alternative.
>
> My2Cents
>
> KatolaZ
>
> --
> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
> ___
> 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

Re: [DNG] Popularity-contest for Devuan

[Patrick Erdmann]

I never participated at the popularity contest but i think a bit
engagement at that would get us a better status in the debian crew.

So i just installed "popularity-contest" and i hoped thats enough?

On 30.03.2016 11:51, Rob wrote:
> 
>>  Original Message 
>> Subject: Re: [DNG] Popularity-contest for Devuan
>> Local Time: 30 March 2016 5:04 AM
>> UTC Time: 30 March 2016 04:04
>> From: dan...@centurion.net.nz
>> To: dng@lists.dyne.org
>>
>>
>> >>
>> > Don't know if this is related to the repo issues or something wrong this
>> > end but I get the following from Cron Daemon
>> >
>> > Subject: Cron test -x /etc/cron.daily/popularity-contest
>> >  &&
>> > /etc/cron.daily/popularity-contest
>> >  --crond
>> >
>> > gpg: 4383FF7B81EEE66F: skipped: public key not found
>> > gpg: /var/log/popularity-contest.new: encryption failed: public key not
>> > found.
>> >
>> > thanks
>> >
>> > Rob
>> >
>>
>> what version of popularity-contest do you have installed?
>>
>>
>> -- 
>> Daniel Reurich
>> Centurion Computer Technology (2005) Ltd.
>> 021 797 722
>>
>>
>  
> 1.64-4+devuan.ceres
> 
> Rob
> 
> 
> 
> ___
> 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

Re: [DNG] Popularity-contest for Devuan

[Rob]

 Original Message 
Subject: Re: [DNG] Popularity-contest for Devuan
Local Time: 30 March 2016 5:04 AM
UTC Time: 30 March 2016 04:04
From: dan...@centurion.net.nz
To: dng@lists.dyne.org


>>
> Don't know if this is related to the repo issues or something wrong this
> end but I get the following from Cron Daemon
>
> Subject: Cron test -x /etc/cron.daily/popularity-contest
>  &&
> /etc/cron.daily/popularity-contest
>  --crond
>
> gpg: 4383FF7B81EEE66F: skipped: public key not found
> gpg: /var/log/popularity-contest.new: encryption failed: public key not
> found.
>
> thanks
>
> Rob
>

what version of popularity-contest do you have installed?


--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722



1.64-4+devuan.ceres

Rob___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[KatolaZ]

On Wed, Mar 30, 2016 at 09:26:32AM +0200, Edward Bartolo wrote:
> 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.
> 

void* and int happen to have the same size in i386 architectures, but
this is not always true. There is no implied correspondence between
void* and int that I am aware of. In my amd64 machine, all pointers
are 8 bytes, but an int is 4 bytes long.

Please do not make assumptions about the length of a pointer. The
typecasting referred before was *between pointers*, and not between
pointers and other types. This means that you can cast a void* to a
char* or to an int**, but not that you can cast a void* to a char.

Also, pointer arithmetic is defined (to the best of my knowledge) only
on typed pointers, so that something like:
 
  void *a;
  a = a +1;

is not meaningful (and I bet you should get a compile-time error),
while:

  void *a;
  a = (int*) a + 1;

is perfectly valid, and widely used.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[KatolaZ]

On Wed, Mar 30, 2016 at 09:16:22AM +0200, Edward Bartolo 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?
> 

Hi Edward, 

sorry but your description is incorrect. A pointer in C is just a
variable large enough to contain a memory address. Period. There is no
explicit or implicit linking between a pointer (which is a variable
large enough to contain a memory address) and the area of memory it
points to. You may have several pointers pointing to the same memory
area. You can have the same pointer (i.e., the same named variable
able to contain a memory address) pointing to different memory areas
at different times. You can use a pointer to wander around an
allocated memory area at your will, changing its value by using the
powerful pointer arithmetic provided by C. You can also have some
allocated memory area for which you don't have any pointer at all (and
this is what is called a "memory leak", and you should avoid it).

Also, memory areas are not "typed" in C, meaning that you can in
principle access a correctly allocated memory area with pointers of
any type, the only problem being the semantics of pointer arithmetics,
which is entirely left to the programmer.

But please forget any implicit linkage between a pointer (the
variable) and the memory area it points to (i.e., the address
contained in that variable), as you don't assume any intrinsic link
between an integer variable and the possible values that the variable
can contain. If you don't break this spell, you will never get around
with C pointers.

Pointers are just variables which are able to contain memory
addresses. What you put in those variables does not bother them in any
discernible way. And shouldn't bother you either, as long as you be
careful in using them to refer to correctly allocated memory. SIGSEGV
is the alternative.

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Edward Bartolo]

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  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  wrote:
>> Hendrik Boom  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

Re: [DNG] Making sense of C pointer syntax.

[Edward Bartolo]

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  wrote:
> Hendrik Boom  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
>
#include 
#include 

typedef enum {t_int, t_float, t_double, t_long_double} t_data;

int alloc_datum(void** datum, t_data type) {
  //if (*datum != NULL) return 2; // non null *datum
  switch (type) {
	  case t_int: 
		  *datum = malloc(sizeof(int));
			break;
		case t_float:
		  *datum = malloc(sizeof(float));
			break;
		case t_double:
		  *datum = malloc(sizeof(double));
		  break;
		case t_long_double:
		  *datum = malloc(sizeof(long double));
			break;			
  }

	if (datum == NULL)
	  return 1; // malloc failed to allocate memory
		else return 0;
}

int main() {
  int* ii;
	long* ll;
	float* ff;
	double* dd;
	long double* ;
	
	void** ptr;
	ptr = malloc(sizeof(void*));
	
	
	alloc_datum(ptr, t_int);
	ii = *ptr;
	*ii = 10;
	alloc_datum(ptr, t_float);
	ff = *ptr;
	*ff = 5.97E24;
	alloc_datum(ptr, t_double);
	dd = *ptr;
	*dd = 2E30;
	alloc_datum(ptr, t_long_double);
	 = *ptr;
	* = 1.5E299;
	free(ptr);
	
	printf("*11 is %d\n", *ii);
	printf("*ff is %e\n", *ff);
	printf("*dd is %e\n", *dd);
	printf("* is %Le\n", *);
	
	free(ii);
	free(ff);
	free(dd);
	free();

  return 0;
}___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng