On Sun, 2003-12-21 at 08:04, Kean Johnston wrote:
> > Which compiler are you using ? CARD32 is typedef'd to an unsigned
> gcc 2.95.3.
>
> The warning is not wrong though. It simply warns that we are passing
> argument 1 to function pmd5_hash() and add_entropy() from an
> incompatible pointer typ
Which compiler are you using ? CARD32 is typedef'd to an unsigned
gcc 2.95.3.
The warning is not wrong though. It simply warns that we are passing
argument 1 to function pmd5_hash() and add_entropy() from an
incompatible pointer type. A CARD32 * is not the same as an unisgned int
*, even though
Kean Johnston wrote (in a message from Sunday 21)
> > We settled down for using CARD32 for now.
> Mmmm ok. I just finished taking a closer look at where the variable was
> being used and it is more appropriate to use unsigned int. The two
> functions that it is calling above are both prototy
We settled down for using CARD32 for now.
Mmmm ok. I just finished taking a closer look at where the variable was
being used and it is more appropriate to use unsigned int. The two
functions that it is calling above are both prototyped to take unsigned
int's. CARD32 will work too but it generat
Kean Johnston wrote (in a message from Sunday 21)
> > I think you're right here. Since we can't assume that every platform
> > on which XFree86 is built has C99 types and that there's no previous
> > art of using uint32_t instead of the older u_int32_t in the XFree86
> > tree, the SCO diff shou
We use them in lots of places that require known size data types. If
the C99 types had been globally available say 10 years earlier, this
likely wouldn't have been the case. As it is now, we either need to
find a mechanism for providing the C99 types on platforms that don't
have them, or continue
I think you're right here. Since we can't assume that every platform
on which XFree86 is built has C99 types and that there's no previous
art of using uint32_t instead of the older u_int32_t in the XFree86
tree, the SCO diff should be reverted and changed to something that
will define u_int32_t on
On Sat, 20 Dec 2003, Warren Turkal wrote:
> David Dawes wrote:
> > We use them in lots of places that require known size data types. If
> > the C99 types had been globally available say 10 years earlier, this
> > likely wouldn't have been the case. As it is now, we either need to
> > find a mec
David Dawes wrote:
> We use them in lots of places that require known size data types. If
> the C99 types had been globally available say 10 years earlier, this
> likely wouldn't have been the case. As it is now, we either need to
> find a mechanism for providing the C99 types on platforms that
On Sat, Dec 20, 2003 at 07:14:36PM +0100, Matthieu Herrb wrote:
>I wrote (in a message from Saturday 20)
> > Warren Turkal wrote (in a message from Saturday 20)
> > > The uint32_t in xc/programs/xdm/genauth.c doesn't compile on my computer. It
> > > appears that stdint.h needs to be included some
I wrote (in a message from Saturday 20)
> Warren Turkal wrote (in a message from Saturday 20)
> > The uint32_t in xc/programs/xdm/genauth.c doesn't compile on my computer. It
> > appears that stdint.h needs to be included somewhere (most likely Xos.h),
> > but it is not. It appears that uint
Warren Turkal wrote (in a message from Saturday 20)
> The uint32_t in xc/programs/xdm/genauth.c doesn't compile on my computer. It
> appears that stdint.h needs to be included somewhere (most likely Xos.h),
> but it is not. It appears that uint32_t was changed from u_int32_t in some
> SCO fixes
The uint32_t in xc/programs/xdm/genauth.c doesn't compile on my computer. It
appears that stdint.h needs to be included somewhere (most likely Xos.h),
but it is not. It appears that uint32_t was changed from u_int32_t in some
SCO fixes. I have included output from trying to compile below.
wt
gcc
13 matches
Mail list logo
