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

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

dereference

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

Contents

  dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-20 18:04 -0400
    Re: dereference Keith Thompson <kst-u@mib.org> - 2012-08-20 15:30 -0700
      Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-20 18:37 -0400
        Re: dereference Keith Thompson <kst-u@mib.org> - 2012-08-20 18:43 -0700
        Re: dereference Kenneth Brody <kenbrody@spamcop.net> - 2012-08-22 14:42 -0400
          Re: dereference Keith Thompson <kst-u@mib.org> - 2012-08-22 12:10 -0700
            Re: dereference Kenneth Brody <kenbrody@spamcop.net> - 2012-08-22 17:38 -0400
      Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-20 21:09 -0400
        Re: dereference Keith Thompson <kst-u@mib.org> - 2012-08-20 18:46 -0700
          Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-21 16:15 -0400
          Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-21 16:26 -0400
        Re: dereference Kenneth Brody <kenbrody@spamcop.net> - 2012-08-22 14:49 -0400
          Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-22 18:10 -0400
            Re: dereference Barry Schwarz <schwarzb@dqel.com> - 2012-08-22 17:36 -0700
              Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-22 20:50 -0400
                Re: dereference Keith Thompson <kst-u@mib.org> - 2012-08-22 17:54 -0700
                  Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-22 21:23 -0400
                  Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-22 21:26 -0400
                    Re: dereference Kenneth Brody <kenbrody@spamcop.net> - 2012-08-23 12:55 -0400
                      Re: dereference Mark Bluemel <mark_bluemel@pobox.com> - 2012-08-24 08:05 +0100
                    Re: dereference Hans Vlems <hvlems@freenet.de> - 2012-08-24 03:00 -0700
                      Re: dereference Kenneth Brody <kenbrody@spamcop.net> - 2012-08-24 13:31 -0400
                        Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-24 17:20 -0400
                        Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-24 19:36 -0400
                          Re: dereference Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-24 20:42 -0700
                            Re: dereference Hans Vlems <hvlems@freenet.de> - 2012-08-27 00:11 -0700
                              Re: dereference Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 02:01 -0700
                                Re: dereference Keith Thompson <kst-u@mib.org> - 2012-08-27 03:24 -0700
                          Re: dereference Barry Schwarz <schwarzb@dqel.com> - 2012-08-24 21:44 -0700
                            Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-25 09:46 -0400
                              Re: dereference Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-25 16:22 +0200
                              Re: dereference Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-25 16:33 +0200
                              Re: dereference Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-25 08:07 -0700
                                Re: dereference Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-25 17:55 +0200
                                  Re: dereference Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-25 10:58 -0700
                                Re: dereference Ike Naar <ike@iceland.freeshell.org> - 2012-08-25 20:39 +0000
                                  Re: dereference Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-26 14:49 -0700
                                Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-25 18:36 -0400
                                  Re: dereference Keith Thompson <kst-u@mib.org> - 2012-08-25 16:42 -0700
                                    Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-25 20:19 -0400
                                  Re: dereference Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-26 14:40 -0700
                                    Re: dereference Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-26 14:46 -0700
                                      Re: dereference Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 02:11 -0700
                                      Re: dereference James Kuyper <jameskuyper@verizon.net> - 2012-08-27 08:36 -0400
                                        Re: dereference Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-27 10:38 -0700
                                          Re: dereference James Kuyper <jameskuyper@verizon.net> - 2012-08-27 13:55 -0400
                                            Re: dereference Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-27 12:57 -0700
                                              Re: dereference James Kuyper <jameskuyper@verizon.net> - 2012-08-27 16:25 -0400
                                                Re: dereference Kenneth Brody <kenbrody@spamcop.net> - 2012-08-29 10:41 -0400
                                  Re: dereference Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 02:09 -0700
                              Re: dereference Barry Schwarz <schwarzb@dqel.com> - 2012-08-25 12:16 -0700
                                Re: dereference Keith Thompson <kst-u@mib.org> - 2012-08-25 16:40 -0700
                                  Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-25 21:21 -0400
                                  Re: dereference Barry Schwarz <schwarzb@dqel.com> - 2012-08-25 21:48 -0700
                            Re: dereference Les Cargill <lcargill99@comcast.com> - 2012-08-25 13:08 -0500
                            Re: dereference Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 02:02 -0700
                        Re: dereference Andrew Cooper <amc96@cam.ac.uk> - 2012-08-25 02:53 +0100
                          Re: dereference Hans Vlems <hvlems@freenet.de> - 2012-08-27 00:10 -0700
                          Re: dereference Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 02:14 -0700
                            Re: dereference Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-27 10:34 -0700
                              Re: dereference Kenneth Brody <kenbrody@spamcop.net> - 2012-08-29 10:22 -0400
    Re: dereference Les Cargill <lcargill99@comcast.com> - 2012-08-20 17:38 -0500
      Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-20 18:41 -0400
    Re: dereference "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-08-20 16:43 -0700
      Re: dereference Mark Bluemel <mark_bluemel@pobox.com> - 2012-08-21 09:22 +0100
      Re: dereference "Bill Cunningham" <nospam@nspam.invalid> - 2012-08-21 16:12 -0400

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#24831

On 23 aug, 03:26, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> Keith Thompson wrote:
> > No, it isn't the same thing at all, and the difference is *exactly*
> > what we've been discussing.
>
> Ok I read Kenneth Brody's post. I guess the difference is the pointer and
> what it's pointing at.
>
> Bill

Imagine two drawers in a cabinet. The right drawer contains a one
dollar note. The left drawer contains a note that says "one dollar
note in right drawer".
The content of the left drawer points to the right drawer. Only the
right drawer holds the real thing (the money).
Hans

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

#24862

On 8/24/2012 6:00 AM, Hans Vlems wrote:
> On 23 aug, 03:26, "Bill Cunningham" <nos...@nspam.invalid> wrote:
>> Keith Thompson wrote:
>>> No, it isn't the same thing at all, and the difference is *exactly*
>>> what we've been discussing.
>>
>> Ok I read Kenneth Brody's post. I guess the difference is the pointer and
>> what it's pointing at.
>
> Imagine two drawers in a cabinet. The right drawer contains a one
> dollar note. The left drawer contains a note that says "one dollar
> note in right drawer".
> The content of the left drawer points to the right drawer. Only the
> right drawer holds the real thing (the money).

Using GC, if I remove the note from the left drawer, what happens to the 
money in the right drawer?

-- 
Kenneth Brody

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

#24874

Kenneth Brody wrote:
> Using GC, if I remove the note from the left drawer, what happens to
> the money in the right drawer?

    Nothing ?

Bill

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

#24877

Kenneth Brody wrote:
> Using GC, if I remove the note from the left drawer, what happens to
> the money in the right drawer?

That sounds like a null pointer.
char p[]="hello world\n";
p==NULL;

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

#24883

On Saturday, 25 August 2012 01:36:12 UTC+2, Bill Cunningham  wrote:
> Kenneth Brody wrote:
> 
> > Using GC, if I remove the note from the left drawer, what happens to
> 
> > the money in the right drawer?
> 
> the money in the right drawer?

I think the "Nothing" answer was better.  I think the right drawer doesn't have a note saying "one dollar in left drawer".  Rather it has a note saying "Money, left drawer", where it is previously understood that the *right* drawer contains a treasure map to finding, say, auntie Rohini's life savings.

   typedef int Dollars;
   Dollars rohinis_stash = 1;
   Dollars *treasure_map = &rohinis_stash;

   rohinis_stash = 0;
   assert(treasure_map == &rohinis_stash);  // passes
   assert(*treasure_map == 0); // passes
 
The pointer in the right draw is unchanged, and still correct, if Rohini empties out the here stash.  What was a pointer to $1 is now a pointer to $0.  A NULL pointer would be if Rohini keeps here money where it is, but replaces the pointer with a not saying "Money, up your nether hole".


   typedef int Dollars;
   Dollars rohinis_stash = 1;
   Dollars *treasure_map = &rohinis_stash;

   treasure_map = NULL;
   assert(*treasure_map == 1); hopefully segfaults

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

#25068

On 25 aug, 05:42, Adrian Ratnapala <adrian.ratnap...@gmail.com> wrote:
> On Saturday, 25 August 2012 01:36:12 UTC+2, Bill Cunningham  wrote:
> > Kenneth Brody wrote:
>
> > > Using GC, if I remove the note from the left drawer, what happens to
>
> > > the money in the right drawer?
>
> > the money in the right drawer?
>
> I think the "Nothing" answer was better.  I think the right drawer doesn't have a note saying "one dollar in left drawer".  Rather it has a note saying "Money, left drawer", where it is previously understood that the *right* drawer contains a treasure map to finding, say, auntie Rohini's life savings.
>
>    typedef int Dollars;
>    Dollars rohinis_stash = 1;
>    Dollars *treasure_map = &rohinis_stash;
>
>    rohinis_stash = 0;
>    assert(treasure_map == &rohinis_stash);  // passes
>    assert(*treasure_map == 0); // passes
>
> The pointer in the right draw is unchanged, and still correct, if Rohini empties out the here stash.  What was a pointer to $1 is now a pointer to $0.  A NULL pointer would be if Rohini keeps here money where it is, but replaces the pointer with a not saying "Money, up your nether hole".
>
>    typedef int Dollars;
>    Dollars rohinis_stash = 1;
>    Dollars *treasure_map = &rohinis_stash;
>
>    treasure_map = NULL;
>    assert(*treasure_map == 1); hopefully segfaults

The right hand drawer is not a pointer. It is simply a location
holding a value.

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

#25087

On Aug 27, 8:11 am, Hans Vlems <hvl...@freenet.de> wrote:
> On 25 aug, 05:42, Adrian Ratnapala <adrian.ratnap...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Saturday, 25 August 2012 01:36:12 UTC+2, Bill Cunningham  wrote:
> > > Kenneth Brody wrote:
>
> > > > Using GC, if I remove the note from the left drawer, what happens to
>
> > > > the money in the right drawer?
>
> > > the money in the right drawer?
>
> > I think the "Nothing" answer was better.  I think the right drawer doesn't have a note saying "one dollar in left drawer".  Rather it has a note saying "Money, left drawer", where it is previously understood that the *right* drawer contains a treasure map to finding, say, auntie Rohini's life savings.

<snip>

> The right hand drawer is not a pointer. It is simply a location
> holding a value.

sounds like a distinction without a difference

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

#25091

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On Aug 27, 8:11 am, Hans Vlems <hvl...@freenet.de> wrote:
>> On 25 aug, 05:42, Adrian Ratnapala <adrian.ratnap...@gmail.com> wrote:
>> > On Saturday, 25 August 2012 01:36:12 UTC+2, Bill Cunningham  wrote:
>> > > Kenneth Brody wrote:
>>
>> > > > Using GC, if I remove the note from the left drawer, what
>> > > > happens to the money in the right drawer?
>>
>> > > the money in the right drawer?
>>
>> > I think the "Nothing" answer was better.  I think the right drawer
>> > doesn't have a note saying "one dollar in left drawer".  Rather it
>> > has a note saying "Money, left drawer", where it is previously
>> > understood that the *right* drawer contains a treasure map to
>> > finding, say, auntie Rohini's life savings.
>
> <snip>
>
>> The right hand drawer is not a pointer. It is simply a location
>> holding a value.
>
> sounds like a distinction without a difference

In the analogy, the drawers are objects, and the note in the left
drawer is a pointer value.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#24885

On Fri, 24 Aug 2012 19:36:12 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>Kenneth Brody wrote:
>> Using GC, if I remove the note from the left drawer, what happens to
>> the money in the right drawer?
>
>That sounds like a null pointer.
>char p[]="hello world\n";
>p==NULL;
>

There are no pointer variables in your code.  Go back and start again
from scratch while writing "Arrays and pointers are different objects"
1000 times.

-- 
Remove del for email

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

#24910

Barry Schwarz wrote:

> There are no pointer variables in your code.  Go back and start again
> from scratch while writing "Arrays and pointers are different objects"
> 1000 times.

    This is something I know because its been drilled into me. But the thing 
is I haven't yet caught onto the real meaning yet. For example I know of a 
funtion whose prototype is char * but if you put a string into it the 
function doesn't work correctly it's called cbc_crypt(). You have to pass 
char key[]="string"; to char *key, the first parameter. Not quite sure why 
yet but that's the way it works.

Bill

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

#24912

On 25/08/2012 15:46, Bill Cunningham wrote:
> Barry Schwarz wrote:
>
>> There are no pointer variables in your code.  Go back and start again
>> from scratch while writing "Arrays and pointers are different objects"
>> 1000 times.
>
>      This is something I know because its been drilled into me. But the thing
> is I haven't yet caught onto the real meaning yet. For example I know of a
> funtion whose prototype is char * but if you put a string into it the
> function doesn't work correctly it's called cbc_crypt(). You have to pass
> char key[]="string"; to char *key, the first parameter. Not quite sure why
> yet but that's the way it works.
>

All you need to know is explained here:
http://c-faq.com/aryptr/index.html

-- 
Vincenzo Mercuri

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

#24913

On 25/08/2012 15:46, Bill Cunningham wrote:
> Barry Schwarz wrote:
>
>> There are no pointer variables in your code.  Go back and start again
>> from scratch while writing "Arrays and pointers are different objects"
>> 1000 times.
>
>      This is something I know because its been drilled into me. But the thing
> is I haven't yet caught onto the real meaning yet. For example I know of a
> funtion whose prototype is char * but if you put a string into it the
> function doesn't work correctly it's called cbc_crypt(). You have to pass
> char key[]="string"; to char *key, the first parameter. Not quite sure why
> yet but that's the way it works.
>

I read your post in comp.unix.programmer, you also
need to read this: http://c-faq.com/decl/strlitinit.html

I'd suggest to read all the FAQ, of course :)

-- 
Vincenzo Mercuri

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

#24916

On Saturday, 25 August 2012 15:46:50 UTC+2, Bill Cunningham  wrote:
[regarding "array" is not a pointer"]
>     This is something I know because its been drilled into me. But the thing 
> is I haven't yet caught onto the real meaning yet. For example I know of a 
> funtion whose prototype is char * but if you put a string into it the 
> function doesn't work correctly it's called cbc_crypt(). You have to pass 
> char key[]="string"; to char *key, the first parameter. Not quite sure why 
> yet but that's the way it works.

That's a really nice example; (warning) I didn't know about cbc_crypt() 
until just now, but I will try to explain it anyway.  My man page says:

    int cbc_crypt(char *key, char *data, unsigned datalen, 
                  unsigned mode, char *ivec);

Notice it is `char *`, not `const char *`.  This is a hint that the function will be read, and *write* into the buffer.  So one way or another, `key` must point to writeable memory.

If we try:

int main(void) 
{
    char *key = "some stuff";
    .
    .
    cbc_crypt(key, ...
    .
    .

In this case GCC (on some OSen) creates a string "some stuff\0" in some read-only segment of your executable, and initialises `key` with a pointer to that string.  If and when `cbc_crypt` tries to write to `key` there will be a segfault, because it points to read-only memory, even though it is a `char *`.


If we try:

int main(void) 
{
    char key[] = "some stuff";
    .
    .
    cbc_crypt(key, ...
    .
    .

In this case the compiler allocates ten bytes on the stack, and initialises them with "some stuff\0".  These bytes are an array of type `char[10]`.  When you call `cbc_crypt`, the array `key`  degenerates into a `char *`; but now that is a pointer to the stack, which is writeable, so you are OK.

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

#24921

On 25/08/2012 17:07, Adrian Ratnapala wrote:
> On Saturday, 25 August 2012 15:46:50 UTC+2, Bill Cunningham  wrote:
> [regarding "array" is not a pointer"]
>>      This is something I know because its been drilled into me. But the thing
>> is I haven't yet caught onto the real meaning yet. For example I know of a
>> funtion whose prototype is char * but if you put a string into it the
>> function doesn't work correctly it's called cbc_crypt(). You have to pass
>> char key[]="string"; to char *key, the first parameter. Not quite sure why
>> yet but that's the way it works.
>
> That's a really nice example; (warning) I didn't know about cbc_crypt()
> until just now, but I will try to explain it anyway.  My man page says:
>
>      int cbc_crypt(char *key, char *data, unsigned datalen,
>                    unsigned mode, char *ivec);
>
> Notice it is `char *`, not `const char *`.  This is a hint that the function will be read, and *write* into the buffer.  So one way or another, `key` must point to writeable memory.
>
[..]

You probably meant that the *key* will be read and written into a buffer.
So, from this point of view, it's the buffer that needs to be writable,
not the `key'. However, in this case in particular, the only reason why
he also needs the key to be writable is because the *crypt() functions
are usually preceded by a call to `des_setparity()' which sets the key's
parity. But `cbc_crypt()' itself would work just fine even if `key' was
not modifiable. But this is not topical here :)

-- 
Vincenzo Mercuri

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

#24927

> 
> > Notice it is `char *`, not `const char *`.  This is a hint that the function will be read, and *write* into the buffer.  So one way or another, `key` must point to writeable memory.
> 
> >
> 
> [..]
> 
> 
> 
> You probably meant that the *key* will be read and written into a buffer.

`key` points to the buffer.  The buffer must be writeable, therefore `key` must point to writeable memory.  But you are quite right; what I wrote could be misunderstood to mean that the pointer itself had to be writeable.  Thanks for the clarification.

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

#24953

On 2012-08-25, Adrian Ratnapala <adrian.ratnapala@gmail.com> wrote:
>     char key[] = "some stuff";
>
> In this case the compiler allocates ten bytes on the stack,

Eleven bytes, and not necessarily on the stack.

> and initialises them with "some stuff\0".

No, it initializes them with "some stuff", the string constant already
includes the terminating null char. "some stuff\0" would be 12 bytes
long and have two null chars at the end.

> These bytes are an array of type `char[10]`.

No, char[11],
[0] 's'
[1] 'o'
[2] 'm'
[3] 'e'
[4] ' '
[5] 's'
[6] 't'
[7] 'u'
[8] 'f'
[9] 'f'
[10] '\0'

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

#25043

On Saturday, 25 August 2012 22:39:22 UTC+2, Ike Naar  wrote:

> 
> >     char key[] = "some stuff";
> > In this case the compiler allocates ten bytes on the stack,
> 
> Eleven bytes, and not necessarily on the stack.

Correct, if you will beleive it, I remembered the '\0' but forgot the space. 

Damn!

Also you are right, it is not necessarily on the stack, it's just somewhere that is safe against multithreading and re-entrant calls.  Like all the other local fucking variables.

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

#24959

Adrian Ratnapala wrote:
> On Saturday, 25 August 2012 15:46:50 UTC+2, Bill Cunningham  wrote:
> [regarding "array" is not a pointer"]
>>     This is something I know because its been drilled into me. But
>> the thing is I haven't yet caught onto the real meaning yet. For
>> example I know of a funtion whose prototype is char * but if you put
>> a string into it the function doesn't work correctly it's called
>> cbc_crypt(). You have to pass char key[]="string"; to char *key, the
>> first parameter. Not quite sure why yet but that's the way it works.
>
> That's a really nice example; (warning) I didn't know about
> cbc_crypt()
> until just now, but I will try to explain it anyway.  My man page
> says:
>
>     int cbc_crypt(char *key, char *data, unsigned datalen,
>                   unsigned mode, char *ivec);
>
> Notice it is `char *`, not `const char *`.  This is a hint that the
> function will be read, and *write* into the buffer.  So one way or
> another, `key` must point to writeable memory.
[snip]

    Would the man page author have done us all a big favor and instead of 
calling all the char *'s in this example char key[] for example? Or is this 
just me and something I didn't get at first.

Bill

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

#24963

"Bill Cunningham" <nospam@nspam.invalid> writes:
> Adrian Ratnapala wrote:
[...]
>>     int cbc_crypt(char *key, char *data, unsigned datalen,
>>                   unsigned mode, char *ivec);
>>
>> Notice it is `char *`, not `const char *`.  This is a hint that the
>> function will be read, and *write* into the buffer.  So one way or
>> another, `key` must point to writeable memory.
> [snip]
>
>     Would the man page author have done us all a big favor and instead of 
> calling all the char *'s in this example char key[] for example? Or is this 
> just me and something I didn't get at first.

"char key[]", as a parameter declaration, means exactly the same thing
as "char *key".  C doesn't even have parameters of array type.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#24967

Keith Thompson wrote:

> "char key[]", as a parameter declaration, means exactly the same thing
> as "char *key".  C doesn't even have parameters of array type.

Oh. OK. My bad.

Bill

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web