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

2016-05-26 Thread Edward Bartolo
Hi, Thanks for the feedback. I applied the suggested changes to Makefile and git push-ed to repository. There is still a non-fatal error about linking against unnecessary libraries that has to be debugged. I will git push as soon as I find a solution. Edward On 25/05/2016, aitor_czr wrote: > >

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

2016-05-25 Thread aitor_czr
El 25/05/16 a las 10:50, aitor_czr escribió: Hi Edward, El 29/03/16 a las 00:58, Edward Bartolo escribió: I found using the return value of a function makes code much more >readable and probably more reliable. Multiple return values can be >encapsulated inside a structure which would be retur

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

2016-05-25 Thread aitor_czr
Hi Edward, El 29/03/16 a las 00:58, Edward Bartolo escribió: I found using the return value of a function makes code much more >readable and probably more reliable. Multiple return values can be >encapsulated inside a structure which would be returned by a function. >I used this construct in s

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

2016-04-15 Thread Edward Bartolo
Hi, Again, thanks for taking some of your time to explain this to me. Sorry for not replying immediately. The past two weeks I couldn't use any of my computers. Edward On 03/04/2016, KatolaZ wrote: > On Sat, Apr 02, 2016 at 02:30:24PM -0400, Steve Litt wrote: > > [cut] > >> >> > You never retur

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

2016-04-03 Thread KatolaZ
On Sat, Apr 02, 2016 at 02:30:24PM -0400, Steve Litt wrote: [cut] > > > You never return a > > pointer to an automatic variable, > > How'd you learn that? I learned that by this particular incident, and I > *NEVER* did that again. > The answer to your question is always the same: I think I l

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

2016-04-02 Thread Steve Litt
On Sat, 2 Apr 2016 10:55:53 +0100 KatolaZ wrote: > On Fri, Apr 01, 2016 at 07:34:02PM -0400, Steve Litt wrote: > > [cut] > > > > > > > = > > char * read_bbs(){ > > char rtrn[WAY_BIGGER_THAN_EVER_NEEDED]; > > strcpy(rtrn, grab_bbs_par

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

2016-04-02 Thread Rainer Weikusat
aitor_czr writes: > On 03/31/16 16:07, KatolaZ wrote: >> On Thu, Mar 31, 2016 at 03:58:49PM +0200, aitor_czr wrote: >> >> [cut] >> > >On Wed, Mar 30, 2016 at 6:04 PM, Rainer Weikusat < > >rainerweiku...@virginmedia.com> wrote: > > > >There's one > > >>important difference:

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

2016-04-02 Thread Hendrik Boom
On Sat, Apr 02, 2016 at 10:55:53AM +0100, KatolaZ wrote: > On Fri, Apr 01, 2016 at 07:34:02PM -0400, Steve Litt wrote: > > [cut] > > > > > > > = > > char * read_bbs(){ > > char rtrn[WAY_BIGGER_THAN_EVER_NEEDED]; > > strcpy(rtrn, grab_b

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

2016-04-02 Thread KatolaZ
On Fri, Apr 01, 2016 at 07:34:02PM -0400, Steve Litt wrote: [cut] > > > = > char * read_bbs(){ > char rtrn[WAY_BIGGER_THAN_EVER_NEEDED]; > strcpy(rtrn, grab_bbs_part1()); > strcat(rtrn, grab_bbs_part2()); > return(rtrn); > } > > r

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

2016-04-01 Thread Steve Litt
On Thu, 31 Mar 2016 13:53:08 +0100 KatolaZ wrote: > But be careful with statically initialised strings, > since they are effectively constant char pointers (they are stored in > the current stack frame, not in the heap, and the address stored in > such variables cannot be modified, AFAIR). Thi

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

2016-03-31 Thread Hendrik Boom
On Thu, Mar 31, 2016 at 03:58:49PM +0200, aitor_czr wrote: > Hi, > > On 03/31/16 13:38, Emiliano Marini wrote: > >Besides, * and [] are interchangeable. You can define a string as an array > >and use it later as a pointer: > > > >char s[] = "hola"; > >char x = s[1]; // Here x = 'o' > >char y

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

2016-03-31 Thread Hendrik Boom
On Thu, Mar 31, 2016 at 03:18:17PM +0100, KatolaZ wrote: > On Thu, Mar 31, 2016 at 03:12:32PM +0200, Edward Bartolo wrote: > > Hi, thanks for taking time to reply, > > > > KatolaZ wrote: > > >> c) type **ss; // declare a pointer to pointer. System only allocates > > >> space for one address > > >

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

2016-03-31 Thread KatolaZ
On Thu, Mar 31, 2016 at 03:12:32PM +0200, Edward Bartolo wrote: > Hi, thanks for taking time to reply, > > KatolaZ wrote: > >> c) type **ss; // declare a pointer to pointer. System only allocates > >> space for one address > > > C pointers are *always* one variable, precisely a variable large > >

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

2016-03-31 Thread aitor_czr
On 03/31/16 16:07, KatolaZ wrote: On Thu, Mar 31, 2016 at 03:58:49PM +0200, aitor_czr wrote: [cut] > >On Wed, Mar 30, 2016 at 6:04 PM, Rainer Weikusat < > >rainerweiku...@virginmedia.com> wrote: > > > >There's one > >>important difference: > >> > >>char chars[] = "12345"; > >> > >>cause the c

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

2016-03-31 Thread karl
Edward Bartolo: > KatolaZ wrote: > >> c) type **ss; // declare a pointer to pointer. System only allocates > >> space for one address > > > C pointers are *always* one variable, precisely a variable large > > enough to store a memory address on the current architecture. > > I think, I did not und

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

2016-03-31 Thread KatolaZ
On Thu, Mar 31, 2016 at 03:58:49PM +0200, aitor_czr wrote: [cut] > >On Wed, Mar 30, 2016 at 6:04 PM, Rainer Weikusat < > >rainerweiku...@virginmedia.com> wrote: > > > >There's one > >>important difference: > >> > >>char chars[] = "12345"; > >> > >>cause the compiler to reserve six bytes (five cha

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

2016-03-31 Thread aitor_czr
Hi, On 03/31/16 13:38, Emiliano Marini wrote: Besides, * and [] are interchangeable. You can define a string as an array and use it later as a pointer: char s[] = "hola"; char x = s[1]; // Here x = 'o' char y = *(s+2); // Here y = 'l' And vice versa: char *s = "hola"; char x = s[0];

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

2016-03-31 Thread Edward Bartolo
Hi, thanks for taking time to reply, KatolaZ wrote: >> c) type **ss; // declare a pointer to pointer. System only allocates >> space for one address > C pointers are *always* one variable, precisely a variable large > enough to store a memory address on the current architecture. I think, I did n

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

2016-03-31 Thread KatolaZ
On Thu, Mar 31, 2016 at 08:38:26AM -0300, Emiliano Marini wrote: > +1 > > Besides, * and [] are interchangeable. You can define a string as an array > and use it later as a pointer: > > char s[] = "hola"; > char x = s[1]; // Here x = 'o' > char y = *(s+2); // Here y = 'l' > > And vice vers

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

2016-03-31 Thread Hendrik Boom
On Thu, Mar 31, 2016 at 08:38:26AM -0300, Emiliano Marini wrote: > +1 > > Besides, * and [] are interchangeable. You can define a string as an array > and use it later as a pointer: > > char s[] = "hola"; > char x = s[1]; // Here x = 'o' > char y = *(s+2); // Here y = 'l' > > And vice vers

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

2016-03-31 Thread KatolaZ
On Wed, Mar 30, 2016 at 10:40:37PM +0200, Edward Bartolo wrote: > 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 This is a bit fishy, and should be taken wi

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

2016-03-31 Thread Emiliano Marini
+1 Besides, * and [] are interchangeable. You can define a string as an array and use it later as a pointer: char s[] = "hola"; char x = s[1]; // Here x = 'o' char y = *(s+2); // Here y = 'l' And vice versa: char *s = "hola"; char x = s[0]; // Here x = 'h' char y = *(s+3); // Here y

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

2016-03-31 Thread Emiliano Marini
Exactly, any local variable comes off the stack, but I was talking about pointers :) On Wed, Mar 30, 2016 at 3:37 PM, 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 usin

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

2016-03-30 Thread 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 ne

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

2016-03-30 Thread 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 o

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

2016-03-30 Thread 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

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

2016-03-30 Thread 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

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

2016-03-30 Thread 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 als

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

2016-03-30 Thread 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, M

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

2016-03-30 Thread 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

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

2016-03-30 Thread 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 t

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

2016-03-30 Thread 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 als

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

2016-03-30 Thread 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.

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

2016-03-30 Thread 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 i

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

2016-03-29 Thread Rainer Weikusat
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

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

2016-03-29 Thread Hendrik Boom
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

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

2016-03-29 Thread aitor_czr
Hi Edward, On 03/29/16 16:34, Edward Bartolo wrote: Is this allowed: void***, int***, double***, etc? Yes, this is allowed. Imagine them like the tensors in algebra: there is no limitation in the number of indices. Aitor. ___ Dng mailing list Dng

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

2016-03-29 Thread Rainer Weikusat
Steve Litt writes: > On Mon, 28 Mar 2016 13:57:08 -0300 > Emiliano Marini wrote: > >> char *p; >> p="01234"; /* skeezy, but makes the point */ >> >> Warning! Here "p" is pointing to nowhere, you don't know which memory >> locations are writing to. > > Yeah, that's why I said "skeezy". But on so

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

2016-03-29 Thread Rainer Weikusat
Edward Bartolo writes: > Hi, > > Thanks for dedicating some of your time to answer me. I used: > > void change_value(void** ptr) > > Because I wanted to enable myself to allocate memory for the pointer > inside the function, therefore I needed a pointer to a pointer of type > void. This is a wron

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

2016-03-29 Thread Emiliano Marini
This is correct: int **L ===> Address1(preallocated) -> Address2(not allocated) -> > int (not allocated) > When you declare a variable, the compiler will reserve memory space to store it. No matter how may asterisks a variable has, from the compiler's view it's only a memory address. So

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

2016-03-29 Thread Edward Bartolo
Hi, As far as I know, the compiler automatically allocates memory for the address where a pointer is saved. The unallocated part is the data attached to a pointer. What happens with a pointer to a pointer like void**? Does the compiler allocate memory for two addresses with the first one in the ch

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

2016-03-29 Thread Didier Kryn
Le 29/03/2016 10:30, Edward Bartolo a écrit : Sometimes, a generic pointer is very useful. For instance, the Windows API documents functions that have untyped pointers. These allow great flexibility and behave like the variant type in other languages but with efficient memory consumption. Delphi

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

2016-03-29 Thread Edward Bartolo
Hi, Sometimes, a generic pointer is very useful. For instance, the Windows API documents functions that have untyped pointers. These allow great flexibility and behave like the variant type in other languages but with efficient memory consumption. Delphi Pascal has both the variant and untyped poi

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

2016-03-29 Thread KatolaZ
On Mon, Mar 28, 2016 at 09:55:08PM +0200, Edward Bartolo wrote: > Hi, > > Thanks for dedicating some of your time to answer me. I used: > > void change_value(void** ptr) > > Because I wanted to enable myself to allocate memory for the pointer > inside the function, therefore I needed a pointer t

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

2016-03-28 Thread Steve Litt
On Mon, 28 Mar 2016 13:57:08 -0300 Emiliano Marini wrote: > char *p; > p="01234"; /* skeezy, but makes the point */ > > Warning! Here "p" is pointing to nowhere, you don't know which memory > locations are writing to. Yeah, that's why I said "skeezy". But on some of compilers, you can actually

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

2016-03-28 Thread Emiliano Marini
Exactly, to modify a pointer you need a pointer to that pointer. Remember in C, function parameters are "read only" because they're always copies of the calling variable's values. This is wrong: function abcd(void *p) { p = malloc(sizeof(int)); // Memory leaking *p = 1; } main () { int *p

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

2016-03-28 Thread Edward Bartolo
Hi, Thanks for dedicating some of your time to answer me. I used: void change_value(void** ptr) Because I wanted to enable myself to allocate memory for the pointer inside the function, therefore I needed a pointer to a pointer of type void. Void allows such a function to handle different data t

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

2016-03-28 Thread Rainer Weikusat
Roger Leigh writes: > On 28/03/2016 15:35, Steve Litt wrote: >> On Mon, 28 Mar 2016 06:03:13 -0400 >> Boruch Baum wrote: >> >>> Why on this list, of all the possible places in Creation? It's a great >>> and important topic, but have you found no other, more appropriate >>> forum? > >> Because we

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

2016-03-28 Thread Roger Leigh
On 28/03/2016 15:35, Steve Litt wrote: On Mon, 28 Mar 2016 06:03:13 -0400 Boruch Baum wrote: Why on this list, of all the possible places in Creation? It's a great and important topic, but have you found no other, more appropriate forum? > Because we're developing software. I'd have to say

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

2016-03-28 Thread Rainer Weikusat
k...@aspodata.se writes: > Rainer Weikusat: > ... >> One thing to note here: Every C pointer is really a pointer to an array >> of values, although the size of the array may just be one. > ... > > I thought it was the other way around, a pointer is just an address to > some (a single) memory locati

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

2016-03-28 Thread Emiliano Marini
I was wrong because in this examples p was a pointer to int. Sorry, I was thinking on something like this: int *p; *p = 0; Cheers, Emiliano. On Mon, Mar 28, 2016 at 2:16 PM, Emiliano Marini wrote: > You're right. > > On Mon, Mar 28, 2016 at 2:04 PM, Rainer Weikusat < > rainerweiku...@virginmed

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

2016-03-28 Thread Emiliano Marini
You're right. On Mon, Mar 28, 2016 at 2:04 PM, Rainer Weikusat < rainerweiku...@virginmedia.com> wrote: > Emiliano Marini writes: > > char *p; > > p="01234"; /* skeezy, but makes the point */ > > > > Warning! Here "p" is pointing to nowhere, you don't know which memory > > locations are writing

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

2016-03-28 Thread Emiliano Marini
The main difference here is where you are storing the value "2000". In the first example, p is located in addresses belonging to "main" memory space (the stack presumably, beacuse "main" is the first function called upon start). You are passing the memory address of p (where p is located) to t

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

2016-03-28 Thread Rainer Weikusat
Emiliano Marini writes: > char *p; > p="01234"; /* skeezy, but makes the point */ > > Warning! Here "p" is pointing to nowhere, you don't know which memory > locations are writing to. The 'memory location' (if any) reserved for the pointer p itself by the compiler, IOW, this is totally correct.

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

2016-03-28 Thread Emiliano Marini
char *p; p="01234"; /* skeezy, but makes the point */ Warning! Here "p" is pointing to nowhere, you don't know which memory locations are writing to. char *p; *p=malloc...* p="01234"; /* skeezy, but makes the point */ On Mon, Mar 28, 2016 at 12:59 PM, Steve Litt wrote: > On Mon, 28 Mar 2016

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

2016-03-28 Thread karl
Steve Litt: ... > Years ago I gave up trying to logically explain the syntax of function > pointers, which are so essential for callbacks and pseudo-oop, and just > memorized the idiom. > > Edition 1 of K&R had an actual algorithm by which one could dissect any > lvalue (thing that can appear on t

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

2016-03-28 Thread aitor_czr
Hi Boruch, On 03/28/2016 02:00 PM, Boruch Baum wrote: Why on this list, of all the possible places in Creation? It's a great and important topic, but have you found no other, more appropriate forum? This is an appropiate list to argue about pointers. Have a look at the code of some projects

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

2016-03-28 Thread Steve Litt
On Mon, 28 Mar 2016 12:28:03 +0200 (CEST) k...@aspodata.se wrote: > To exemplify the "as they are used" statement, take a function > pointer declaration: > > void (*log_func)(int priority, const char *format); > > here you cannot conveniently move the "*" to the "void" so it will > look like a

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

2016-03-28 Thread Steve Litt
On Mon, 28 Mar 2016 14:51:19 +0200 (CEST) k...@aspodata.se wrote: > Rainer Weikusat: > ... > > One thing to note here: Every C pointer is really a pointer to an > > array of values, although the size of the array may just be one. > ... > > I thought it was the other way around, a pointer is jus

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

2016-03-28 Thread Steve Litt
Because we're developing software. On Mon, 28 Mar 2016 06:03:13 -0400 Boruch Baum wrote: > Why on this list, of all the possible places in Creation? It's a great > and important topic, but have you found no other, more appropriate > forum? > > On 03/28/2016 02:50 AM, Edward Bartolo wrote: > > H

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

2016-03-28 Thread karl
Rainer Weikusat: > k...@aspodata.se writes: ... > > With pointers, you have to handle the special case of null pointers. > > I'm assuming you are omitting it here for brevity, but generally > > change_value() should be something like: > > > > void change_value(int* ptr) { > > if (!ptr) return; >

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

2016-03-28 Thread karl
Rainer Weikusat: > k...@aspodata.se writes: ... > > To exemplify the "as they are used" statement, take a function pointer > > declaration: > > > > void (*log_func)(int priority, const char *format); > > > > here you cannot conveniently move the "*" to the "void" so it will look > > like a "poin

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

2016-03-28 Thread karl
Rainer Weikusat: ... > One thing to note here: Every C pointer is really a pointer to an array > of values, although the size of the array may just be one. ... I thought it was the other way around, a pointer is just an address to some (a single) memory location which can be part of an array, I'd

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

2016-03-28 Thread Rainer Weikusat
k...@aspodata.se writes: [...] > With pointers, you have to handle the special case of null pointers. > I'm assuming you are omitting it here for brevity, but generally > change_value() should be something like: > > void change_value(int* ptr) { > if (!ptr) return; > *ptr = 2000; > } It

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

2016-03-28 Thread karl
Edward Bartolo: ... > 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. ... Some comments on test101.c #include void change_value(void* ptr) { *((int*) ptr) = 2000; } int main() {

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

2016-03-28 Thread Rainer Weikusat
k...@aspodata.se writes: [...] > To exemplify the "as they are used" statement, take a function pointer > declaration: > > void (*log_func)(int priority, const char *format); > > here you cannot conveniently move the "*" to the "void" so it will look > like a "pointer" declaration; it declares

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

2016-03-28 Thread Rainer Weikusat
Edward Bartolo writes: > 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

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

2016-03-28 Thread karl
Edward Bartolo: ... > However, C pointer syntax is proving to be as unintuitive as it can > be. ... > I want to understand, as opposed to knowing by rote, the > mechanism why they work. ... /// I think one source of confusion re. c-pointers is that they are declared "as they are used", but you mi

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

2016-03-28 Thread Boruch Baum
Why on this list, of all the possible places in Creation? It's a great and important topic, but have you found no other, more appropriate forum? On 03/28/2016 02:50 AM, Edward Bartolo wrote: > Hi, > > As the title of the email indicates, I am doing some exercises to make > sense out of C pointer

[DNG] Making sense of C pointer syntax.

2016-03-27 Thread Edward Bartolo
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 s