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

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

Typecasting Pointers on a 64 bit System

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

Contents

  Typecasting Pointers on a 64 bit System Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-10 20:21 +0000
    Re: Typecasting Pointers on a 64 bit System Lauri Alanko <la@iki.fi> - 2011-11-10 20:29 +0000
      Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 20:51 +0000
        Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 20:58 +0000
        Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-10 16:08 -0500
          Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 21:35 +0000
            Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-10 17:18 -0500
              Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 23:14 +0000
                Re: Typecasting Pointers on a 64 bit System Richard Damon <news.x.richarddamon@xoxy.net> - 2011-11-10 19:36 -0500
    Re: Typecasting Pointers on a 64 bit System Ben Pfaff <blp@cs.stanford.edu> - 2011-11-10 12:32 -0800
      Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-10 15:44 -0500
      Re: Typecasting Pointers on a 64 bit System Keith Thompson <kst-u@mib.org> - 2011-11-10 12:58 -0800
        Re: Typecasting Pointers on a 64 bit System blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-17 15:53 +0000
    Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 20:45 +0000
      Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 21:00 +0000
    Re: Typecasting Pointers on a 64 bit System Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-10 15:14 -0700
    Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-11 11:22 +1300
      Re: Typecasting Pointers on a 64 bit System William Ahern <william@wilbur.25thandClement.com> - 2011-11-14 11:10 -0800
        Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 08:28 +1300
          Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 14:48 -0500
            Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:15 +1300
              Re: Typecasting Pointers on a 64 bit System jacob navia <jacob@spamsink.net> - 2011-11-14 22:18 +0100
                Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:26 +1300
              Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 16:46 -0500
                Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 10:58 +1300
                  Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 17:15 -0500
                    Re: Typecasting Pointers on a 64 bit System blp@cs.stanford.edu (Ben Pfaff) - 2011-11-14 14:18 -0800
                    Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 11:29 +1300
                      Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 18:14 -0500
                        Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-14 23:01 +0000
                          Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-16 10:39 +0200
                            Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-16 20:18 +0000
                            Re: Typecasting Pointers on a 64 bit System Fritz Wuehler <fritz@spamexpire-201111.rodent.frell.theremailer.net> - 2011-11-17 02:54 +0100
                              Re: Typecasting Pointers on a 64 bit System pete <pfiland@mindspring.com> - 2011-11-16 21:29 -0500
                              Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-17 02:31 +0000
                                Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 14:31 +0200
                              Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-17 02:44 +0000
                              Re: Typecasting Pointers on a 64 bit System Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-16 21:33 -0700
                          Re: Typecasting Pointers on a 64 bit System "io_x" <a@b.c.invalid> - 2011-11-17 04:01 +0100
                          Re: Typecasting Pointers on a 64 bit System blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-17 15:46 +0000
                            Re: Typecasting Pointers on a 64 bit System Seebs <usenet-nospam@seebs.net> - 2011-11-17 18:48 +0000
                              Re: Typecasting Pointers on a 64 bit System blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> - 2011-11-18 14:48 +0000
                        Re: Typecasting Pointers on a 64 bit System Ian Collins <ian-news@hotmail.com> - 2011-11-15 14:37 +1300
                    Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-16 10:23 +0200
                      Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-16 06:53 -0500
                        Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-16 11:15 -0500
                          Re: Typecasting Pointers on a 64 bit System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-16 17:08 +0000
                          Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 15:09 +0200
                        Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 14:24 +0200
                          Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-18 10:08 -0500
                            Re: Typecasting Pointers on a 64 bit System Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 17:52 +0200
              Re: Typecasting Pointers on a 64 bit System Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-14 15:45 -0700
    Re: Typecasting Pointers on a 64 bit System "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-11-10 15:19 -0800
      Re: Typecasting Pointers on a 64 bit System Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 23:41 +0000
        Re: Typecasting Pointers on a 64 bit System Keith Thompson <kst-u@mib.org> - 2011-11-10 20:48 -0800
        Re: Typecasting Pointers on a 64 bit System "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-11-14 03:39 -0800
          Re: Typecasting Pointers on a 64 bit System Lauri Alanko <la@iki.fi> - 2011-11-14 13:08 +0000
            Re: Typecasting Pointers on a 64 bit System James Kuyper <jameskuyper@verizon.net> - 2011-11-14 09:21 -0500
          Re: Typecasting Pointers on a 64 bit System Keith Thompson <kst-u@mib.org> - 2011-11-14 12:54 -0800

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

#13317

On 11/15/11 08:48 AM, James Kuyper wrote:
> On 11/14/2011 02:28 PM, Ian Collins wrote:
>> On 11/15/11 08:10 AM, William Ahern wrote:
> ....
>>> Pass-by-reference and threads aren't
>>> known to play well. IMHO the OP had sensible intuition to pass the
>>> descriptor by value. It may not be pretty in C, but neither is threaded
>>> programming.
>>
>> As long as the address is still valid when a thread dereferences it,
>> what's the problem?
>
> The possibility that the address might NOT still be valid at the time of
> use. This has already been pointed out, and is explicitly considered
> (but somehow ignored as unimportant) in your own response.

I had assumed a competent programmer would be aware of the issue.  I had 
further assumed a programmer writing threaded applications to be 
competent.  If either of those assumptions are untrue, the programmer's 
foray into threaded programming will be brief and painful.

> A relevant response would give reasons justifying your treatment of that
> possibility as unimportant.

Where did I say it was unimportant?  Do you expect me to qualify every 
mention of passing an address?

-- 
Ian Collins

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

#13319

Le 14/11/11 22:15, Ian Collins a écrit :
> On 11/15/11 08:48 AM, James Kuyper wrote:
>> On 11/14/2011 02:28 PM, Ian Collins wrote:
>>> On 11/15/11 08:10 AM, William Ahern wrote:
>> ....
>>>> Pass-by-reference and threads aren't
>>>> known to play well. IMHO the OP had sensible intuition to pass the
>>>> descriptor by value. It may not be pretty in C, but neither is threaded
>>>> programming.
>>>
>>> As long as the address is still valid when a thread dereferences it,
>>> what's the problem?
>>
>> The possibility that the address might NOT still be valid at the time of
>> use. This has already been pointed out, and is explicitly considered
>> (but somehow ignored as unimportant) in your own response.
>
> I had assumed a competent programmer would be aware of the issue. I had
> further assumed a programmer writing threaded applications to be
> competent. If either of those assumptions are untrue, the programmer's
> foray into threaded programming will be brief and painful.
>

Well, it is not a matter of competence Ian, calm down. I think Mr Kuyper
wants to point out that a solution passing some pointer instead of a
value provokes further complexities that obviously *could* be handled
by a competent programmer but that complexify the interface of that 
function...

If I understood him correctly that is.

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

#13320

On 11/15/11 10:18 AM, jacob navia wrote:
> Le 14/11/11 22:15, Ian Collins a écrit :
>> On 11/15/11 08:48 AM, James Kuyper wrote:
>>> On 11/14/2011 02:28 PM, Ian Collins wrote:
>>>> On 11/15/11 08:10 AM, William Ahern wrote:
>>> ....
>>>>> Pass-by-reference and threads aren't
>>>>> known to play well. IMHO the OP had sensible intuition to pass the
>>>>> descriptor by value. It may not be pretty in C, but neither is threaded
>>>>> programming.
>>>>
>>>> As long as the address is still valid when a thread dereferences it,
>>>> what's the problem?
>>>
>>> The possibility that the address might NOT still be valid at the time of
>>> use. This has already been pointed out, and is explicitly considered
>>> (but somehow ignored as unimportant) in your own response.
>>
>> I had assumed a competent programmer would be aware of the issue. I had
>> further assumed a programmer writing threaded applications to be
>> competent. If either of those assumptions are untrue, the programmer's
>> foray into threaded programming will be brief and painful.
>>
>
> Well, it is not a matter of competence Ian, calm down. I think Mr Kuyper
> wants to point out that a solution passing some pointer instead of a
> value provokes further complexities that obviously *could* be handled
> by a competent programmer but that complexify the interface of that
> function...
>
> If I understood him correctly that is.

:)

I'm quite calm.  I just had a strong urge to be pompous...

As an aside, the problem (a dangling pointer) tends not to happen with 
pthreads because the default behaviour of pthread_create is to create a 
joinable thread.  So I'd also assumed there would be pthread_join 
further on in the code.

-- 
Ian Collins

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

#13322

On 11/14/2011 04:15 PM, Ian Collins wrote:
> On 11/15/11 08:48 AM, James Kuyper wrote:
>> On 11/14/2011 02:28 PM, Ian Collins wrote:
>>> On 11/15/11 08:10 AM, William Ahern wrote:
>> ....
>>>> Pass-by-reference and threads aren't
>>>> known to play well. IMHO the OP had sensible intuition to pass the
>>>> descriptor by value. It may not be pretty in C, but neither is threaded
>>>> programming.
>>>
>>> As long as the address is still valid when a thread dereferences it,
>>> what's the problem?
>>
>> The possibility that the address might NOT still be valid at the time of
>> use. This has already been pointed out, and is explicitly considered
>> (but somehow ignored as unimportant) in your own response.
> 
> I had assumed a competent programmer would be aware of the issue.  I had 
> further assumed a programmer writing threaded applications to be 
> competent.  If either of those assumptions are untrue, the programmer's 
> foray into threaded programming will be brief and painful.

That second assumption seems unjustified to me, and I would say the same
about your assumption that the painful foray will be short. I've seen an
incompetent programmer spend several long painful months trying to deal
with problems caused by a much simpler misunderstanding (and I'm not
talking about Bill Cunningham). If the particular programmer I'm
thinking of had bothered spending 5 minutes asking me questions, that
waste could have been avoided, but I had no idea that he was wasting his
time that way. He was under orders to ask me questions if he ran into
trouble, but never did so - he never gave a coherent explanation of why
he didn't.

However, neither assumption seems to be relevant here. As long as this
is an issue that the programmer needs to be aware of, the need for such
awareness IS the problem that you're asking about.

>> A relevant response would give reasons justifying your treatment of that
>> possibility as unimportant.
> 
> Where did I say it was unimportant?

You asked "what's the problem?" in the same sentence where you conceded
both the existence and relevance of the problem you were asking about.
The simplest explanation I could come up with for such a seemingly
bizarre combination was that you considered the problem you mentioned to
be unimportant, and were challenging people to come up with a more
important one, with the expectation that they would not succeed. I'll
concede that there might be other reasons for writing a sentence with
that structure, but the variety of those other possible reasons is
great, and the probability that any particular one of them is justified
is small. It would improve my understanding of the point of your message
if you could explain your reason for posting such a question.

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

#13323

On 11/15/11 10:46 AM, James Kuyper wrote:
> On 11/14/2011 04:15 PM, Ian Collins wrote:
>> On 11/15/11 08:48 AM, James Kuyper wrote:
>
>>> A relevant response would give reasons justifying your treatment of that
>>> possibility as unimportant.
>>
>> Where did I say it was unimportant?
>
> You asked "what's the problem?" in the same sentence where you conceded
> both the existence and relevance of the problem you were asking about.

In the same vein as "as long as you hold the knife by the handle, what's 
the problem?".

> The simplest explanation I could come up with for such a seemingly
> bizarre combination was that you considered the problem you mentioned to
> be unimportant, and were challenging people to come up with a more
> important one, with the expectation that they would not succeed. I'll
> concede that there might be other reasons for writing a sentence with
> that structure, but the variety of those other possible reasons is
> great, and the probability that any particular one of them is justified
> is small. It would improve my understanding of the point of your message
> if you could explain your reason for posting such a question.

Wow, I consider my pomposity well and truly trumped!

-- 
Ian Collins

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

#13324

On 11/14/2011 04:58 PM, Ian Collins wrote:
> On 11/15/11 10:46 AM, James Kuyper wrote:
>> On 11/14/2011 04:15 PM, Ian Collins wrote:
>>> On 11/15/11 08:48 AM, James Kuyper wrote:
>>
>>>> A relevant response would give reasons justifying your treatment of that
>>>> possibility as unimportant.
>>>
>>> Where did I say it was unimportant?
>>
>> You asked "what's the problem?" in the same sentence where you conceded
>> both the existence and relevance of the problem you were asking about.
> 
> In the same vein as "as long as you hold the knife by the handle, what's 
> the problem?".

I would interpret a question such as that as one which dismisses the
importance of having to hold the knife by the handle, because it's easy
to arrange to do so. I had assumed you were doing the same: implicitly
asserting that it's trivial to arrange that the address remains valid; I
was rather surprised when you vehemently denied that inference. I had
expected an explanation of why it is trivial.

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

#13325

James Kuyper <jameskuyper@verizon.net> writes:

> On 11/14/2011 04:58 PM, Ian Collins wrote:
>> On 11/15/11 10:46 AM, James Kuyper wrote:
>>> On 11/14/2011 04:15 PM, Ian Collins wrote:
>>>> On 11/15/11 08:48 AM, James Kuyper wrote:
>>>
>>>>> A relevant response would give reasons justifying your treatment of that
>>>>> possibility as unimportant.
>>>>
>>>> Where did I say it was unimportant?
>>>
>>> You asked "what's the problem?" in the same sentence where you conceded
>>> both the existence and relevance of the problem you were asking about.
>> 
>> In the same vein as "as long as you hold the knife by the handle, what's 
>> the problem?".
>
> I would interpret a question such as that as one which dismisses the
> importance of having to hold the knife by the handle, because it's easy
> to arrange to do so. I had assumed you were doing the same: implicitly
> asserting that it's trivial to arrange that the address remains valid; I
> was rather surprised when you vehemently denied that inference. I had
> expected an explanation of why it is trivial.

Sure it's trivial.  In the old thread, malloc(sizeof(int)), put
the file descriptor there and pass the malloc'd pointer.  In the
new thread, dereference the pointer to get the file descriptor,
then free it.
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

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

#13328

On 11/15/11 11:15 AM, James Kuyper wrote:
> On 11/14/2011 04:58 PM, Ian Collins wrote:
>> On 11/15/11 10:46 AM, James Kuyper wrote:
>>> On 11/14/2011 04:15 PM, Ian Collins wrote:
>>>> On 11/15/11 08:48 AM, James Kuyper wrote:
>>>
>>>>> A relevant response would give reasons justifying your treatment of that
>>>>> possibility as unimportant.
>>>>
>>>> Where did I say it was unimportant?
>>>
>>> You asked "what's the problem?" in the same sentence where you conceded
>>> both the existence and relevance of the problem you were asking about.
>>
>> In the same vein as "as long as you hold the knife by the handle, what's
>> the problem?".
>
> I would interpret a question such as that as one which dismisses the
> importance of having to hold the knife by the handle, because it's easy
> to arrange to do so. I had assumed you were doing the same: implicitly
> asserting that it's trivial to arrange that the address remains valid; I
> was rather surprised when you vehemently denied that inference. I had
> expected an explanation of why it is trivial.

I think our opinions on what constitutes common sense differ somewhat. 
I see not passing a pointer to something that has gone out of scope in 
the same way as not holding a knife by the blade.  In both cases, doing 
the consequences of doing the wrong thing tend to deter a repeat.

Or maybe I've just been doing this stuff for way to long...

-- 
Ian Collins

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

#13333

On 11/14/2011 05:29 PM, Ian Collins wrote:
...
> I think our opinions on what constitutes common sense differ somewhat. 

Probably; I think that the existence of "common sense" is a popular
delusion, based upon people projecting onto others their own
understanding of things. People suffering from that delusion often hold
those others to blame for the failure of that projection to match reality.

> I see not passing a pointer to something that has gone out of scope in 
> the same way as not holding a knife by the blade.  In both cases, doing 
> the consequences of doing the wrong thing tend to deter a repeat.
> 
> Or maybe I've just been doing this stuff for way to long...

Attempting to dereference a pointer to memory that has already been
deallocated is one of the most common nasty mistakes made by C
programmers. There are many other mistakes that are more common, but
most of them are easier to diagnose than that one. I'm no expert in
multi-threaded code, but it seems to me that the problem can only be
worse if the dynamically allocated memory is shared between threads.

Several participants on this thread suggested that this was a serious
problem, you've suggested that its trivial. I think that they may be
exaggerating the difficulty, while you may be doing the opposite; I was
hoping to provoke a more detailed discussion that would clarify the
discrepancy. Instead I seem to have only provoked a discussion about my
provocation.

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

#13336

On 2011-11-14, James Kuyper <jameskuyper@verizon.net> wrote:
> Probably; I think that the existence of "common sense" is a popular
> delusion, based upon people projecting onto others their own
> understanding of things. People suffering from that delusion often hold
> those others to blame for the failure of that projection to match reality.

I tend towards this view, myself.

If nothing else, I do not consider it safe to assume that generic programmers
not previously verified to understand the issues have any awareness of the
issues of passing the address of "some object somewhere" into a thread
mechanism or the like.

Heck.

Consider:

	struct foo *f = malloc(sizeof(*f));
	free(f);
	f->x = 1;

I do not consider it a reasonable assumption that an arbitrary person
with 3-5 years or more of experience programming C will see anything
wrong here.  I've seen someone who had >10 years claimed experience and
got promoted to lead engineer for a project who insisted that this was
not only permissible but the only way to avoid memory leaks in C.

... And yes, the project failed utterly and everyone involved lost their
jobs.  Funny only because it was over a decade ago.  :)

It is very easy for people who have finally been taught that it's not okay
to return the address of a local variable to conclude that it's fine to
pass the address of a local variable to a function you call.  And you're
*calling* pthread_create(), see.  So that's fine.

Worse yet if they have done a lot of work in a language with closures.  :)

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#13465

Seebs <usenet-nospam@seebs.net> writes:
> Consider:
> 
> 	struct foo *f = malloc(sizeof(*f));
> 	free(f);
> 	f->x = 1;
> 
> I do not consider it a reasonable assumption that an arbitrary person
> with 3-5 years or more of experience programming C will see anything
> wrong here.

Astounding. And I say that as someone who's spent a long time in maintenance
fixing major fuck-ups by people who just didn't get it. But not one of them
(even the "we've read /Design Patterns/, we don't have to care about O(n^2)
getting huge" crowd, and even the "shift by N bits by shifting by 1 bit N-1 
times" dude) would have done *that*.

I hope you're exagerating. I guess I should get a nice warm feeling of
comfort that ${DAYJOB} really is about as great a bunch of coders as
you could ever hope to work with.

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

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

#13514

On 2011-11-16, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> Consider:
>> 
>> 	struct foo *f = malloc(sizeof(*f));
>> 	free(f);
>> 	f->x = 1;
>> 
>> I do not consider it a reasonable assumption that an arbitrary person
>> with 3-5 years or more of experience programming C will see anything
>> wrong here.

> Astounding. And I say that as someone who's spent a long time in maintenance
> fixing major fuck-ups by people who just didn't get it. But not one of them
> (even the "we've read /Design Patterns/, we don't have to care about O(n^2)
> getting huge" crowd, and even the "shift by N bits by shifting by 1 bit N-1 
> times" dude) would have done *that*.

You would be amazed.

> I hope you're exagerating. I guess I should get a nice warm feeling of
> comfort that ${DAYJOB} really is about as great a bunch of coders as
> you could ever hope to work with.

Nope, not exaggerating.  Couple jobs back, there was this guy who had
on paper a decade of C experience, who absolutely *insisted* that this
had to work, and was the only reasonable way to avoid memory leaks.

And he got promoted to being in charge of stuff.

But yeah.  It is sort of astounding, but then...  I read a lot of code,
and it is full of nonsense.  Today's:

	*p++ = toupper((unsigned char) *p);

This is in code that's widely used, and gcc even warns about it... If
you compile at -O0.  Which most people don't.

In another fairly famous piece of software, we came across:

	unsigned char x;

	x = NULL;

which, again, "had worked most of the time".

I guess that's the thing.  Most code is not subject to serious technical
review, and most programmers are sorta shoddy.  Heck, I do horrible stuff,
it's just that I usually get it caught in review, or I catch it myself
if I'm lucky.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#13532

> Seebs <usenet-nospam@seebs.net> writes:
> > Consider:
> > 
> > 	struct foo *f = malloc(sizeof(*f));
> > 	free(f);
> > 	f->x = 1;
> > 
> > I do not consider it a reasonable assumption that an arbitrary person
> > with 3-5 years or more of experience programming C will see anything
> > wrong here.

Let's try something else. I have a lot of experience in programming but I
have written about 10 lines of C (and no Java, C++ or anything related) and
not had to work with it or close to it ever.

Does this code fragment mean

1. allocate some storage
2. free it
3. assign a value to the area pointed to by the pointer to the storage you just
   freed 

If so that won't work forever, especially not in a multiuser or
multiprocessing environment. It might work for a long time on a single user
DOS though. Where is this code supposed to run?

If I got it right you don't need 3-5 years of programming in C to realize
the problem you just need to have a clue. If I am wrong then I will probably
need 3-5 years of programming in C to understand the issue!

Btw I don't understand the nuances of the first line, does it mean define a
structure called foo that contains a pointer to storage enough for one
pointer to a structure named foo that contains only a pointer?

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

#13533

Fritz Wuehler wrote:
> 
> > Seebs <usenet-nospam@seebs.net> writes:
> > > Consider:
> > >
> > >     struct foo *f = malloc(sizeof(*f));
 
> Btw I don't understand the nuances of the first line,
> does it mean define a
> structure called foo that contains a pointer to storage enough for one
> pointer to a structure named foo that contains only a pointer?

Close.

It means that struct foo has been previously defined,

and that (f) is a pointer to that type
and that the malloc call will 
either
     allocate enough memory for one structure of that type 
     and initialize (f) with the address of that memory
or
     malloc will not allocate memory
     and will initialize (f) with a null pointer value.

-- 
pete

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

#13534

On 2011-11-17, Fritz Wuehler <fritz@spamexpire-201111.rodent.frell.theremailer.net> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>> > Consider:

>> > 	struct foo *f = malloc(sizeof(*f));
>> > 	free(f);
>> > 	f->x = 1;

>> > I do not consider it a reasonable assumption that an arbitrary person
>> > with 3-5 years or more of experience programming C will see anything
>> > wrong here.

> Let's try something else. I have a lot of experience in programming but I
> have written about 10 lines of C (and no Java, C++ or anything related) and
> not had to work with it or close to it ever.

> Does this code fragment mean

> 1. allocate some storage
> 2. free it
> 3. assign a value to the area pointed to by the pointer to the storage you just
>    freed 

Yup.

> If so that won't work forever, especially not in a multiuser or
> multiprocessing environment. It might work for a long time on a single user
> DOS though. Where is this code supposed to run?

It was running originally on SunOS, which is Unixy, and in which the
default behavior (everything involved was single-threaded) was basically
that the pointer would probably stay valid for a while until something else
got allocated using the same space.

> If I got it right you don't need 3-5 years of programming in C to realize
> the problem you just need to have a clue. If I am wrong then I will probably
> need 3-5 years of programming in C to understand the issue!

Well, yes.  And that's my point; it is not reasonable to infer that someone
who has been professionally programming for several years in a language has
any particular clue.

Which is why I think pointing out that there are risks involved in, say,
handing a pointer to allocated memory to another thread in a multithreaded
program is probably reasonable.  Yes, all the experienced-and-competent
programmers know that, but lots of people are only one or the other of
those, and lots are neither.

> Btw I don't understand the nuances of the first line, does it mean define a
> structure called foo that contains a pointer to storage enough for one
> pointer to a structure named foo that contains only a pointer?

No, it means declare a pointer-to-struct-foo named 'f', and set the pointer
to the return of malloc(N), where N is "the number of bytes you need to
hold a thing of the same type as *f".

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#13587

Seebs <usenet-nospam@seebs.net> writes:
> On 2011-11-17, Fritz Wuehler <fritz@spamexpire-201111.rodent.frell.theremailer.net> wrote:
> >> Seebs <usenet-nospam@seebs.net> writes:
> >> > Consider:
> 
> >> > 	struct foo *f = malloc(sizeof(*f));
> >> > 	free(f);
> >> > 	f->x = 1;
> 
> >> > I do not consider it a reasonable assumption that an arbitrary person
> >> > with 3-5 years or more of experience programming C will see anything
> >> > wrong here.
> 
> > Let's try something else. I have a lot of experience in programming but I
> > have written about 10 lines of C (and no Java, C++ or anything related) and
> > not had to work with it or close to it ever.
> 
> > Does this code fragment mean
> 
> > 1. allocate some storage
> > 2. free it
> > 3. assign a value to the area pointed to by the pointer to the storage you just
> >    freed 
> 
> Yup.

I wonder if the guy had learnt just enough Unixy stuff to make that knowledge
dangerous. Compare:

open temp file
unlink it
use it

Phil
-- 
Unix is simple. It just takes a genius to understand its simplicity
-- Dennis Ritchie (1941-2011), Unix Co-Creator

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

#13538

On 2011-11-17, Fritz Wuehler <fritz@spamexpire-201111.rodent.frell.theremailer.net> wrote:
>> Seebs <usenet-nospam@seebs.net> writes:
>> > Consider:
>> > 
>> > 	struct foo *f = malloc(sizeof(*f));
>> > 	free(f);
>> > 	f->x = 1;
>> > 
>> > I do not consider it a reasonable assumption that an arbitrary person
>> > with 3-5 years or more of experience programming C will see anything
>> > wrong here.
>
> Let's try something else. I have a lot of experience in programming but I
> have written about 10 lines of C (and no Java, C++ or anything related) and
> not had to work with it or close to it ever.
>
> Does this code fragment mean
>
> 1. allocate some storage
> 2. free it
> 3. assign a value to the area pointed to by the pointer to the storage you just
>    freed 
>
> If so that won't work forever, especially not in a multiuser or
> multiprocessing environment.

In practical terms (how this typically works): the freed object's memory area
is no longer owned by the program, but by the memory allocator.  The memory
allocator can put bits there, such as link pointers that put the object on a
free list. If that is how the allocator works, it will typically put those
bits there right away, before the free function returns.

In many memory allocators, in the interests of saving space, allocated objects
do not have any headers. This allows objects to be adjacently allocated with
no wasted space.  Only free objects are kept on free lists, and the bookkeeping
pieces such as pointer and flag fields for keeping free lists go inside
the objects, in the same memory where the application's data used to be
when those objects were allocated.

After the program did the above, it might continue executing fine until the
next time it makes any kind of call to the memory allocator. This is true even
if there is no concurrency. The memory allocator might walk its free lists
and hit a bad pointer due to the clobbered memory location.

In ``ISO C language lawyer'' terms, as soon sa free(f) is called, the pointer f
(and all copies of f that the program may have elsewhere) become
``indeterminate'' values.  The use of an indeterminately-valued object results
in undefined behavior.

I.e undefined behavior occurs in the expression f->x itself, regardless of the
assignment to that location f->x = 1. The expression f->x uses the pointer f
(to access the place x, or to designate it as an lvalue). This use is undefined
since f is indeterminate.

> It might work for a long time on a single user
> DOS though.

Perhaps, if the program does not ever make another call to functions like
malloc, free, realloc, calloc again.

If the DOS memory allocator is being directly used by malloc, this might screw
up the operating system.

> If I got it right you don't need 3-5 years of programming in C to realize
> the problem you just need to have a clue.
> If I am wrong then I will probably
> need 3-5 years of programming in C to understand the issue!
>
> Btw I don't understand the nuances of the first line, does it mean define a

The snippet is incomplete.  The first line assumes that there is a 'struct foo'
type that has been previously defined, which has a member x of integer type (or
some arithmetic type to which 1 can be assigned). The first line could define
the type by including the body of the structure:

  struct foo { int x; } *f = malloc(sizeof *f);

This is a declaration with an initializer. The 'struct foo .. { ... }'
is the list of declaration specifiers (containing one specifier: that
for a structure type).  The *f part is a declarator, declaring a name f.
The * type construction operator means that f is declared as a pointer
type (a pointer to what? The type produced by the declaration specifier list).

C declarations are split into specifiers and declarators, which allows
multiple declarators to hang off a shared "stem" of specifiers, and
yet declare different kinds of things:

  /* x is of type int; y is a pointer to int; 
     z is a function of no arguments returning int. */

  int x, *y, (*z)(void);

Our pointer f is initialized from the return value of a call to the principal C
memory allocation function, malloc. sizeof is an operator for computing the
sizes of types based on object-designating expressions or type expressions, and
*f is an object-designating expression which means "the object obtained by
dereferencing the pointer f". f is not yet initialized, so the object does not
exist, but that doesn't matter because sizeof doesn't use an expression's
value, only its type.  The type of *f is "struct foo". So we are asking malloc
for enough bytes to cover the structure.

If you write    some_type *p = malloc(sizeof *p),  then the size automatically
adjusts itself if you edit something to other_type: you have not
mentioned the type name in two places, as in:
some_type *p = malloc(sizeof (some_type)); /* more error-prone */

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

#13543

Fritz Wuehler <fritz@spamexpire-201111.rodent.frell.theremailer.net>
writes:

>> Seebs <usenet-nospam@seebs.net> writes:
>> > Consider:
>> > 
>> > 	struct foo *f = malloc(sizeof(*f));
>> > 	free(f);
>> > 	f->x = 1;
>> > 
>> > I do not consider it a reasonable assumption that an arbitrary person
>> > with 3-5 years or more of experience programming C will see anything
>> > wrong here.
>
> Let's try something else. I have a lot of experience in programming but I
> have written about 10 lines of C (and no Java, C++ or anything related) and
> not had to work with it or close to it ever.
>
> Does this code fragment mean
>
> 1. allocate some storage
> 2. free it
> 3. assign a value to the area pointed to by the pointer to the storage you just
>    freed 
>
> If so that won't work forever, especially not in a multiuser or
> multiprocessing environment. It might work for a long time on a single user
> DOS though. Where is this code supposed to run?

You're right that it won't work forever -- it's going to fail as soon as
that space is malloc'ed again, and written over.  Whenever that is.

This has absolutely nothing to do with multiuser or multiprocessing
environments, as processes all have their own address space (subject to
some very specific sharing, which won't have anything to do with the
dynamic memory heap).

> If I got it right you don't need 3-5 years of programming in C to realize
> the problem you just need to have a clue. If I am wrong then I will probably
> need 3-5 years of programming in C to understand the issue!
>
> Btw I don't understand the nuances of the first line, does it mean define a
> structure called foo that contains a pointer to storage enough for one
> pointer to a structure named foo that contains only a pointer?

It means declare a pointer to an object of type 'struct foo' (that's
what the 'struct foo *f' part means, allocate a block of storage
large enough to hold an object of that size, and assign the pointer to
point at the space (that's what the '= malloc(sizeof(*f));' part
means).

'struct foo' must have been defined elsewhere for this to work.

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

#13539

"Seebs" <usenet-nospam@seebs.net> ha scritto nel messaggio
news:slrnjc38ub.r7s.usenet-nospam@guild.seebs.net...
> On 2011-11-14, James Kuyper <jameskuyper@verizon.net> wrote:
>> Probably; I think that the existence of "common sense" is a popular
>> delusion, based upon people projecting onto others their own
>> understanding of things. People suffering from that delusion often hold
>> those others to blame for the failure of that projection to match reality.
>
> I tend towards this view, myself.
>
> If nothing else, I do not consider it safe to assume that generic programmers
> not previously verified to understand the issues have any awareness of the
> issues of passing the address of "some object somewhere" into a thread
> mechanism or the like.
>
> Heck.
>
> Consider:
>
> struct foo *f = malloc(sizeof(*f));
> free(f);
> f->x = 1;
>
> I do not consider it a reasonable assumption that an arbitrary person
> with 3-5 years or more of experience programming C will see anything
> wrong here.  I've seen someone who had >10 years claimed experience and
> got promoted to lead engineer for a project who insisted that this was
> not only permissible but the only way to avoid memory leaks in C.

problems of above code in my vew:
0) i cannot write memory just free()
1) when free() is possible that, afther some time some piece of heap
   can be free() to the sys: so that code here has segfault
2) when free() the data is put in the free list, in a multitread program
   it is possible some other thread has the memory that thread write
3) the same for malloc() in a multithread program
   that return &f + 20 if the size of that pointer is in &f->x
   in the header of the pointer in the size of pointer area;
   so this can make wrong all heap if that heap not check for size too
   of each pointer return from malloc()

> ... And yes, the project failed utterly and everyone involved lost their
> jobs.  Funny only because it was over a decade ago.  :)
>
> It is very easy for people who have finally been taught that it's not okay
> to return the address of a local variable to conclude that it's fine to
> pass the address of a local variable to a function you call.  And you're
> *calling* pthread_create(), see.  So that's fine.
>
> Worse yet if they have done a lot of work in a language with closures.  :)
>
> -s
> -- 
> Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
> http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
> http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
> I am not speaking for my employer, although they do rent some of my opinions.

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

#13558

In article <slrnjc38ub.r7s.usenet-nospam@guild.seebs.net>,
Seebs  <usenet-nospam@seebs.net> wrote:
> On 2011-11-14, James Kuyper <jameskuyper@verizon.net> wrote:
> > Probably; I think that the existence of "common sense" is a popular
> > delusion, based upon people projecting onto others their own
> > understanding of things. People suffering from that delusion often hold
> > those others to blame for the failure of that projection to match reality.
> 
> I tend towards this view, myself.
> 
> If nothing else, I do not consider it safe to assume that generic programmers
> not previously verified to understand the issues have any awareness of the
> issues of passing the address of "some object somewhere" into a thread
> mechanism or the like.
> 
> Heck.
> 
> Consider:
> 
> 	struct foo *f = malloc(sizeof(*f));
> 	free(f);
> 	f->x = 1;
> 
> I do not consider it a reasonable assumption that an arbitrary person
> with 3-5 years or more of experience programming C will see anything
> wrong here.  I've seen someone who had >10 years claimed experience and
> got promoted to lead engineer for a project who insisted that this was
> not only permissible but the only way to avoid memory leaks in C.

Remarkable.  Just .... remarkable.

For some reason lately the following quotation, attributed to Charles
Babbage, has been coming to mind a lot:

"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly
apprehend the kind of confusion of ideas that could provoke such
a question." -- Charles Babbage (1791-1871)

Something about that "I am not able to rightly apprehend the kind
of confusion of ideas ...."  :-)

> ... And yes, the project failed utterly and everyone involved lost their
> jobs.  Funny only because it was over a decade ago.  :)
> 
> It is very easy for people who have finally been taught that it's not okay
> to return the address of a local variable to conclude that it's fine to
> pass the address of a local variable to a function you call.  And you're
> *calling* pthread_create(), see.  So that's fine.

Well, now *I*'m the one who's confused ....  Are you saying
it's not fine?  I suppose if the function you call creates an
independent thread, and that thread persists longer than the one
that created it, yes, there could be a problem ....  Was that
your point?

> Worse yet if they have done a lot of work in a language with closures.  :)

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.

[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