Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 9 Jan 2002 19:21:45 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Daniel Eischen <eischen@pcnet1.pcnet.com>
Cc:        John Baldwin <jhb@FreeBSD.ORG>, Dan Eischen <eischen@vigrid.com>, <arch@FreeBSD.ORG>, Doug Rabson <dfr@nlsystems.com>
Subject:   Re: Getcontext resolution?
Message-ID:  <20020109190544.O7640-100000@gamplex.bde.org>
In-Reply-To: <Pine.SUN.3.91.1020108193344.27477A-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Jan 2002, Daniel Eischen wrote:

> On Tue, 8 Jan 2002, John Baldwin wrote:
> > On 08-Jan-02 Dan Eischen wrote:
> > > Doug Rabson wrote:
> > >> I've been thinking about this and I think that possibly 'intptr_t' would
> > >> be a better type for the arguments than 'uintptr_t' since that is a signed
> > >> type.

Do you need a signed type for the args?  'intptr_t' is a strange type for
representing pointers because it is a signed type, but operations on pointers
act more like operations on unsigned types than signed ones.

> > > OK, will change it.  This is really only applicable to alpha and
> > > other 64-bit archs, though.  I've left i386 as int's since we know
> > > it's always going to be 32-bits, right?
> >
> > intptr_t is 32-bits on i386.  It's easier to just use the same type everywhere.
> > Also, you could consider the new C99 type intmax_t.
>
> intmax_t is 64 bits on i386 so it won't work.  I'm using intptr_t
> for both i386 and alpha now.
>
> Trying to use the correct type seems all well and good, but we
> are still somewhat limited to how the registers are defined in
> the machine context anyways (int for i386, and [unsigned] long
> for alpha).

Registers have type u_register_t on all machines.  There is also an
unnatural signed type register_t.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020109190544.O7640-100000>