Re: 4.3.902 bug report
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 SCO if needed. I can do that but there's not much prior art of using u_int32_t either. In fact, just one file: loader/xf86sym.c, and a few header files, most of which seem BSD related. And equally small number use uint32_t. I didnt run into problems before your checking at revision 3.18. Perhaps the best way to avoid this is to use neither ... simply use unsigned int? Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
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 using the CARD{8,16,32} and INT{8,16,32} types,
and also provide CARD64 and INT64 on more platforms than we currently
do.
Using either CARD32 or INT32 give 4 extra warnings (I know they're
completely benign but still, I dont like warnings) whereas using
unsigned int doesn't. There may be 64-bit issues with unsigned int, so I
dont know how safe that would be either.
Definitely something to follow up soon after the 4.4.0 release.
I agree. Making X more type-consistent would be a Good Thing, even
though its likely to be pretty invasive.
Kean
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
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 should be reverted and changed to something that will define u_int32_t on SCO if needed. I can do that but there's not much prior art of using u_int32_t either. In fact, just one file: loader/xf86sym.c, and a few header files, most of which seem BSD related. And equally small number use uint32_t. I didnt run into problems before your checking at revision 3.18. Perhaps the best way to avoid this is to use neither ... simply use unsigned int? We settled down for using CARD32 for now. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
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 generates 4 extra warnings whereas unsigned int doesn't. But I'm not emotionally attached to either solution :) Kean ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
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 prototyped to take unsigned int's. CARD32 will work too but it generates 4 extra warnings whereas unsigned int doesn't. But I'm not emotionally attached to either solution :) ints can be 64 bit long on some weird machines (CRay I think was one of them). Here the lenght of the type matters, so better don't loose this information. Which compiler are you using ? CARD32 is typedef'd to an unsigned int. And none of the compilers I use is generating a warning for such casts. But well the pmd5* functions can have their prototypes fixed. These are all static functions local to this file. Matthieu ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.902 bug report
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 type. A CARD32 * is not the same as an unisgned int *, even though CARD32 is typedef'ed to an unsigned int. The typedef introduces a new type and it is pedantically different. pedantic Typedefs are generally considered not to introduce new types in C. Likely the compiler is warning because CARD32 is typedef'ed to unsigned long not unsigned int on your system. (long and int *are* distinct, even when they have the same width.) /pedantic Owen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Select returned 0
Hi I'm here to report a problem i have with XFree 2.4.23 I've setted up a box with X and some WM and all was ok. When i unplugged my mouse from the machine i noticed a slowdown in X loading time. The logcreatedina -verbose 10 mode was only reporting a lot of: select returned 0select returned 0select returned 0 and so on. now, is possibile to modify this log-routine to report the problem in a "standard" log too? And is possible to have a write like: Warning: mouse not found instead of the "select returned 0"? Thanxa lot Tomcat
for 1 $ you will get access to horny housewives.Can you spare it?
Lusty Lady Wants Fun On The Side! ( Active during the last 24 hours ) Name: Sylvania_6969 Location: Missouri Age: 38 Marital Status: married Body Type: Athletic Height: 5' 8 Caucasian (white) Living Situation: husband works away on weekends Have Kids: No Interests: Arts, Dancing, Dining, Family, Movies, Listening to Music, Travel if you don't like this one click below there are more ladies waiting! http://www.oilupherbutthole.com/ocw/100265.html no more next time http://www.oilupherbutthole.com/rsp.php yyifmpxu t ko
4.3.99.902
Just upgraded this laptop from 4.3.0 (plus a couple of patches) to 4.3.99.902. ddc partially works again -- it hadn't at all in 4.3.0. At startup the server can get the details of the lcd, but ddc2xdccc fails to work: the XFree86_DDC_EDID1_RAWDATA prop is not gettting set. My logo key no longer works as expected in icewm; xev shows that it is Super_L, but icewm ignores it. I tried adding altwin:super_win to my setxkbmap options, but that didn't work. Even when I used xmodmap to remove hyper from mod4 emacs still showed both hyper and super modifiers when I tried it show key command. Any thoughts on these issues? -JimC ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
problem using dead keys
Hi, i´m from mexico, I´ve just installed xfree version 4.4.0 rc1 everything was ok, except that it appears to be ignoring the Option XkbOptions grp:lwin_switch which I used to use in 4.3 version for switching betwen US and US_INTL groups layouts, i´ve appended the current config, which was autogenerated using XFree86 -configure (and edited to use deadkeys) and the old XF86Config, none of boths could use last mentioned option. well, however, the work you do with 4.4 its very nice, i´m using Sis 630, with the driver DRM, and it appears to e a little faster than in 4.3, congratulations, feel free to ask any information you could need. Carlos Morales Computer Systems Eng. XF86Config.old Description: Binary data XF86Config.new Description: Binary data
