Subj : Re: returning arguments
To   : comp.programming.threads
From : David Butenhof
Date : Fri Jul 01 2005 02:14 pm

Sergey P. Derevyago wrote:
> David Butenhof wrote:
> 
>>To (perhaps) make this more clear... technically, there's exactly ONE
>>return value from a thread. But the TYPE of that value is "void*"
>>(pointer). You can carry any pointer type in that "void* container". On
>>most contemporary mainstream systems you can get away with carrying any
>>scalar type x with sizeof(x) <= sizeof(void*).
> 
> 	IMHO it should be explicitly noted that passing arbitrary scalar values as
> pointer values is not standard conforming:
> 
> 3.7.3.2p4 of ISO/IEC 14882:2003(E)
> The effect of using an invalid pointer value ... is undefined (On some
> implementations, it causes a system-generated runtime fault).

I usually take care to point out that the semantics of casting between 
integer and pointer types itself is not completely defined by the 
standard. The clause you point out is also valid, but generally of less 
concern because it applies only if you dereference the "not really a 
pointer" value. It's quite possible to use (void*) as a "universal type" 
carrier without ever dereferencing it. (In fact you can't dereference a 
"void*" pointer anyway; that'll fail at compile time.)

While I alluded to that restriction in this thread, I wasn't as explicit 
about it as usual; nevertheless I do agree that it's always a good idea 
to increase awareness.

HOWEVER, this stuff is safe on any mainstream C/UNIX class of system 
because it's always been presumed to be safe by a vast body of extant 
code -- breaking that would be severely limiting no matter how legal it 
is. "Real" UNIX/C systems are byte-addressed, and addresses are nothing 
more than a byte index. The problems come with WORD addressed machines 
(like Crays) that support a field-reference address format, meaning 
addresses are no longer simply byte indices; and changing pointer types 
(much less changing integer values to pointers) might involve changes to 
the data. (These are perfectly valid C systems, and can be "UNIX-like", 
but will never be widely perceived as "real UNIX" because of those 
portability restrictions on classic and common programming practice.) 
(One final disclaimer ;-) : I say "real" in quotes because neither POSIX 
nor SUS makes any attempt, nor has any intent, to overrule the 
allowances of ANSI C in this regard. But I'm not talking about 
legalities, just deeply ingrained cultural expectations. ;-) )

-- 
Dave Butenhof, David.Butenhof@hp.com
HP Utility Pricing software, POSIX thread consultant
Manageability Solutions Lab (MSL), Hewlett-Packard Company
110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062

.