On Wednesday 25 May 2005 23:14, Jerry Feldman wrote:

That is because you have a bug in your program.

That's not the only bug, it's not nice to cast an integer to (void *). It invokes unspecified behaviour, I'm pretty sure

On Thursday 26 May 2005 00:07, Jon Nelson wrote:

That's not a bug.

Yes it is

Perhaps it's not the best style (and in this particular case, even that is debatable), but there's nothing technically wrong with it.

Yes there is

A void * must be able to hold the largest pointer value, and since you can't pass anything larger than a single pointer value in C, it's not a problem.

First of all, what do you mean by this? You can pass entire structs by value in C. It's perhaps not advisable from a performance point of view, but that's another issue. Secondly, there is nothing to guarantee that a pointer is stored in any form suitable to hold an integer. There are platforms where pointers are complex structures not at all suitable for storing integers. It is also possible that a pointer is 32 bit while an integer is 64 bit. The only thing guaranteed by the standard is that short <= int <= long and that a char is 8 bits. Nothing else regarding size is guaranteed, certainly not an equality between sizeof(int) and sizeof(void *) On x86 platforms and some others, you are usually lucky when you do this, because a pointer happens to be an integer there. But it is not guaranteed by the standard. A compiler would be free to do whatever it pleases after such a case. It is known as undefined behaviour and it is most definitely a bug, even though it may work on a few popular platforms

Technically, he *could* pass the /value/ of the /address/ of t,

commonly known as a pointer, yes, you can cast (int *) to (void *)

On Thu, 26 May 2005 00:28:17 +0200 Anders Johansson wrote:

First of all, what do you mean by this? You can pass entire structs by value in C. It's perhaps not advisable from a performance point of view, but that's another issue.

Secondly, there is nothing to guarantee that a pointer is stored in any form suitable to hold an integer. There are platforms where pointers are complex structures not at all suitable for storing integers. It is also possible that a pointer is 32 bit while an integer is 64 bit. The only thing guaranteed by the standard is that

short <= int <= long

and that a char is 8 bits. Nothing else regarding size is guaranteed, certainly not an equality between sizeof(int) and sizeof(void *) The C standard does NOT say that a char is 8 bits. It says that it must be at least 8 bits.

On x86 platforms and some others, you are usually lucky when you do this, because a pointer happens to be an integer there. But it is not guaranteed by the standard. A compiler would be free to do whatever it pleases after such a case. It is known as undefined behaviour and it is most definitely a bug, even though it may work on a few popular platforms

As I mentioned, it happens to be a common practice in pthread programming to pass an int directly into the thread entry. The prototype for a pthread start routine is: void *functionname(void *); The C language does permit the assignment of an integral to a pointer and vice-versa, but truncation and/or unexpected sign extension can occur. Theoretically you are correct that a pointer on a specific system could be 32-bits and an int could be 64-bits and a long 128- bits. There are no systems I know of where a pointer is smaller than a long. (I suppose mixed model programming an an old 8086 class could have a 16 bit pointer and a 32-bit int, but Linux does not run on that). -- Jerry Feldman Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9

On Wednesday 25 May 2005 8:57 pm, Anders Johansson wrote:

Well, as I mentioned, it is implementation defined. Which means you are creating a program that is not guaranteed to be portable to other compilers. The C standard itself does not define the width of a pointer type, but there is a set of conventions that all Linux and Unix systems use: ILP32 is used on 32-bit systems that define the type int, long, and pointer to be 32 bits. On 64-bit systems, there is LP64. In this case, int is 32-bits, where both long and pointers are 64-bits. Note that Windows-64 uses LLP64 where ints and longs are 32-bits and pointers and long longs are 64 bits.

But, as you very correctly mentioned, assignment of an integral to a pointer and vice-versa is not a good programming practice. In the posted thread example, there are 3 problems: 1. The premature exit of the main thread which causes an erroneous result on Linux 2.6 kernel. 2. The passing of an int into the thread argument. This is simply a non-portable and bad practice. 3. The use of the argument within the thread uncasted in the printf. This may cause erroneous results on a big-endian system because the %d printf specification will take the first 32-bits. So, on a Solaris or HP-UX 64-bit system, the thread number will print as 0 in this particular case. void *PrintHello(void *threadid) : printf("\n%d: Hello World!\n", threadid); This should be: printf("\n%d: Hello World!\n", (int)threadid); ---------------------- A better solution might be to pass the argument in as a pointer to a struct: /****************************************************************************** * FILE: hello.c * DESCRIPTION: * A "hello world" Pthreads program. Demonstrates thread creation and * termination. * AUTHOR: Blaise Barney * LAST REVISED: 04/05/05 ******************************************************************************/ #include #include #include #define NUM_THREADS 5 typedef struct thd { pthread_t tid; int thread_number; int rv; } THD_T; void *PrintHello(void *threadid) { int i = 0; THD_T *mytid = threadid; /* to avoid an ugly cast */ while (i < 10) { printf("\n%d: Hello World!\n", mytid->thread_number); i ++; } mytid->rv = 0; pthread_exit(threadid); } int main(int argc, char *argv[]) { THD_T threads[NUM_THREADS]; int rc, t; for(t=0;t Partner Technology Access Center (contractor) (PTAC-MA) Hewlett-Packard Co. 550 King Street LKG2a-X2 Littleton, Ma. 01460 (978)506-5243