Unix Programming - Negative numbers for thread ID

Author

Negative numbers for thread ID - why ?

markryde@gmail.com

2007-01-17, 7:04 pm

Hello,

I am running FC6 machine (i386 based).
I am trying the follwing:

create a thread with pthread_create().
in the thread function, I have:
printf("tid in thread_func=%d\n",(int)pthread_self());

I get negative number for the thread id, for example:

tid in thread2_func=-1218974832

Why is it so ?
I saw in some places usage of this method (pthread_self()),but
it returned non negative numbers.

Any ideas?
Regards,
Mark

Spoon

2007-01-17, 7:04 pm

markryde wrote:

> I am running FC6 machine (i386 based).
> I am trying the follwing:
>
> create a thread with pthread_create().
> in the thread function, I have:
> printf("tid in thread_func=%d\n",(int)pthread_self());

pthread_self() returns a pthread_t
http://www.opengroup.org/onlinepubs...hread_self.html

On my platform pthread_t is an unsigned long int.

David T. Ashley

2007-01-17, 7:04 pm

<markryde@gmail.com> wrote in message
news:1169049535.558760.187050@51g2000cwl.googlegroups.com...
> Hello,
>
> I am running FC6 machine (i386 based).
> I am trying the follwing:
>
> create a thread with pthread_create().
> in the thread function, I have:
> printf("tid in thread_func=%d\n",(int)pthread_self());
>
> I get negative number for the thread id, for example:
>
> tid in thread2_func=-1218974832
>
> Why is it so ?
> I saw in some places usage of this method (pthread_self()),but
> it returned non negative numbers.
>
> Any ideas?

Surprisingly, somebody posted the exact same type of question on comp.lang.c
within the last 72 hours or so. I'll paste in the text of my reply below.

----BEGIN PASTED POST FROM COMP.LANG.C

"Nicholas Zhou" <zhou....@osu.edu> wrote in message

news:eok3ui$4hb$1@charm.magnus.acs.ohio-state.edu...

> Hi,

> I was writing a testing program to test the ranges of char, short, int and
> long variables on my computer, both signed and unsigned.

> Everything was fine except for unsigned int and unsigned long. I got
> 0 to -1 for both. The expected answers should be:

> unsigned int: 0 to 65535
> unsigned long: 0 to 4294967295

> What might be wrong here? Please help.

Assuming a standard 2's complement machine (just about all of them nowadays,
I think), the reason you got -1 is that the bit pattern of all 1's in an
integer data type corresponds to:

a)The largest possible positive value, if the data is interpreted as an
unsigned type.

b)-1, if the value is interpreted as a signed type.

As other posters pointed out, the problem was the format specifier. The
format specifier caused interpretation as a signed type.

An integer in memory is just a collection of 0's and 1's. It can be either
unsigned or signed. It is all in how you interpret it.

2's complement has historically been used in computers because the same
addition and subtraction instructions give correct results for both unsigned
and signed interpretations. However, a little extra digital logic and a
couple of extra flags are required in the processor for correct branches and
so on.

The smallest practical example is 3 bits. Here are the values when
interpreted as unsigned and signed.

Bit Pattern Unsigned Signed

000 0 0
001 1 1
010 2 2
011 3 3
100 4 -4
101 5 -3
110 6 -2
111 7 -1

Notice that if N is the number of bits, the largest value corresponds to
2^N-1 as an unsigned or -1 as a signed.

This is all explained (I hope) here:

http://en.wikipedia.org/wiki/Twos_complement

One other thing you might notice is that the representations correspond to
the same values up until the sign bit is set. It is a not-uncommon problem
in 'C' to introduce a bug that only becomes apparent at large data values
because one somehow casts an unsigned to a signed. Everything works great.
Until 2^(N-1). Then all hell breaks loose.

-----END PASTED POST

--
David T. Ashley (dta@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

Sponsored Links