On 10/05/2009 10:08 PM, Eric Anholt wrote:
> On Mon, 2009-10-05 at 15:35 -0400, Adam Jackson wrote:
>
>> On Sun, 2009-10-04 at 12:08 +1100, Daniel Stone wrote:
>>
>>> On Fri, Oct 02, 2009 at 01:42:50PM -0700, Jamey Sharp wrote:
>>>
On 64-bit systems, int and pointers don't have
Excerpts from Eamon Walsh's message of Thu Oct 22 12:56:46 +0900 2009:
> I have a patch sitting around that does this, guess I'll float it.
yeah, I can't quite see how we can take this as-is given the Xlib
typedef horror show -- XID in Xlib is defined as unsigned long, and so
the whole Xlib API i
On Thu, Oct 22, 2009 at 04:06:34PM +0900, Keith Packard wrote:
> Excerpts from Eamon Walsh's message of Thu Oct 22 12:56:46 +0900 2009:
> > I have a patch sitting around that does this, guess I'll float it.
>
> yeah, I can't quite see how we can take this as-is given the Xlib
> typedef horror show
Excerpts from Daniel Stone's message of Thu Oct 22 18:23:42 +0900 2009:
> Right. Why don't we just ditch CARD32 and move to the native inttypes.h
> types everywhere but Xlib?
Do you want to do this for all XID types? Also, I assume you're
proposing that we drop Cray support from the protocol hea
On Thu, Oct 22, 2009 at 06:49:26PM +0900, Keith Packard wrote:
> Excerpts from Daniel Stone's message of Thu Oct 22 18:23:42 +0900 2009:
>
> > Right. Why don't we just ditch CARD32 and move to the native inttypes.h
> > types everywhere but Xlib?
>
> Do you want to do this for all XID types? Also
Hi,
On Thu, Oct 22, 2009 at 06:49:26PM +0900, Keith Packard wrote:
> Excerpts from Daniel Stone's message of Thu Oct 22 18:23:42 +0900 2009:
> > Right. Why don't we just ditch CARD32 and move to the native inttypes.h
> > types everywhere but Xlib?
>
> Do you want to do this for all XID types? Al
On Thu, 2009-10-22 at 18:49 +0900, Keith Packard wrote:
> Excerpts from Daniel Stone's message of Thu Oct 22 18:23:42 +0900 2009:
>
> > Right. Why don't we just ditch CARD32 and move to the native inttypes.h
> > types everywhere but Xlib?
>
> Do you want to do this for all XID types? Also, I ass
Excerpts from Daniel Stone's message of Thu Oct 22 20:55:57 +0900 2009:
> I mean just for CARDxx and INTxx, i.e. they really only have the number
> of bits implied by the type. XID/Atom/etc, where they're just used as
> unsigned long, will have to stay that way. Shrug.
Yeah, the CARD/INT stuff
Keith Packard writes:
> Excerpts from Eamon Walsh's message of Thu Oct 22 12:56:46 +0900 2009:
>
> > I have a patch sitting around that does this, guess I'll float it.
>
> yeah, I can't quite see how we can take this as-is given the Xlib
> typedef horror show -- XID in Xlib is defined as unsign
On Thu, Oct 22, 2009 at 11:20:35PM +0900, Keith Packard wrote:
> Excerpts from Daniel Stone's message of Thu Oct 22 20:55:57 +0900 2009:
> > I mean just for CARDxx and INTxx, i.e. they really only have the number
> > of bits implied by the type. XID/Atom/etc, where they're just used as
> > unsigne
> Date: Wed, 21 Oct 2009 23:56:46 -0400
> From: Eamon Walsh
>
> >> I would love love love to see us move entirely to stdint types instead
> >> of the mess we've got now.
> >>
> > Yes. Yes yes yes.
> >
>
> I have a patch sitting around that does this, guess I'll float it.
Hmm, isn't thi
Excerpts from Mark Kettenis's message of Tue Oct 27 08:39:40 -0700 2009:
> typedef unsigned long XID;
>
> into what's effectively
>
> typedef uint32_t XID;
The goal is to fix this everywhere *except* the Xlib API, which is
where the whole unsigned long disaster appears. Everywhere else uses
Mark Kettenis wrote:
>> Date: Wed, 21 Oct 2009 23:56:46 -0400
>> From: Eamon Walsh
>>
I would love love love to see us move entirely to stdint types instead
of the mess we've got now.
>>> Yes. Yes yes yes.
>> I have a patch sitting around that does this, guess I'll float it.
>
> Hmm, isn
13 matches
Mail list logo
