Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #43110 > unrolled thread

coding dynamic allocation question

Back to article view | Back to comp.lang.c

Contents

  coding dynamic allocation question "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-18 22:25 -0400
    Re: coding dynamic allocation question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-19 04:06 -0700
      Re: coding dynamic allocation question "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-19 19:04 -0400
        Re: coding dynamic allocation question Barry Schwarz <schwarzb@dqel.com> - 2014-04-19 16:52 -0700
        Re: coding dynamic allocation question Keith Thompson <kst-u@mib.org> - 2014-04-19 17:36 -0700
          Re: coding dynamic allocation question "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-19 20:47 -0400
            Re: coding dynamic allocation question Keith Thompson <kst-u@mib.org> - 2014-04-19 18:55 -0700
              Re: coding dynamic allocation question "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-19 21:59 -0400
                Re: coding dynamic allocation question Keith Thompson <kst-u@mib.org> - 2014-04-19 19:19 -0700
                  Re: coding dynamic allocation question "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-19 22:47 -0400
                    Re: coding dynamic allocation question Keith Thompson <kst-u@mib.org> - 2014-04-19 20:18 -0700
                Re: coding dynamic allocation question Richard <rgrdev_@gmail.com> - 2014-04-20 11:00 +0100
        Re: coding dynamic allocation question rescattered@gmail.com - 2014-04-20 05:25 -0700
          Re: coding dynamic allocation question rescattered@gmail.com - 2014-04-20 05:42 -0700
    Re: coding dynamic allocation question Richard <rgrdev_@gmail.com> - 2014-04-19 14:57 +0100
      Re: coding dynamic allocation question Ian Collins <ian-news@hotmail.com> - 2014-04-20 23:24 +1200
    Re: coding dynamic allocation question Michael Angelo Ravera <maravera@prodigy.net> - 2014-04-19 16:19 -0700

#43110 — coding dynamic allocation question

    I guess these two statements are not the same. Why not? I guess I 
haven't learned this I haven't used it much.

int *p;
p=malloc(sizeof (int)); //seems to be in error
p=malloc(sizeof (int *)); //is the correct coding

    What exactly is the difference?

Bill

[toc] | [next] | [standalone]

#43118

On Saturday, April 19, 2014 3:25:31 AM UTC+1, Bill Cunningham wrote:
> I guess these two statements are not the same. Why not? I guess I 
> haven't learned this I haven't used it much.
> 
> int *p;
> 
> p=malloc(sizeof (int)); //seems to be in error
> p=malloc(sizeof (int *)); //is the correct coding
>  
>     What exactly is the difference?
>
The last one is almost certainly wrong.

malloc() creates a buffer, a region of memory where you can put things. So
if you want ten ints, p=malloc(10*sizeof(int)); If you want ten pointers to
ints, p=malloc(10*sizeof(int*));
But since p is an int *, it points to a buffer of ints, so presumably we
want ints in our buffer. 

Usually you call malloc when the size of the buffer you need isn't known
at compile time. So if N is a variable holding the number of ints we need,
it's p = malloc(N * sizeof(int)); That's the power of it. It gives us the
memory we need to scale up to any size N, until we run out of memory and
malloc() returns NULL.
 

[toc] | [prev] | [next] | [standalone]

#43144

Malcolm McLean wrote:
> On Saturday, April 19, 2014 3:25:31 AM UTC+1, Bill Cunningham wrote:

[snip]

Thanks for your help. I work as best I can with the *nix API in kandr2 and I 
am interested in sockets. The most confusing thing seems to be pointers but 
that's typical. I know if you wanted a static buffer you can simply use an 
array. I'm not quite sure how to use malloc as a dynamic buffer but I will 
try and find out. The thing with C is I know the basics but not the 
/caveats/ of how to use the language. Such as malloc is intended for buffers 
that you are not sure of what the size is going to be. All I know to do is 
just jump in and do your best and if you hit a brick wall; ask for help. I 
am beginning to undestand what "pass by value" actually means and it 
involves pointer manipulation. But as is said "C wears well as one's 
experience with it.." and so on.

Bill

[toc] | [prev] | [next] | [standalone]

#43148

On Sat, 19 Apr 2014 19:04:05 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>Malcolm McLean wrote:
>> On Saturday, April 19, 2014 3:25:31 AM UTC+1, Bill Cunningham wrote:
>
>[snip]
>
>Thanks for your help. I work as best I can with the *nix API in kandr2 and I 
>am interested in sockets. The most confusing thing seems to be pointers but 
>that's typical. I know if you wanted a static buffer you can simply use an 
>array. I'm not quite sure how to use malloc as a dynamic buffer but I will 

Why do you think you need a dynamic buffer?  

>try and find out. The thing with C is I know the basics but not the 

Obviously not or you would never ask what the difference is between an
int and a pointer to int as you did in the origin of this discussion.

>/caveats/ of how to use the language. Such as malloc is intended for buffers 
>that you are not sure of what the size is going to be. All I know to do is 
>just jump in and do your best and if you hit a brick wall; ask for help. I 

Jumping in is almost always the wrong approach.  Programs should be
designed after careful analysis.  Actual coding is one of the very
last steps.

>am beginning to undestand what "pass by value" actually means and it 
>involves pointer manipulation. But as is said "C wears well as one's 

Pass by value has no more to do with pointer manipulation than
addition of two variables does.

>experience with it.." and so on.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#43154

"Bill Cunningham" <nospam@nspam.invalid> writes:
> I am beginning to undestand what "pass by value" actually means and it
> involves pointer manipulation.

No, "pass by value" specifically *doesn't* involve pointer manipulation.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43156

Keith Thompson wrote:

> No, "pass by value" specifically *doesn't* involve pointer
> manipulation.

I wonder what I'm meaning then. I will demonstrate by code.

int *pi;
int a;
a=20;
pi=&a;
*pi=10;
printf("%d\n",*pi);

Now you mean I am not changing the value of the int from 20 to 10 using a 
pointer? Is that not pointer manipulation?

Bill

[toc] | [prev] | [next] | [standalone]

#43159

"Bill Cunningham" <nospam@nspam.invalid> writes:
> Keith Thompson wrote:
>
>> No, "pass by value" specifically *doesn't* involve pointer
>> manipulation.
>
> I wonder what I'm meaning then. I will demonstrate by code.
>
> int *pi;
> int a;
> a=20;
> pi=&a;
> *pi=10;
> printf("%d\n",*pi);
>
> Now you mean I am not changing the value of the int from 20 to 10 using a 
> pointer? Is that not pointer manipulation?

Yes, you're changing the value of the int from 20 to 10 using a pointer.
Yes, that's pointer manipulation.  But it's not "pass by value".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43160

Keith Thompson wrote:

> Yes, you're changing the value of the int from 20 to 10 using a
> pointer. Yes, that's pointer manipulation.  But it's not "pass by
> value".

    Ok so I'm not passing by value then. Then what exactly is passing by 
value? Does it include pointer manipulation?

Bill

[toc] | [prev] | [next] | [standalone]

#43161

"Bill Cunningham" <nospam@nspam.invalid> writes:
> Keith Thompson wrote:
>> Yes, you're changing the value of the int from 20 to 10 using a
>> pointer. Yes, that's pointer manipulation.  But it's not "pass by
>> value".
>
>     Ok so I'm not passing by value then. Then what exactly is passing by 
> value? Does it include pointer manipulation?

Passing by value is how C passes parameters to functions.  The value of
the argument expression is passed to the function.  If the argument is a
variable name, the function doesn't have access to the variable, just to
the value it had when the call was executed.  And again, no, it doesn't
involve pointer manipulation, just copying a value.

The term applies only to function calls.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43162

"Keith Thompson" <kst-u@mib.org> wrote in message

> Passing by value is how C passes parameters to functions.  The value of
> the argument expression is passed to the function.  If the argument is a
> variable name, the function doesn't have access to the variable, just to
> the value it had when the call was executed.  And again, no, it doesn't
> involve pointer manipulation, just copying a value.
>
> The term applies only to function calls.

    Ok. That makes sense except for this one thing. Strings. How are they 
pass by value? When I think of "value" I am thinking about numerical values. 
For example...

char *val;
val="I am a string.";

Pass that val to a function with a paramter of say

void func(char *value);

How is that still pass by value? It's a string. Just a little confused by 
that. The ints, doubles, float and such makes sense.

Bill

[toc] | [prev] | [next] | [standalone]

#43163

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
>> Passing by value is how C passes parameters to functions.  The value of
>> the argument expression is passed to the function.  If the argument is a
>> variable name, the function doesn't have access to the variable, just to
>> the value it had when the call was executed.  And again, no, it doesn't
>> involve pointer manipulation, just copying a value.
>>
>> The term applies only to function calls.
>
>     Ok. That makes sense except for this one thing. Strings. How are they 
> pass by value? When I think of "value" I am thinking about numerical values. 
> For example...
>
> char *val;
> val="I am a string.";
>
> Pass that val to a function with a paramter of say
>
> void func(char *value);
>
> How is that still pass by value? It's a string. Just a little confused by 
> that. The ints, doubles, float and such makes sense.

val is an object of type char*.  The value of that object (which happens
to be a pointer) is passed to func.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#43168

"Bill Cunningham" <nospam@nspam.invalid> writes:

> Keith Thompson wrote:
>
>> Yes, you're changing the value of the int from 20 to 10 using a
>> pointer. Yes, that's pointer manipulation.  But it's not "pass by
>> value".
>
>     Ok so I'm not passing by value then. Then what exactly is passing by 
> value? Does it include pointer manipulation?
>
> Bill
>

Amazing.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#43172

On Saturday, April 19, 2014 7:04:05 PM UTC-4, Bill Cunningham wrote:
> Malcolm McLean wrote:
> 
> > On Saturday, April 19, 2014 3:25:31 AM UTC+1, Bill Cunningham wrote:
> 
> 
> 
> [snip]
> 
> 
> 
> Thanks for your help. I work as best I can with the *nix API in kandr2 and I 
> 
> am interested in sockets. The most confusing thing seems to be pointers but 
> 
> that's typical. I know if you wanted a static buffer you can simply use an 
> 
> array. I'm not quite sure how to use malloc as a dynamic buffer but I will 
> 
> try and find out. The thing with C is I know the basics but not the 
> 
> /caveats/ of how to use the language. Such as malloc is intended for buffers 
> 
> that you are not sure of what the size is going to be. All I know to do is 
> 
> just jump in and do your best and if you hit a brick wall; ask for help. I 
> 
> am beginning to undestand what "pass by value" actually means and it 
> 
> involves pointer manipulation. But as is said "C wears well as one's 
> 
> experience with it.." and so on.
> 
> 
> 
> Bill

C is possibly the worst language for "just jumping in". A language like Python
is designed to be fairly intuitive and has a gentle learning curve. You can
pick up the basics on Friday and write a working program on Saturday (unlikely 
to be a *good* Python program but if it is short enough it will likely do what
you intend it to do). With C, there are a host of problems which are likely to 
trip up beginners (out-of-bounds errors, buffer overflows, stray pointers, 
memory leaks) which can't arise in a language like Python. Furthermore -- these 
are not always problems that you encounter "like a brick wall". Sometimes they 
are more like hidden booby traps which don't explode until after your program
is up and seemingly running. If you learn about pitfalls only as you become 
aware of them then it is almost certain that your code is going to contain 
bugs silently lurking in the background. 

Having said all this -- if you are a hobbyist programmer and you are just 
playing around then none of this really matters, and actually coding *is* a 
good way to learn. So by all means - jump in. But, don't *just* jump in. I 
would recommend dividing your time between coding and reading a good book. I 
highly recommend King's book "Modern C Programming".

[toc] | [prev] | [next] | [standalone]

#43173

On Sunday, April 20, 2014 8:25:08 AM UTC-4, resca...@gmail.com wrote:
> On Saturday, April 19, 2014 7:04:05 PM UTC-4, Bill Cunningham wrote:
> 
> > Malcolm McLean wrote:
> 
> > 
> 
> > > On Saturday, April 19, 2014 3:25:31 AM UTC+1, Bill Cunningham wrote:
> 
> > 
> 
> > 
> 
> > 
> 
> > [snip]
> 
> > 
> 
> > 
> 
> > 
> 
> > Thanks for your help. I work as best I can with the *nix API in kandr2 and I 
> 
> > 
> 
> > am interested in sockets. The most confusing thing seems to be pointers but 
> 
> > 
> 
> > that's typical. I know if you wanted a static buffer you can simply use an 
> 
> > 
> 
> > array. I'm not quite sure how to use malloc as a dynamic buffer but I will 
> 
> > 
> 
> > try and find out. The thing with C is I know the basics but not the 
> 
> > 
> 
> > /caveats/ of how to use the language. Such as malloc is intended for buffers 
> 
> > 
> 
> > that you are not sure of what the size is going to be. All I know to do is 
> 
> > 
> 
> > just jump in and do your best and if you hit a brick wall; ask for help. I 
> 
> > 
> 
> > am beginning to undestand what "pass by value" actually means and it 
> 
> > 
> 
> > involves pointer manipulation. But as is said "C wears well as one's 
> 
> > 
> 
> > experience with it.." and so on.
> 
> > 
> 
> > 
> 
> > 
> 
> > Bill
> 
> 
> 
> C is possibly the worst language for "just jumping in". A language like Python
> 
> is designed to be fairly intuitive and has a gentle learning curve. You can
> 
> pick up the basics on Friday and write a working program on Saturday (unlikely 
> 
> to be a *good* Python program but if it is short enough it will likely do what
> 
> you intend it to do). With C, there are a host of problems which are likely to 
> 
> trip up beginners (out-of-bounds errors, buffer overflows, stray pointers, 
> 
> memory leaks) which can't arise in a language like Python. Furthermore -- these 
> 
> are not always problems that you encounter "like a brick wall". Sometimes they 
> 
> are more like hidden booby traps which don't explode until after your program
> 
> is up and seemingly running. If you learn about pitfalls only as you become 
> 
> aware of them then it is almost certain that your code is going to contain 
> 
> bugs silently lurking in the background. 
> 
> 
> 
> Having said all this -- if you are a hobbyist programmer and you are just 
> 
> playing around then none of this really matters, and actually coding *is* a 
> 
> good way to learn. So by all means - jump in. But, don't *just* jump in. I 
> 
> would recommend dividing your time between coding and reading a good book. I 
> 
> highly recommend King's book "Modern C Programming".

Correct title: "C Programming: A Modern Approach"

[toc] | [prev] | [next] | [standalone]

#43123

"Bill Cunningham" <nospam@nspam.invalid> writes:

>     I guess these two statements are not the same. Why not? I guess I 
> haven't learned this I haven't used it much.
>
> int *p;
> p=malloc(sizeof (int)); //seems to be in error
> p=malloc(sizeof (int *)); //is the correct coding
>
>     What exactly is the difference?
>
> Bill
>

8/10

Someone will think you're serious and provide a horrifically long
laboured reply though no doubt.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#43171

Richard wrote:
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>
>>      I guess these two statements are not the same. Why not? I guess I
>> haven't learned this I haven't used it much.
>>
>> int *p;
>> p=malloc(sizeof (int)); //seems to be in error
>> p=malloc(sizeof (int *)); //is the correct coding
>>
>>      What exactly is the difference?
>>
>> Bill
>>
>
> 8/10

That's over generous, I'd only go to a 7.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#43146

On Friday, April 18, 2014 7:25:31 PM UTC-7, Bill Cunningham wrote:
> I guess these two statements are not the same. Why not? I guess I 
> 
> haven't learned this I haven't used it much.
> 
> 
> 
> int *p;
> p=malloc(sizeof (int)); //seems to be in error
> p=malloc(sizeof (int *)); //is the correct coding
> 
>     What exactly is the difference?

Please do us all a favor and study a little bit about data representation. Both of these are statements that would never (except maybe as a test of something) appear in a sane program.

Apart from an occasional effort to skirt implementation-specific limitations (like stack size, which you don't understand because you don't understand data representation) most programmers do not use malloc when the size or multiplicity of something is known, or assumed to be known or limited, in advance and, even then, certainly, never to allocate a single scalar value.

So, go learn something about data representation and get back to us.

Of course, if you are a C programming instructor posting to see, if you can get one of your students to respond, I apologize. But, history shows that's not the case.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web