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

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

pass by address

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

Contents

  pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-02 16:53 -0400
    Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-02 17:03 -0400
      Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-02 17:20 -0400
    Re: pass by address Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-05-02 17:58 -0400
      Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-02 18:09 -0400
        Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-02 16:37 -0700
          Re: pass by address gazelle@shell.xmission.com (Kenny McCormack) - 2014-05-02 23:43 +0000
            Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-03 15:58 +0200
              Re: pass by address gazelle@shell.xmission.com (Kenny McCormack) - 2014-05-03 14:08 +0000
                Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-03 10:38 -0700
                  Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-03 21:13 +0200
          Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-03 01:46 -0400
          Re: pass by address "Bill Cunningaham" <nospam@nspam.invalid> - 2014-05-03 11:22 -0400
            Re: pass by address James Kuyper <jameskuyper@verizon.net> - 2014-05-03 12:13 -0400
            Re: pass by address Keith Thompson <kst-u@mib.org> - 2014-05-03 12:34 -0700
              Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-03 22:33 +0200
              Re: pass by address glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-05-03 21:21 +0000
                Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-04 00:08 -0400
                  Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-03 21:52 -0700
                    Re: pass by address Tonton Th <tth@nowhere.invalid> - 2014-05-04 08:44 +0000
                      Re: pass by address Keith Thompson <kst-u@mib.org> - 2014-05-04 01:51 -0700
                        Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-04 15:06 -0400
                          Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-04 15:35 -0700
                            Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-05 12:01 +0200
                              Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-05 11:46 -0700
                            Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 14:18 -0400
                              Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-05 11:55 -0700
                                Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 15:20 -0400
                                  Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 15:23 -0400
                                    Re: pass by address Ken Brody <kenbrody@spamcop.net> - 2014-05-06 11:02 -0400
                                      Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-06 14:46 -0400
                          Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-05 12:00 +0200
                          Re: pass by address Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-05-05 14:50 -0700
                            Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 23:13 -0400
                              Re: pass by address "Osmium" <r124c4u102@comcast.net> - 2014-05-05 23:09 -0500
                                Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-06 08:55 -0400
                              Re: pass by address Ken Brody <kenbrody@spamcop.net> - 2014-05-06 11:16 -0400
                                Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-06 18:13 +0200
                        Re: pass by address Kaz Kylheku <kaz@kylheku.com> - 2014-05-04 21:06 +0000
                          Re: pass by address Kaz Kylheku <kaz@kylheku.com> - 2014-05-04 23:50 +0000
                    Re: pass by address Keith Thompson <kst-u@mib.org> - 2014-05-04 12:36 -0700
                    Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-05 14:21 -0400
                  Re: pass by address Keith Thompson <kst-u@mib.org> - 2014-05-04 01:29 -0700
                    Re: pass by address "Bill Cunningham" <nospam@nspam.invalid> - 2014-05-04 15:09 -0400
          Re: pass by address "Bill Cunningaham" <nospam@nspam.invalid> - 2014-05-03 11:32 -0400
    Re: pass by address Barry Schwarz <schwarzb@dqel.com> - 2014-05-02 16:43 -0700
      Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-03 01:54 -0400
        Re: pass by address Richard <rgrdev_@gmail.com> - 2014-05-03 15:59 +0200
      Re: pass by address "Bill Cunningham" <nosapm@nspam.invalid> - 2014-05-03 02:08 -0400
        Re: pass by address "Bill Cunningaham" <nospam@nspam.invalid> - 2014-05-03 11:46 -0400
      Re: pass by address Kaz Kylheku <kaz@kylheku.com> - 2014-05-03 21:43 +0000

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

#43998

Tonton Th <tth@nowhere.invalid> writes:
> On 2014-05-04, Barry Schwarz <schwarzb@dqel.com> wrote:
>>>#include <stdio.h>
>>>
>>>int main()
>>>{
>>>    int a = 15;
>>>    int *p;
>>>    p = &a;
>>>    printf("%p\n", &p);
>>
>> Undefined behavior #1.
>>
>>>    printf("%p\n", p);
>>
>> Undefined behavior #2.
>>
>>>    printf("%d\n", *p);
>>>}
>
>    I don't understand where in the undefined behaviour. Not so usable
>    values printed, yes, but &p and p are pointers, so %p can print their
>    values, no ?
>
>    Maybe because p and &p are not 'void *' pointers...

That's exactly it.  "%p" requires an argument of type void*, not of any
arbitrary pointer type.  In practice, most implementations use the same
representation and argument passing convention for all pointer types, so
it's likely to work, but for well-defined behavior you need to cast the
arguments to void*.

-- 
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]

#44004

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnr44aj596.fsf@nuthaus.mib.org...
> Tonton Th <tth@nowhere.invalid> writes:
>> On 2014-05-04, Barry Schwarz <schwarzb@dqel.com> wrote:
>>>>#include <stdio.h>
>>>>
>>>>int main()
>>>>{
>>>>    int a = 15;
>>>>    int *p;
>>>>    p = &a;
>>>>    printf("%p\n", &p);
>>>
>>> Undefined behavior #1.
>>>
>>>>    printf("%p\n", p);
>>>
>>> Undefined behavior #2.
>>>
>>>>    printf("%d\n", *p);
>>>>}
>>
>>    I don't understand where in the undefined behaviour. Not so usable
>>    values printed, yes, but &p and p are pointers, so %p can print their
>>    values, no ?
>>
>>    Maybe because p and &p are not 'void *' pointers...
>
> That's exactly it.  "%p" requires an argument of type void*, not of any
> arbitrary pointer type.  In practice, most implementations use the same
> representation and argument passing convention for all pointer types, so
> it's likely to work, but for well-defined behavior you need to cast the
> arguments to void*.

    Well I learned something today new. I'll keep that in mind. What would 
be the best way to take careof that in your opinion? Cast a (void *). These 
are the little things that you need to know so when you get into big 
programs could cause real problems.

Bill

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

#44020

On Sun, 4 May 2014 15:06:07 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>
>"Keith Thompson" <kst-u@mib.org> wrote in message 
>news:lnr44aj596.fsf@nuthaus.mib.org...
>> Tonton Th <tth@nowhere.invalid> writes:
>>> On 2014-05-04, Barry Schwarz <schwarzb@dqel.com> wrote:
>>>>>#include <stdio.h>
>>>>>
>>>>>int main()
>>>>>{
>>>>>    int a = 15;
>>>>>    int *p;
>>>>>    p = &a;
>>>>>    printf("%p\n", &p);
>>>>
>>>> Undefined behavior #1.
>>>>
>>>>>    printf("%p\n", p);
>>>>
>>>> Undefined behavior #2.
>>>>
>>>>>    printf("%d\n", *p);
>>>>>}
>>>
>>>    I don't understand where in the undefined behaviour. Not so usable
>>>    values printed, yes, but &p and p are pointers, so %p can print their
>>>    values, no ?
>>>
>>>    Maybe because p and &p are not 'void *' pointers...
>>
>> That's exactly it.  "%p" requires an argument of type void*, not of any
>> arbitrary pointer type.  In practice, most implementations use the same
>> representation and argument passing convention for all pointer types, so
>> it's likely to work, but for well-defined behavior you need to cast the
>> arguments to void*.
>
>    Well I learned something today new. I'll keep that in mind. What would 

No you didn't.  And you probably won't.  This is the same advice you
were given as recently as August 20, 2012.  Maybe you should consider
saving some of the responses to your messages and rereading them to
reinforce the lessons  they provide.

>be the best way to take careof that in your opinion? Cast a (void *). These 
>are the little things that you need to know so when you get into big 
>programs could cause real problems.

-- 
Remove del for email

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

#44035

Barry Schwarz <schwarzb@dqel.com> writes:

> On Sun, 4 May 2014 15:06:07 -0400, "Bill Cunningham"
> <nospam@nspam.invalid> wrote:
>
>>
>>"Keith Thompson" <kst-u@mib.org> wrote in message 
>>news:lnr44aj596.fsf@nuthaus.mib.org...
>>> Tonton Th <tth@nowhere.invalid> writes:
>>>> On 2014-05-04, Barry Schwarz <schwarzb@dqel.com> wrote:
>>>>>>#include <stdio.h>
>>>>>>
>>>>>>int main()
>>>>>>{
>>>>>>    int a = 15;
>>>>>>    int *p;
>>>>>>    p = &a;
>>>>>>    printf("%p\n", &p);
>>>>>
>>>>> Undefined behavior #1.
>>>>>
>>>>>>    printf("%p\n", p);
>>>>>
>>>>> Undefined behavior #2.
>>>>>
>>>>>>    printf("%d\n", *p);
>>>>>>}
>>>>
>>>>    I don't understand where in the undefined behaviour. Not so usable
>>>>    values printed, yes, but &p and p are pointers, so %p can print their
>>>>    values, no ?
>>>>
>>>>    Maybe because p and &p are not 'void *' pointers...
>>>
>>> That's exactly it.  "%p" requires an argument of type void*, not of any
>>> arbitrary pointer type.  In practice, most implementations use the same
>>> representation and argument passing convention for all pointer types, so
>>> it's likely to work, but for well-defined behavior you need to cast the
>>> arguments to void*.
>>
>>    Well I learned something today new. I'll keep that in mind. What would 
>
> No you didn't.  And you probably won't.  This is the same advice you
> were given as recently as August 20, 2012.  Maybe you should consider

So you remember everything you were told two years ago? Amazing!

> saving some of the responses to your messages and rereading them to
> reinforce the lessons  they provide.

Are you for real? You ALSO don't realise you're being trolled?!?!?!
Life can't be fun when so easily made to jump for every treat.

>
>>be the best way to take careof that in your opinion? Cast a (void *). These 
>>are the little things that you need to know so when you get into big 
>>programs could cause real problems.

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

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

#44045

On Mon, 05 May 2014 12:01:46 +0200, Richard <rgrdev_@gmail.com> wrote:

>Are you for real? You ALSO don't realise you're being trolled?!?!?!
>Life can't be fun when so easily made to jump for every treat.

It's obvious he is a troll.  So what?  It is more entertaining than
the currently never ending thread about Knuth.

-- 
Remove del for email

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

#44043

"Barry Schwarz" <schwarzb@dqel.com> wrote in message

> No you didn't.

    No.

 And you probably won't.

    I won't?

 This is the same advice you
> were given as recently as August 20, 2012.  Maybe you should consider
> saving some of the responses to your messages and rereading them to
> reinforce the lessons  they provide.

I don't know. Things have changed much over two years. I'm not concerned so 
much about blah blah 2012. I'm concerned about May 2014. Barry you've got 
better things to do. Right?


>>be the best way to take careof that in your opinion? Cast a (void *). 
>>These
>>are the little things that you need to know so when you get into big
>>programs could cause real problems.

    I don't expect to get into big programs. As said many times (where ya 
been?) I am not and don't expect to be a professional C programmer. I just 
want to work with a few APIs. But these things you don't get out of a book. 
And clc is not a place for a tutorial either. You dont "Teach C" on usenet.

You're smarter than that.

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

#44046

On Mon, 5 May 2014 14:18:57 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>
>"Barry Schwarz" <schwarzb@dqel.com> wrote in message
>
>> No you didn't.
>
>    No.
>
> And you probably won't.
>
>    I won't?
>
> This is the same advice you
>> were given as recently as August 20, 2012.  Maybe you should consider
>> saving some of the responses to your messages and rereading them to
>> reinforce the lessons  they provide.
>
>I don't know. Things have changed much over two years. I'm not concerned so 
>much about blah blah 2012. I'm concerned about May 2014. 

Proving once again that George Santayana was right.

>>>be the best way to take careof that in your opinion? Cast a (void *). 
>>>These
>>>are the little things that you need to know so when you get into big
>>>programs could cause real problems.
>
>    I don't expect to get into big programs.

I'm glad you don't.  But if you don't, why did you bring it up in the
first place and again now?  It is a quote from your message that I
didn't address at all.

-- 
Remove del for email

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

#44048

"Barry Schwarz" <schwarzb@dqel.com> wrote in message 
news:a6nfm958crqdoik3p7trnst1j17v73ebim@4ax.com...
> On Mon, 5 May 2014 14:18:57 -0400, "Bill Cunningham"
> <nospam@nspam.invalid> wrote:
>
>>
>>"Barry Schwarz" <schwarzb@dqel.com> wrote in message
>>
>>> No you didn't.
>>
>>    No.
>>
>> And you probably won't.
>>
>>    I won't?
>>
>> This is the same advice you
>>> were given as recently as August 20, 2012.  Maybe you should consider
>>> saving some of the responses to your messages and rereading them to
>>> reinforce the lessons  they provide.
>>
>>I don't know. Things have changed much over two years. I'm not concerned 
>>so
>>much about blah blah 2012. I'm concerned about May 2014.
>
> Proving once again that George Santayana was right.

    Well I don't know who George Santayana is and don't care. But I'm not 
going to get into my personal life with anyone on usenet about anything at 
any point in my life. 2, 5, or 20 years ago. But I will say that kandr2 
ain't doing it. And I have some more C books now that I didn't have 2 years 
ago.

[...]

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

#44049

"Bill Cunningham" <nospam@nspam.invalid> wrote in message 
news:lk8o9v$sie$1@dont-email.me...
>
> "Barry Schwarz" <schwarzb@dqel.com> wrote in message 
> news:a6nfm958crqdoik3p7trnst1j17v73ebim@4ax.com...
>> On Mon, 5 May 2014 14:18:57 -0400, "Bill Cunningham"
>> <nospam@nspam.invalid> wrote:
>>
>>>
>>>"Barry Schwarz" <schwarzb@dqel.com> wrote in message
>>>
>>>> No you didn't.
>>>
>>>    No.
>>>
>>> And you probably won't.
>>>
>>>    I won't?
>>>
>>> This is the same advice you
>>>> were given as recently as August 20, 2012.  Maybe you should consider
>>>> saving some of the responses to your messages and rereading them to
>>>> reinforce the lessons  they provide.
>>>
>>>I don't know. Things have changed much over two years. I'm not concerned 
>>>so
>>>much about blah blah 2012. I'm concerned about May 2014.
>>
>> Proving once again that George Santayana was right.
>
>    Well I don't know who George Santayana is and don't care. But I'm not 
> going to get into my personal life with anyone on usenet about anything at 
> any point in my life. 2, 5, or 20 years ago. But I will say that kandr2 
> ain't doing it. And I have some more C books now that I didn't have 2 
> years ago.
>
> [...]
>
    Oh yes and let me add too. They seem to have helped me but I will not 
mention them because guess what? They're all wrong! Even though the compiler 
accepts them and they seem to function!

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

#44059

On 5/5/2014 3:23 PM, Bill Cunningham wrote:
[...]
>      Oh yes and let me add too. They seem to have helped me but I will not
> mention them because guess what? They're all wrong! Even though the compiler
> accepts them and they seem to function!

I'm coming in late to this discussion, but compilers are allowed to accept 
invalid code, and (with some exceptions) are allowed to compile such code 
without a peep.

A compiler is allowed to accept:

     int i;
     printf("%d %d %d\n",i++,i++,i++);

and even generate the output that you expected.  That doesn't mean the code 
was valid.

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

#44064

"Ken Brody" <kenbrody@spamcop.net> wrote in message 
news:lkatil$7bp$1@dont-email.me...

[snip]

> and even generate the output that you expected.  That doesn't mean the 
> code was valid.

    They say there's a difference in coders and programmers.

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

#44034

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

> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnr44aj596.fsf@nuthaus.mib.org...
>> Tonton Th <tth@nowhere.invalid> writes:
>>> On 2014-05-04, Barry Schwarz <schwarzb@dqel.com> wrote:
>>>>>#include <stdio.h>
>>>>>
>>>>>int main()
>>>>>{
>>>>>    int a = 15;
>>>>>    int *p;
>>>>>    p = &a;
>>>>>    printf("%p\n", &p);
>>>>
>>>> Undefined behavior #1.
>>>>
>>>>>    printf("%p\n", p);
>>>>
>>>> Undefined behavior #2.
>>>>
>>>>>    printf("%d\n", *p);
>>>>>}
>>>
>>>    I don't understand where in the undefined behaviour. Not so usable
>>>    values printed, yes, but &p and p are pointers, so %p can print their
>>>    values, no ?
>>>
>>>    Maybe because p and &p are not 'void *' pointers...
>>
>> That's exactly it.  "%p" requires an argument of type void*, not of any
>> arbitrary pointer type.  In practice, most implementations use the same
>> representation and argument passing convention for all pointer types, so
>> it's likely to work, but for well-defined behavior you need to cast the
>> arguments to void*.
>
>     Well I learned something today new. I'll keep that in mind. What would 
> be the best way to take careof that in your opinion? Cast a (void *). These 
> are the little things that you need to know so when you get into big 
> programs could cause real problems.
>
> Bill
>

lol!

10/10

"when you get into big programs"

Genius!


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

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

#44050

On Sunday, May 4, 2014 8:06:07 PM UTC+1, Bill Cunningham wrote:
> 
>     Well I learned something today new. I'll keep that in mind. What would 
> be the best way to take careof that in your opinion? Cast a (void *). These 
> are the little things that you need to know so when you get into big 
> programs could cause real problems.
> 
Why do you need to print out a pointer?
I'm sure someone can think of a reason, but normally, only for debugging.
If a program is behaving strangely, you might want to print out a few
pointer values to see what they look like.
So typically you'll insert a daignostic printf("%p\n", ptr), take a
look at the problem, fix it, then delete the code.

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

#44053

"Malcolm McLean" <malcolm.mclean5@btinternet.com>

Why do you need to print out a pointer?
> I'm sure someone can think of a reason, but normally, only for debugging.
> If a program is behaving strangely, you might want to print out a few
> pointer values to see what they look like.
> So typically you'll insert a daignostic printf("%p\n", ptr), take a
> look at the problem, fix it, then delete the code.

    In real life I can't think of why. But my tutorials that are no good 
give me those examples. There  are certain things that you don't pick up out 
of the tutorials I now have that you can't get except from those with 
experience. The thing is I'm getting a little leary of the advice I'm 
getting. It's like asking someone for directions and they point to the right 
with the right arm and the left with the left arm and they don't seem to 
understand what I just asked.

Bill

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

#44054

"Bill Cunningham" wrote:

> The thing is I'm getting a little leary of the advice I'm getting. It's 
> like asking someone for directions and they point to the right with the 
> right arm and the left with the left arm and they don't seem to understand 
> what I just asked.

Is it possible that your writing is sometimes confusing?  You do realize 
that words such as them, they, those and so on have no intrinsic meaning, 
right?  So I replaced them by x and updated the grammar so it still reads 
like English. .

Do you recognize this?

Oh yes and let me add too. x seems to have helped me but I will not
mention x because guess what? x are all wrong! Even though the compiler
accepts x and x seems to function!

Now what is x?  A book? A person?  A program fragment?  A computer language? 
My guess is that there are at least two unknowns, an x and a y. But one 
"them" is indistinguishable from another "them", you see a distinction in 
your mind, you know what you mean.  But that is not very helpful to someone 
who can only see the words you type, not see into your mind.. 

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

#44057

"Osmium" <r124c4u102@comcast.net> wrote

> Is it possible that your writing is sometimes confusing?

    Very much so. I can understand that. And it causes some people to accuse 
me of saying or doing something I am not. I use contractions alot but I 
would think they would be understandable.

Bill

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

#44060

On 5/5/2014 11:13 PM, Bill Cunningham wrote:
> "Malcolm McLean" <malcolm.mclean5@btinternet.com>
>
> Why do you need to print out a pointer?
>> I'm sure someone can think of a reason, but normally, only for debugging.
>> If a program is behaving strangely, you might want to print out a few
>> pointer values to see what they look like.
>> So typically you'll insert a daignostic printf("%p\n", ptr), take a
>> look at the problem, fix it, then delete the code.
>
>      In real life I can't think of why. But my tutorials that are no good
> give me those examples. There  are certain things that you don't pick up out
> of the tutorials I now have that you can't get except from those with
> experience.

I can think of tutorials having a good reason to want to display pointers. 
Consider explaining why "str1==str2" is not the same as "strcmp(str1,str2)".

=====
#define	MyString "Hello, world.\n"
char foo1[] = MyString;
char bar1[] = MyString;
char *foo2 =  MyString;
char *bar2 =  MyString;
...
printf("foo1 is at address %p\nbar1 is at address %p\n",foo1,bar1);
printf("foo2 points to %p\nbar2 points to %p\n",foo2,bar2);
....
=====

> The thing is I'm getting a little leary of the advice I'm
> getting. It's like asking someone for directions and they point to the right
> with the right arm and the left with the left arm and they don't seem to
> understand what I just asked.

Perhaps it's because you ask for directions with questions like "I'm trying 
to drive backwards down a one-way street, but I'm not sure which key fits 
the ignition -- can you tell me how to put gas in the tank?"

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

#44061

Ken Brody <kenbrody@spamcop.net> writes:

> On 5/5/2014 11:13 PM, Bill Cunningham wrote:
>> "Malcolm McLean" <malcolm.mclean5@btinternet.com>
>>
>> Why do you need to print out a pointer?
>>> I'm sure someone can think of a reason, but normally, only for debugging.
>>> If a program is behaving strangely, you might want to print out a few
>>> pointer values to see what they look like.
>>> So typically you'll insert a daignostic printf("%p\n", ptr), take a
>>> look at the problem, fix it, then delete the code.
>>
>>      In real life I can't think of why. But my tutorials that are no good
>> give me those examples. There  are certain things that you don't pick up out
>> of the tutorials I now have that you can't get except from those with
>> experience.
>
> I can think of tutorials having a good reason to want to display
> pointers. Consider explaining why "str1==str2" is not the same as
> "strcmp(str1,str2)".
>
> =====
> #define	MyString "Hello, world.\n"
> char foo1[] = MyString;
> char bar1[] = MyString;
> char *foo2 =  MyString;
> char *bar2 =  MyString;
> ...
> printf("foo1 is at address %p\nbar1 is at address %p\n",foo1,bar1);
> printf("foo2 points to %p\nbar2 points to %p\n",foo2,bar2);
> ....
> =====
>
>> The thing is I'm getting a little leary of the advice I'm
>> getting. It's like asking someone for directions and they point to the right
>> with the right arm and the left with the left arm and they don't seem to
>> understand what I just asked.
>
> Perhaps it's because you ask for directions with questions like "I'm trying to
> drive backwards down a one-way street, but I'm not sure which key fits the
> ignition -- can you tell me how to put gas in the tank?"
>
>

Gadzooks.

Or he's trolling...

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

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

#44017

On 2014-05-04, Keith Thompson <kst-u@mib.org> wrote:
> Tonton Th <tth@nowhere.invalid> writes:
>> On 2014-05-04, Barry Schwarz <schwarzb@dqel.com> wrote:
>>>>#include <stdio.h>
>>>>
>>>>int main()
>>>>{
>>>>    int a = 15;
>>>>    int *p;
>>>>    p = &a;
>>>>    printf("%p\n", &p);
>>>
>>> Undefined behavior #1.
>>>
>>>>    printf("%p\n", p);
>>>
>>> Undefined behavior #2.
>>>
>>>>    printf("%d\n", *p);
>>>>}
>>
>>    I don't understand where in the undefined behaviour. Not so usable
>>    values printed, yes, but &p and p are pointers, so %p can print their
>>    values, no ?
>>
>>    Maybe because p and &p are not 'void *' pointers...
>
> That's exactly it.  "%p" requires an argument of type void*, not of any
> arbitrary pointer type.  In practice, most implementations use the same
> representation and argument passing convention for all pointer types, so
> it's likely to work, but for well-defined behavior you need to cast the
> arguments to void*.

For well-defined behavior, you must also avoid the inclusion of
any header which us not in ISO C nor in your program, such as

#include <unistd.h>

Standard-defined behavior is an unrealistic goal for many kinds
of programs. The concept broadly encompasses issues of correctness,
as well as portability.

The assumption that %p can print any pointer is not maximally
portable, that is all.

As a side note, it would be astonishing to find an implementation
where char * arguments break with %p in some way that goes
away when a cast to void * is added.


-- 
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List:  http://www.kylheku.com/mp1

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

#44028

On 2014-05-04, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2014-05-04, Keith Thompson <kst-u@mib.org> wrote:
>> Tonton Th <tth@nowhere.invalid> writes:
>>> On 2014-05-04, Barry Schwarz <schwarzb@dqel.com> wrote:
>>>>>#include <stdio.h>
>>>>>
>>>>>int main()
>>>>>{
>>>>>    int a = 15;
>>>>>    int *p;
>>>>>    p = &a;
>>>>>    printf("%p\n", &p);
>>>>
>>>> Undefined behavior #1.
>>>>
>>>>>    printf("%p\n", p);
>>>>
>>>> Undefined behavior #2.
>>>>
>>>>>    printf("%d\n", *p);
>>>>>}
>>>
>>>    I don't understand where in the undefined behaviour. Not so usable
>>>    values printed, yes, but &p and p are pointers, so %p can print their
>>>    values, no ?
>>>
>>>    Maybe because p and &p are not 'void *' pointers...
>>
>> That's exactly it.  "%p" requires an argument of type void*, not of any
>> arbitrary pointer type.  In practice, most implementations use the same
>> representation and argument passing convention for all pointer types, so
>> it's likely to work, but for well-defined behavior you need to cast the
>> arguments to void*.
>
> For well-defined behavior, you must also avoid the inclusion of
> any header which us not in ISO C nor in your program, such as
>
> #include <unistd.h>
>
> Standard-defined behavior is an unrealistic goal for many kinds
> of programs. The concept broadly encompasses issues of correctness,
> as well as portability.
>
> The assumption that %p can print any pointer is not maximally
> portable, that is all.

I'd like to add that you're not really doing a better job of programming
by doing things like printf("%p", (void *) ptr).

You're only wasting time on portability to a machine that you don't have.

If you don't have that machine, you have no way to verify to what
extent you have done a proper job (at least no empirical way).

In other words, portability to hardware that you don't have is half-assed
portability. Not a real portability that actually targets the machine,
and delivers a release for actual deployment somewhere.

Portability to hardware that you don't ever *plan* to have is not
economically justifiable: there is no business case for it.

So, the effort is doubly damned: you're doing a half-assed job of something for
which there is no business case in the first place.

(Kind of like working on a new ISO C standard, isn't it.)

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

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

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

csiph-web