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:
>
>
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
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
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
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
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
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:
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
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
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
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
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
> >
>
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
> >
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
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
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
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];
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
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
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
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
+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
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
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
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
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
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
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
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
+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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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;
>
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
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
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
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() {
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
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
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
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
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
70 matches
Mail list logo
