February 2014 - Wine-Devel - list.winehq.org

Re: msi: Expand REG_EXPAND_SZ keys when resolving AppSearch entries (resend)

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5094 Your paranoid android. === w2000pro (32 bit package) === package.c:3945: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:3951: Test failed: Expected "C:\\FileName2", got "C:\FileName2" package.c:3957: Test failed: Expected "C:\\FileName3", got "C:\FileName3" package.c:3969: Test failed: Expected "C:\\FileName5", got "C:\FileName5" package.c:3975: Test failed: Expected "C:\\", got "C:\" package.c:3981: Test failed: Expected "C:\\", got "C:\" package.c:3997: Test failed: Expected "C:\\FileName8.dll", got "C:\FileName8.dll" package.c:4008: Test failed: Expected "C:\\FileName10.dll", got "C:\FileName10.dll" package.c:4467: Test failed: Expected ERROR_SUCCESS, got 1627 package.c:4559: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4570: Test failed: Expected "C:\\", got "C:\" package.c:4581: Test failed: Expected "C:\\", got "C:\" package.c:4631: Test failed: Expected "C:\\FileName3.dll", got "C:\FileName3.dll" package.c:4642: Test failed: Expected "C:\\FileName5.dll", got "C:\FileName5.dll" package.c:4657: Test failed: Expected "C:\\", got "C:\" package.c:4662: Test failed: Expected "", got "C:\" package.c:4678: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4687: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4937: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:4948: Test failed: Expected "C:\\", got "C:\" package.c:4954: Test failed: Expected "C:\\", got "C:\" package.c:4975: Test failed: Expected "C:\\FileName2.dll", got "C:\FileName2.dll" package.c:4986: Test failed: Expected "C:\\FileName4.dll", got "C:\FileName4.dll" package.c:5226: Test failed: Expected "C:\\FileName1", got "C:\FileName1" package.c:5232: Test failed: Expected "C:\\", got "C:\" package.c:5249: Test failed: Expected "C:\\one\two\three\FileName2", got "C:\one\two\three\FileName2" package.c:5260: Test failed: Expected "C:\\one\two\three\FileName2", got "C:\one\two\three\FileName2" package.c:5268: Test failed: Expected "C:\\FileName3.dll", got "C:\FileName3.dll" package.c:5612: Test failed: Expected C:\\winetest-package.msi, got C:\winetest-package.msi package.c:6244: Test failed: Expected C:\\abelisaurus or empty string, got C:\abelisaurus package.c:6268: Test failed: Expected C:\\ or empty string, got C:\ package.c:6312: Test failed: Expected C:\\ or empty string, got C:\ package.c:6321: Test failed: Expected C:\\neosodon\ or empty string, got C:\neosodon\ package.c:6551: Test failed: Expected "C:\\", got "C:\" package.c:6552: Test failed: Expected 4, got 3 package.c:6559: Test failed: Expected "C:\\", got "C:\" package.c:6560: Test failed: Expected 4, got 3 package.c:6576: Test failed: Expected "C:\\", got "C:\" package.c:6577: Test failed: Expected 4, got 3 package.c:6583: Test failed: Expected "C:\\", got "C:\" package.c:6584: Test failed: Expected 4, got 3 package.c:6591: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6592: Test failed: Expected 14, got 13 package.c:6599: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6600: Test failed: Expected 19, got 18 package.c:6610: Test failed: Expected "C:\\", got "C:\" package.c:6611: Test failed: Expected 4, got 3 package.c:6618: Test failed: Expected "C:\\", got "C:\" package.c:6619: Test failed: Expected 4, got 3 package.c:6635: Test failed: Expected "C:\\", got "C:\" package.c:6636: Test failed: Expected 4, got 3 package.c:6642: Test failed: Expected "C:\\", got "C:\" package.c:6643: Test failed: Expected 4, got 3 package.c:6650: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6651: Test failed: Expected 14, got 13 package.c:6658: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6659: Test failed: Expected 19, got 18 package.c:6669: Test failed: Expected "C:\\", got "C:\" package.c:6670: Test failed: Expected 4, got 3 package.c:6677: Test failed: Expected "C:\\", got "C:\" package.c:6678: Test failed: Expected 4, got 3 package.c:6694: Test failed: Expected "C:\\", got "C:\" package.c:6695: Test failed: Expected 4, got 3 package.c:6701: Test failed: Expected "C:\\", got "C:\" package.c:6702: Test failed: Expected 4, got 3 package.c:6709: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6710: Test failed: Expected 14, got 13 package.c:6717: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6718: Test failed: Expected 19, got 18 package.c:6728: Test failed: Expected "C:\\", got "C:\" package.c:6729: Test failed: Expected 4, got 3 package.c:6736: Test failed: Expected "C:\\", got "C:\" package.c:6737: Test failed: Expected 4, got 3 package.c:6753: Test failed: Expected "C:\\", got "C:\" package.c:6754: Test failed: Expected 4, got 3 package.c:6760: Test failed: Expected "C:\\", got "C:\" package.c:6761: Test failed: Expected 4, got 3 package.c:6768: Test failed: Expected "C:\\subsource\", got "C:\subsource\" package.c:6769: Test failed: Expected 14, got 13 package.c:6776: Test failed: Expected "C:\\subsource\sub2\", got "C:\subsource\sub2\" package.c:6777: Test failed: Expected 19, got 18 package.c:6792: Test failed: Expected 4, got 3 package.c:6809: Test failed: Expected 4, got 3 package.c:6815: Test failed: Expected ERROR_MORE_DATA, got 0 package.c:6818: Test failed: Expected 4, got 3 package.c:6825: Test failed: Expected "C:\\", got "C:\" package.c:6826: Test failed: Expected 4, got 3 package.c:6837: Test failed: Expected "C:\\", got "C:\" package.c:6838: Test failed: Expected 4, got 3 package.c:6933: Test failed: Expected "C:\\", got "C:\" package.c:6934: Test failed: Expected 4, got 3 package.c:6941: Test failed: Expected "C:\\", got "C:\" package.c:6942: Test failed: Expected 4, got 3 package.c:6951: Test failed: Expected "C:\\", got "C:\" package.c:6952: Test failed: Expected 4, got 3 package.c:6960: Test failed: Expected "C:\\", got "C:\" package.c:6961: Test failed: Expected 4, got 3 package.c:6967: Test failed: Expected "C:\\", got "C:\" package.c:6968: Test failed: Expected 4, got 3 package.c:6975: Test failed: Expected "C:\\", got "C:\" package.c:6976: Test failed: Expected 4, got 3 package.c:6983: Test failed: Expected "C:\\", got "C:\" package.c:6984: Test failed: Expected 4, got 3 package.c:6994: Test failed: Expected "C:\\", got "C:\" package.c:6995: Test failed: Expected 4, got 3 package.c:7002: Test failed: Expected "C:\\", got "C:\" package.c:7003: Test failed: Expected 4, got 3 package.c:7012: Test failed: Expected "C:\\", got "C:\" package.c:7013: Test failed: Expected 4, got 3 package.c:7021: Test failed: Expected "C:\\", got "C:\" package.c:7022: Test failed: Expected 4, got 3 package.c:7028: Test failed: Expected "C:\\", got "C:\" package.c:7029: Test failed: Expected 4, got 3 package.c:7036: Test failed: Expected "C:\\", got "C:\" package.c:7037: Test failed: Expected 4, got 3 package.c:7044: Test failed: Expected "C:\\", got "C:\" package.c:7045: Test failed: Expected 4, got 3 package.c:7055: Test failed: Expected "C:\\", got "C:\" package.c:7056: Test failed: Expected 4, got 3 package.c:7063: Test failed: Expected "C:\\", got "C:\" package.c:7064: Test failed: Expected 4, got 3 package.c:7073: Test failed: Expected "C:\\", got "C:\" package.c:7074: Test failed: Expected 4, got 3 package.c:7082: Test failed: Expected "C:\\", got "C:\" package.c:7083: Test failed: Expected 4, got 3 package.c:7089: Test failed: Expected "C:\\", got "C:\" package.c:7090: Test failed: Expected 4, got 3 package.c:7097: Test failed: Expected "C:\\", got "C:\" package.c:7098: Test failed: Expected 4, got 3 package.c:7105: Test failed: Expected "C:\\", got "C:\" package.c:7106: Test failed: Expected 4, got 3 package.c:7116: Test failed: Expected "C:\\", got "C:\" package.c:7117: Test failed: Expected 4, got 3 package.c:7124: Test failed: Expected "C:\\", got "C:\" package.c:7125: Test failed: Expected 4, got 3 package.c:7134: Test failed: Expected "C:\\", got "C:\" package.c:7135: Test failed: Expected 4, got 3 package.c:7143: Test failed: Expected "C:\\", got "C:\" package.c:7144: Test failed: Expected 4, got 3 package.c:7150: Test failed: Expected "C:\\", got "C:\" package.c:7151: Test failed: Expected 4, got 3 package.c:7158: Test failed: Expected "C:\\", got "C:\" package.c:7159: Test failed: Expected 4, got 3 package.c:7166: Test failed: Expected "C:\\", got "C:\" package.c:7167: Test failed: Expected 4, got 3 package.c:7264: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7265: Test failed: Expected 9, got 8 package.c:7274: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7275: Test failed: Expected 9, got 8 package.c:7284: Test failed: Expected "C:\\long\", got "C:\long\" package.c:7285: Test failed: Expected 9, got 8 package.c:7296: Test failed: Expected "C:\\two\", got "C:\two\" package.c:7297: Test failed: Expected 8, got 7 package.c:7308: Test failed: Expected "C:\\four\", got "C:\four\" package.c:7309: Test failed: Expected 9, got 8 package.c:7320: Test failed: Expected "C:\\six\", got "C:\six\" package.c:7321: Test failed: Expected 8, got 7 package.c:7332: Test failed: Expected "C:\\eight\", got "C:\eight\" package.c:7333: Test failed: Expected 10, got 9 package.c:7344: Test failed: Expected "C:\\ten\", got "C:\ten\" package.c:7345: Test failed: Expected 8, got 7 package.c:7356: Test failed: Expected "C:\\twelve\", got "C:\twelve\" package.c:7357: Test failed: Expected 11, got 10 package.c:7408: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7409: Test failed: Expected 10, got 9 package.c:7418: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7419: Test failed: Expected 10, got 9 package.c:7428: Test failed: Expected "C:\\short\", got "C:\short\" package.c:7429: Test failed: Expected 10, got 9 package.c:7440: Test failed: Expected "C:\\one\", got "C:\one\" package.c:7441: Test failed: Expected 8, got 7 package.c:7452: Test failed: Expected "C:\\three\", got "C:\three\" package.c:7453: Test failed: Expected 10, got 9 package.c:7464: Test failed: Expected "C:\\five\", got "C:\five\" package.c:7465: Test failed: Expected 9, got 8 package.c:7476: Test failed: Expected "C:\\seven\", got "C:\seven\" package.c:7477: Test failed: Expected 10, got 9 package.c:7488: Test failed: Expected "C:\\nine\", got "C:\nine\" package.c:7489: Test failed: Expected 9, got 8 package.c:7500: Test failed: Expected "C:\\eleven\", got "C:\eleven\" package.c:7501: Test failed: Expected 11, got 10 package.c:7637: Test failed: Expected "C:\\", got "C:\" package.c:7638: Test failed: Expected 4, got 3 package.c:7649: Test failed: Expected "C:\\", got "C:\" package.c:7650: Test failed: Expected 4, got 3 package.c:7657: Test failed: Expected "C:\\", got "C:\" package.c:7658: Test failed: Expected 4, got 3 package.c:7755: Test failed: Expected "C:\\", got "C:\" package.c:7756: Test failed: Expected 4, got 3 package.c:7763: Test failed: Expected "C:\\", got "C:\" package.c:7764: Test failed: Expected 4, got 3 package.c:7771: Test failed: Expected "C:\\", got "C:\" package.c:7772: Test failed: Expected 4, got 3 package.c:7791: Test failed: Expected "C:\\", got "C:\" package.c:7792: Test failed: Expected 4, got 3 package.c:7799: Test failed: Expected "C:\\", got "C:\" package.c:7800: Test failed: Expected 4, got 3 package.c:7819: Test failed: Expected "C:\\", got "C:\" package.c:7820: Test failed: Expected 4, got 3 package.c:7827: Test failed: Expected "C:\\", got "C:\" package.c:7828: Test failed: Expected 4, got 3 package.c:7847: Test failed: Expected "C:\\", got "C:\" package.c:7848: Test failed: Expected 4, got 3 package.c:7855: Test failed: Expected "C:\\", got "C:\" package.c:7856: Test failed: Expected 4, got 3

Feb. 23, 2014

Re: ff-core effect id handling in case of a failed effect upload

by Dmitry Torokhov

On Wed, Feb 19, 2014 at 11:14:18PM +0100, Elias Vanderstuyft wrote: > On Wed, Feb 19, 2014 at 10:05 PM, Dmitry Torokhov > <dmitry.torokhov(a)gmail.com> wrote: > > On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote: > >> (added Dmitry to CC) > >> > >> 19.02.2014 13:42, Elias Vanderstuyft kirjoitti: > >> > Hi, > >> > > >> > >> Hi, > >> > >> > In the process of reviewing the Wine DInput translation layer, I > >> > noticed an inconvenience (in the ff-core implementation?) that can > >> > possibly lead to confusing problems to application developers (not > >> > only for Wine), in short: > >> > If a new (id==-1) effect was uploaded (look at > >> > ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL), > >> > ff-core will have assigned a positive number to the effect id. This > >> > can be confusing because the dev->ff->effects[] array will not contain > >> > an element at the index of that new effect id. > >> > >> I agree that this is a bit confusing, and the kernel code should > >> probably be modified to not clobber the ioctl-provided effect on failure > >> (effect->id is set to an "undefined" value, i.e. next free effect slot). > >> > >> Dmitry, WDYT? > > > > Yeah, it looks like we need to change evdev.c to read: > > > > error = input_ff_upload(dev, &effect, file); > > if (error) > > return error; > > > > if (put_user(effect.id, &(((struct ff_effect __user *)p)->id))) > > return -EFAULT; > > > > return 0; > > Alright, who will create the patch? > Do I may / have to do it? If you could create the patch that would be appreciated. Thanks. -- Dmitry

Feb. 23, 2014

Re: Wine 64 bit

by Austin English

On Thu, Feb 20, 2014 at 12:44 PM, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2014-02-20 17:20, schrieb Ken Thomases: > > Besides running under an emulator, it may be possible to wrap every > > call out to system libraries with code to save and restore the > > register. Or, if you prefer to think of it this way, the wrapper > > would be on exit from and entry back into native Windows binary > > code. This would be somewhat similar to what we do with stack > > alignment, although we have compiler help for that. Either way, > > that would probably impose a significant performance penalty. > Sounds much more pleasant than an emulator. But doesn't the problem > also affect multitasking context switches? > > I have some llvm work (__ms_hook_prologue__) on my todo list anyway. > Maybe it's an idea to add a compiler feature to take care of this. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJTBmkoAAoJEN0/YqbEcdMwktIP/11AS7Dv48LWFM+cmwVkWtld > H7mHGe5Az6AYk8LeAfqXyA+tgk9MUtir8TQXZV3/6dAzLysf9kKDrikTPrSuqe8x > IhJyNPz5asiMDHwzUJLTkXoaefLPZYDIzEu8Ce0VuBOwiprK4CXdv2b43p3E+hyU > v5ERW0n01UBnQSKwDBwe60baRp7ToFv1BxNBATpidNZBdBIcKGpuqMVn2/nPytow > GSytIVEFTlnE7d+DiQnzANyiOUVbeM8mjkHNJGTaYi9xD/WrPksA7ZZw8RIZ7NnQ > L7nYyWyqOZ/r0tM31lQYuOOSiM5XqBWPRlGToGFpIzIsT+huXaYIxNSc7MsAhf7G > 5fHis0KrprXG1Rn5BhDUwgOxPyWDcAfg/iYmZhulVUEQar/shqdF22eM1lClzBqe > QPoQiyoXA9Q7JW307O7fGJt/8ih/03U+yH1pkvjcoZ0Cltzmu+UZT+irOX8rtocK > ABF+B6JPieZFk7QrlOyYKKFEtDyE9BjyKP9Lg5zeY7OMukhK/m9+hu7U+n/MsJPi > U5kFRwNX3E2jKAnLP2CFgJakr4OICY0XIGmMV0v6coAQQGHTBhJhQ7IlEKcilCYL > W/cPeOadKI1NHlvYHDxp1qp4tJiso7up7Vx5zLx/064lR+vrAv3c33Mn6zzMYvMC > R9uqODuYJvdgB/DV084m > =DHRq > -----END PGP SIGNATURE----- > > While you're in there, builtin_ms_va_list ( http://llvm.org/bugs/show_bug.cgi?id=8851) would be nice, to see how clang does with wine64. -- -Austin

Feb. 23, 2014

Re: oleaut32: Use BOOL type where appropriate

by Frédéric Delanoy

On Sat, Feb 22, 2014 at 6:39 PM, Ken Thomases <ken(a)codeweavers.com> wrote: > On Feb 22, 2014, at 11:14 AM, Frédéric Delanoy wrote: > >> According to MSDN, it's either 0 for non-leading zero, or 1 for >> leading.zero > > If the documented values are 0 or 1 (rather than, say, FALSE or TRUE), then why are you changing 0s and 1s to something else? > >> (hence TRUE/FALSE def'd to 1/0 in windef) > > "Hence" implies a causal relationship. The fact that TRUE and FALSE happen to be defined to 1 and 0 is unrelated to the fact that LeadingZero should be either 1 or 0. yeah, my sentence was a bit ambiguous/unclear, I meant "hence using T/F, which are defined to 1/0 in windef)." Sorry about that. > -Ken The LeadingZero conveys itself a boolean/logical semantics (i.e. has leading zeros or not), and it would be clearer to assign truths values to it IMHO (and it's not like T/F definitions are ever about to change). But of course I can understand your line of reasoning as well. Frédéric Delanoy

Feb. 22, 2014

Re: Fixing up the code style

by Chiitoo

On 22/02/14 20:50, Stefan Dösinger wrote: > > (Soory for the top post, phone...) > > I think the idea is to use spaces after keywords but not macro / > function names. But I don't know what the exact logic and rationale is. > I see. I guess that makes sense. Thanks! > I'll write a wiki page about the wined3d code style the next time I > review a patch with style issues or when I have some spare minutes and > the necessary motivazion. > Good idea, and definitely something I will be looking forward to!

Feb. 22, 2014

Re: Windows sets CCS_VERT when TB_GETEXTENDEDSTYLE is set

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://newtestbot.winehq.org/JobDetails.pl?Key=5092 Your paranoid android. === build (build) === Make failed

Feb. 22, 2014

Re: Fixing up the code style

by Stefan Dösinger

(Soory for the top post, phone...) I think the idea is to use spaces after keywords but not macro / function names. But I don't know what the exact logic and rationale is. I'll write a wiki page about the wined3d code style the next time I review a patch with style issues or when I have some spare minutes and the necessary motivazion. Am 22.02.2014 19:45 schrieb "Chiitoo" <escomk3(a)hotmail.com>: > Teegrins! > > > On 13/02/14 15:09, Stefan Dösinger wrote: > > Hi, > > After recently helping two contributors (the Pipelight guys and Martin > Storsjö) through the maze of the Wine code style I think it's best to > lift the ban against style-only patches and unify the code style once > and for all. > > The basic reasoning is that from my point of view the lack of clarity > wrt the code style and lack of automatic enforceability is causing > more issues than the problems style-only patches cause with git blame. > Finding a style-only change with git blame can be handled by running > git blame again. Frustrating contributors on the other hand has no > workaround. > > So I propose to agree on a code style for the entire project, fixing > it up preferably with an automated tool and in the future enforcing > the style with checks in the Testbot. > > Opinions? > > Wrt the code style I propose the style that is used in wineserver. It > is the same one as the new style in the d3d code except for > single-line if conditions. > > Cheers, > Stefan > > > I, for one, like this idea. > > Not that my likes mean much (if anything), at least not yet, but I'm > hoping one day I am able to contribute actual code to the project. As > such, I have been delving more and more into the code of Wine, and I tend > to learn from my surroundings, where inconsistency certainly isn't too > helpful. > It might also mean that I would further make it inconsistent by following > whatever conventions happen to be around specific code (although that in > itself could be considered consistent, in a way, though I am aware of > changing code to follow a certain style being a thing while editing > particular code for some other reason). > > Either way, for what it's worth, I like the proposal. > > > Also, I have a more or less related (possibly silly) question as well, > which is what pushed me to post here for the first time ever just now: > > As I understand it, a whitespace is to be used after 'ifs' and such. Why > is this not the case for TRACEs, ERRs, WARNs, and the likes as seen in the > example below? > > if (cs->state.textures[i] == prev) > { > TRACE("Texture is also bound to stage %u.\n", i); > prev->sampler = i; > break; > } > > Perhaps it's wrong for me to group those things together at all, but I > guess it would just look better to me if there was a space after TRACE as > well. > > > Just some thoughts! > > Kind Regards (and many thanks), > Chiitoo >

Feb. 22, 2014

Re: Fixing up the code style

by Chiitoo

Teegrins! On 13/02/14 15:09, Stefan Dösinger wrote: > Hi, > > After recently helping two contributors (the Pipelight guys and Martin > Storsjö) through the maze of the Wine code style I think it's best to > lift the ban against style-only patches and unify the code style once > and for all. > > The basic reasoning is that from my point of view the lack of clarity > wrt the code style and lack of automatic enforceability is causing > more issues than the problems style-only patches cause with git blame. > Finding a style-only change with git blame can be handled by running > git blame again. Frustrating contributors on the other hand has no > workaround. > > So I propose to agree on a code style for the entire project, fixing > it up preferably with an automated tool and in the future enforcing > the style with checks in the Testbot. > > Opinions? > > Wrt the code style I propose the style that is used in wineserver. It > is the same one as the new style in the d3d code except for > single-line if conditions. > > Cheers, > Stefan I, for one, like this idea. Not that my likes mean much (if anything), at least not yet, but I'm hoping one day I am able to contribute actual code to the project. As such, I have been delving more and more into the code of Wine, and I tend to learn from my surroundings, where inconsistency certainly isn't too helpful. It might also mean that I would further make it inconsistent by following whatever conventions happen to be around specific code (although that in itself could be considered consistent, in a way, though I am aware of changing code to follow a certain style being a thing while editing particular code for some other reason). Either way, for what it's worth, I like the proposal. Also, I have a more or less related (possibly silly) question as well, which is what pushed me to post here for the first time ever just now: As I understand it, a whitespace is to be used after 'ifs' and such. Why is this not the case for TRACEs, ERRs, WARNs, and the likes as seen in the example below? if (cs->state.textures[i] == prev) { TRACE("Texture is also bound to stage %u.\n", i); prev->sampler = i; break; } Perhaps it's wrong for me to group those things together at all, but I guess it would just look better to me if there was a space after TRACE as well. Just some thoughts! Kind Regards (and many thanks), Chiitoo

Feb. 22, 2014

Re: oleaut32: Use BOOL type where appropriate

by Ken Thomases

On Feb 22, 2014, at 11:14 AM, Frédéric Delanoy wrote: > According to MSDN, it's either 0 for non-leading zero, or 1 for > leading.zero If the documented values are 0 or 1 (rather than, say, FALSE or TRUE), then why are you changing 0s and 1s to something else? > (hence TRUE/FALSE def'd to 1/0 in windef) "Hence" implies a causal relationship. The fact that TRUE and FALSE happen to be defined to 1 and 0 is unrelated to the fact that LeadingZero should be either 1 or 0. -Ken

Feb. 22, 2014

Re: oleaut32: Use BOOL type where appropriate

by Frédéric Delanoy

On Sat, Feb 22, 2014 at 12:36 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > On 2/22/2014 15:22, Frédéric Delanoy wrote: >> >> --- >> dlls/oleaut32/varformat.c | 8 ++++---- >> dlls/oleaut32/vartype.c | 2 +- >> 2 files changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/dlls/oleaut32/varformat.c b/dlls/oleaut32/varformat.c >> index e72a170..a6a10cf 100644 >> --- a/dlls/oleaut32/varformat.c >> +++ b/dlls/oleaut32/varformat.c >> @@ -2303,9 +2303,9 @@ HRESULT WINAPI VarFormatNumber(LPVARIANT pVarIn, INT >> nDigits, INT nLeading, INT >> if (nLeading == -2) >> GETLOCALENUMBER(LOCALE_ILZERO, LeadingZero); >> else if (nLeading == -1) >> - numfmt.LeadingZero = 1; >> + numfmt.LeadingZero = TRUE; >> else >> - numfmt.LeadingZero = 0; >> + numfmt.LeadingZero = FALSE; >> if (nGrouping == -2) >> { >> @@ -2484,9 +2484,9 @@ HRESULT WINAPI VarFormatCurrency(LPVARIANT pVarIn, >> INT nDigits, INT nLeading, >> if (nLeading == -2) >> GETLOCALENUMBER(LOCALE_ILZERO, LeadingZero); >> else if (nLeading == -1) >> - numfmt.LeadingZero = 1; >> + numfmt.LeadingZero = TRUE; >> else >> - numfmt.LeadingZero = 0; >> + numfmt.LeadingZero = FALSE; >> > > That's not a case when it's appropriate - 'LeadingZero' is UINT, not BOOL. > Somewhat improved variant of above conditions could look like that: > > --- > else > numfmt.LeadingZero = nLeading == -1; According to MSDN, it's either 0 for non-leading zero, or 1 for leading.zero (hence TRUE/FALSE def'd to 1/0 in windef) Now obviously the field type can't be modified, but in other places in the code, booleans are stored e.g. in unsigned foo:1, or other unsigned type. cf. http://msdn.microsoft.com/en-us/library/windows/desktop/dd319095%28v=vs.85%… http://msdn.microsoft.com/en-us/library/windows/desktop/dd373784%28v=vs.85%… Frédéric

Feb. 22, 2014