Re: posting advertisements
On 5/10/07, Lei Zhang [EMAIL PROTECTED] wrote: On 5/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! How much time it needs to be asked so that you stopped posting advertisements? If you are participating on a developers list behave accordingly. It's a gmail account. Does gmail automatically append advertisements? As far as I know, gmail does not. No, Gmail does not append advertisements(as can be seen by the lack of advertisments on this message.)
Re: [PATCH 2/3] winex11: Implement TINN algorithm. (try 3)
An int value can be more precise then a float can, however a float can hold bigger numbers. It's the difference between having a 24 bit fraction with 8 bits of exponent and 1 of sign vs 31/32 bits of fraction data without exponent. Plus, integer operations are faster then floating point operations, even if just margionably. On 5/9/07, Vitaly Budovski [EMAIL PROTECTED] wrote: Dmitry Timoshkov wrote: Vitaly Budovski [EMAIL PROTECTED] wrote: Please show me how an unsigned int can represent values greater than 2^32. This is why a float is used. Of course int can't, but neither float can. Perhaps you confuse it with double? I'm pretty sure I'm not confusing it with double. http://steve.hollasch.net/cgindex/coding/ieeefloat.html http://en.wikipedia.org/wiki/IEEE_754#Single-precision_32_bit
Question about OpenAL
Is there any interest in adding OpenAL to Wine? I would imagine it's relatively simple to implement the OpenAL dll that would be a simple wrap around the Linux OpenAL library assuming they have the same functionality(from what I know of OpenAL, they should). It's not a very common library, but if we could implement it on top of the local implementation, that would mean that programs that use it would be using local devices without having to go through the DirectSound library. I'm not talking about using OpenAL as an audio driver, but an implementation of the OpenAL library for Wine that would use the local version of OpenAL. I tried looking around, and the only thing I found was talk about the OpenAL driver, and also brief requests for an OpenAL dll, but I didn't see anything official. Any thoughts on if this is something that would be beneficial to add?
const cleanup round 1(commentary on what I found)
Some of this was included in the patch submission. Some of it I had questions about. spawn.c : warnings may or may not be harmless depending on if esecvp attempts to modify the results. Specs indicate it doesn't, but the function typing doesn't indicate so(the difference is 'const char * const argv[]' and 'char *const argv[]') libs/wine/string.c: strstrW - returns the location where sub was found in str. I believe returning a non-const value is what is expected. Should this be changed to a non-const parameter, or just leave the warning as is? tools/winedump/pdb.c: pdb_exit [line 149,153,155] - freeing of const variable. Is this ok? I could imagine it *could* cause problems if what we are freeing isn't in readable/writeable memory. pdb_dump_symbols [line 293,403,409] - same as pdb_exit. pdb_dump_types [line 462] - ditto pdb_jg_dump line[514] - ditto pdb_ds_dump line[643] - ditto tools/winedump/search.c: get_type [line 305, 329] - freeing of const variable again. [line 314, 335] - both cases, set return_text to type_str. Either parsed_symbol's return_text needs to be constified, proto should be unconstified, or leave it in place as a necessary cast. Any comments on the above spots? what of these are necessary casts? what of these can/should be corrected, and what needs to be done to correct them? **patches submitted to wine-patches** the following were straight forward patches that shouldn't modify the flow of the program beyond fixing the warnings. libs/wine/string.c: strtolW and strtoulW - constify the endptr value. This is just an output value to indicate where in the array we stoped processing. Change causes this to be the same type as the first value. Reduces number of cast-qual warnings by 6. tools/winedump/lnk.c: dump_pidl [line 176] - switched to const. Value is never modified in the function. Removes a cast-qual warning. tools/winedump/symbol.c: symbol_clean_string - this function is modifying the string. This should most definitely *not* be a const parameter. It's not even logically const(as a comment tried to claim) as the the intent of the function is to make the type string Wine-friendly. That requires modifications to that string, and to the variable. Removes a cast-qual warning. Comments? questions? Current number of cast-qual warnings fixed: 8. Number deemed necessary: 0(you guys need to help me decide what of these need to remain) Number looked at: 24. Estimated number remaining: 521.
Re: const cleanup round 1
after some extra testing I found that it's not that my modification would forbid that, but it would complain about the second parameter not being const(which I thought that the compiler would be fine with auto promoting the WCHAR ** to const WCHAR **). Fair enoug then. Strike those modifications. Should I resubmit without those? or should I put that off until I get a second round ready? On 3/13/07, Eric Pouech [EMAIL PROTECTED] wrote: Mike Schaadt a écrit : string.c: strtolW and strtoulW - constify the endptr value. This is just an output value to indicate where in the array we stoped processing. Change causes this to be the same type as the first value. Reduces number of cast-qual warnings by 6. lnk.c: dump_pidl [line 176] - switched to const. Value is never modified in the function. Removes a cast-qual warning. symbol.c: symbol_clean_string - this function is modifying the string. This should most definitly *not* be a const parameter. It's not even logically const as the the intent of the function is to make the type string Wine-friendly. That requires modifications to that string. diff --git a/include/wine/unicode.h b/include/wine/unicode.h index 83a7d52..4e2caa5 100644 --- a/include/wine/unicode.h +++ b/include/wine/unicode.h @@ -96,8 +96,8 @@ extern int strcmpiW( const WCHAR *str1, extern int strncmpiW( const WCHAR *str1, const WCHAR *str2, int n ); extern int memicmpW( const WCHAR *str1, const WCHAR *str2, int n ); extern WCHAR *strstrW( const WCHAR *str, const WCHAR *sub ); -extern long int strtolW( const WCHAR *nptr, WCHAR **endptr, int base ); -extern unsigned long int strtoulW( const WCHAR *nptr, WCHAR **endptr, int base ); +extern long int strtolW( const WCHAR *nptr, const WCHAR **endptr, int base ); +extern unsigned long int strtoulW( const WCHAR *nptr, const WCHAR **endptr, int base ); this is wrong as you want to be able to write code as: WCHAR* str; WCHAR* p; int val = strtolW(str, p, 10); *p = '\0'; which your modification forbids (ANSI strtol doesn't have the const modifier for endptr) the rest of the patch looks ok -- Eric Pouech The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot. (Douglas Adams)
Question about OpenGL/D3D
Has anyone tested using standard window objects in a window that also had an opengl/d3d context? I believe Terragen 2 is attempting to do this. If this hasn't been tested, than it might be the cause of all of the static that appears non opengl area, making the program nearly unusable. No messages get printed to the console from wine(Terragen 2 prints out a fair bit of debug info there, but nothing from wine that would cause the problem, just a few warnings that shouldn't be related). Any thoughts?
-Wcast-qual result
I submited a patch today that modified unicode.h that disables warnings(which allows for -Wcast-qual to actually give relevant results) I don't know if it will be accepted or not(it has the potential of being problematic if modifying unicode.h that would normally result in a warning, but this patch would cause it to be suppresed), but I figured I would at least share the results I found. after configuring with cast-qual, I stored the warnings that resulted(which I've included as an attachment for those that are interested.). There were no warnings in the make depend, and make generated 545 warnings(all from .c files). The included file does not contain the sub directory for what file generates the warning. If anyone knows how to pull that data, let me know and I'll redo it and extract that information as well. I plan on start looking through these and working on fixing some here soon, but I thought I would share what I found with this group in general. cast-qual.result Description: Binary data
