[Linux-ia64] Re: Port of the posix timers to IA64

[Linux-ia64] Re: Port of the posix timers to IA64

[David Mosberger]

Hi Eric,

>>>>> On Fri, 28 Feb 2003 10:52:33 +0100, Eric Piel <Eric.Piel@Bull.Net> said:

  Eric> long v;
  Eric> :
  Eric> :
  Eric> if ( v >= (1 << 56)){
  Eric> :
  Eric> }

  Eric> It seems very strange for me that when compiling this part gcc
  Eric> considers that eveything must be converted to int. I have to
  Eric> write 1UL instead of 1 in order to obtain the correct
  Eric> behaviour of the code. I guess you've already come along with
  Eric> such problem.

As Andreas pointed out, that's just how C works.

  Eric> So, first, do you think it's a bug in gcc?

No, gcc is doing the Right Thing.

  Eric> Second should I convert every 1's I see by 1UL's (there are
  Eric> only few but sounds so strange)?

Yes, you need to make sure that anything that gets shifted more than
32 bits has the proper type.  In portable code, I sometimes prefer
to use explicit type-casts, e.g.:

	((size_t) 1) << 48

if the final value needs to be of type size_t, but that's largely
a matter of taste.

	--david

[Linux-ia64] Re: Port of the posix timers to IA64

[Eric Piel]

David Mosberger wrote:
> 
> Yes, you need to make sure that anything that gets shifted more than
> 32 bits has the proper type.  In portable code, I sometimes prefer
> to use explicit type-casts, e.g.:
> 
>         ((size_t) 1) << 48
> 
> if the final value needs to be of type size_t, but that's largely
> a matter of taste.
> 
Thank you, the code now works.

However I still don't feel confortable with the port because I had to
change the size of timer_t from int to long. I did so just because the
posix timers functions are based on the longest integer available (using
BITS_PER_LONG).
But it's not so convenient because then the include files of the system
also have to be updated (include/bits/types.h). In addition 2^24 ids
available (when using 32 bits) are already a lot.

Do you think I should try to care about compatibility and change the
posix timers functions to work on ints or should I just use longs and
update the include files?

Eric

Re: [Linux-ia64] Re: Port of the posix timers to IA64

[David Mosberger]

>>>>> On Mon, 03 Mar 2003 15:12:43 +0100, Eric Piel <Eric.Piel@Bull.Net> said:

  Eric> However I still don't feel confortable with the port because I
  Eric> had to change the size of timer_t from int to long. I did so
  Eric> just because the posix timers functions are based on the
  Eric> longest integer available (using BITS_PER_LONG).  But it's not
  Eric> so convenient because then the include files of the system
  Eric> also have to be updated (include/bits/types.h). In addition
  Eric> 2^24 ids available (when using 32 bits) are already a lot.

  Eric> Do you think I should try to care about compatibility and
  Eric> change the posix timers functions to work on ints or should I
  Eric> just use longs and update the include files?

I'd recommend to take this up with the glibc maintainers.  As far as I
know, the Linux kernel doesn't define timer_t anywhere at this point.
I didn't see Single UNIX Spec saying anything about the size of
timer_t, but then again, I didn't look very hard.

	--david

Re: [Linux-ia64] Re: Port of the posix timers to IA64

[Jes Sorensen]

>>>>> "Eric" = Eric Piel <Eric.Piel@Bull.Net> writes:

Eric> However I still don't feel confortable with the port because I
Eric> had to change the size of timer_t from int to long. I did so
Eric> just because the posix timers functions are based on the longest
Eric> integer available (using BITS_PER_LONG).  But it's not so
Eric> convenient because then the include files of the system also
Eric> have to be updated (include/bits/types.h). In addition 2^24 ids
Eric> available (when using 32 bits) are already a lot.

Eric, I take it you are only talking about updating the ia64 code
needing to be changed?

If you want to change the API, then we should certainly care about
compatibility.

Cheers,
Jes