Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Typecasting Pointers on a 64 bit System

Reply
Thread Tools

Typecasting Pointers on a 64 bit System

 
 
James Kuyper
Guest
Posts: n/a
 
      11-14-2011
On 11/14/2011 08:08 AM, Lauri Alanko wrote:
> In article <(E-Mail Removed)>,
> christian.bau <(E-Mail Removed)> wrote:
>> on
>> MacOS X 64 bit and probably on other 64 bit systems casting an int to
>> a pointer will _always_ invoke undefined behavior unless the int has a
>> value of 0, and that therefore the result is always a null pointer.

>
> On MacOS X the result may indeed be a null pointer, but, as discussed
> previously (the thread of <ijo6qc$kql$(E-Mail Removed)>),
> this behavior does not seem to be guaranteed by the standard.


It is not.
--
James Kuyper
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      11-14-2011
On 11/15/11 08:10 AM, William Ahern wrote:
> Ian Collins<(E-Mail Removed)> wrote:
>> On 11/11/11 09:21 AM, Quentin Pope wrote:

> <snip>
>>> pthread_create(&tid, NULL, readit, (void *)(long)connfd)
>>>
>>> I need to pass the file descriptor as a void * for pthread_create. But
>>> I need the file descriptor as an integer to read and write to it. Is the
>>> above the best approach to turn off the warning?

>
>> No. just pass the address of the descriptor.

>
> Why do people keep suggesting this?


If OP had, this thread would never have been born.

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

--
Ian Collins
 
Reply With Quote
 
 
 
 
James Kuyper
Guest
Posts: n/a
 
      11-14-2011
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.
A relevant response would give reasons justifying your treatment of that
possibility as unimportant.


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-14-2011
"christian.bau" <(E-Mail Removed)> writes:
[...]
> Now an optimizing compiler could easily conclude that producing a data
> pointer value that is not a null pointer or a pointer to an object or
> past the last byte of an object is always undefined behavior, and on
> MacOS X 64 bit and probably on other 64 bit systems casting an int to
> a pointer will _always_ invoke undefined behavior unless the int has a
> value of 0, and that therefore the result is always a null pointer.
> gcc tends to do that kind of optimizations and break "widely portable"
> undefined behavior.


This:

void *ptr = 0;

is guaranteed to set ptr to a null pointer value, because the constant
0 is a null pointer constant. This:

int var = 0;
void *ptr = (int*)var;

is not (though it's likely to do so under most implementations).

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-14-2011
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
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      11-14-2011
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.

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-14-2011
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
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-14-2011
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.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      11-14-2011
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
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      11-14-2011
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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Typecasting pointers Nishu C Programming 26 01-30-2007 02:33 PM
Typecasting Pointers on a 64 bit System bwaichu@yahoo.com C Programming 12 08-08-2006 09:44 PM
typecasting of function pointers srinivas.satish@gmail.com C Programming 12 03-21-2006 05:33 PM
Typecasting function pointers to void * bnoordhuis@gmail.com C Programming 3 07-15-2005 07:13 AM
Typecasting Pointers brian C Programming 13 11-29-2004 03:45 PM



Advertisments