November 2010 - Wine-Devel - list.winehq.org

Re: [RFC] cmd: Add a space at the end of the first echo'ed batch line [try5]

by Vitaliy Margolen

On 11/01/2010 07:37 AM, GOUJON Alexandre wrote: > Hi everyone, > > I'm trying to fix the wine cmd behavior but as this 5th try differs greatly > with the previous one, I'd like to have some feedback before submitting it. > > If you have any question, just let me know. > Thanks is advance. > > + static const char escaped_space[] = "@space@"; > + DWORD len_space = strlen(escaped_space); The better way to calculate size of a static string, which is a compile time calculation. strlen() call is a runtime. You should move declaration from compare_line() and use it instead here. > +static char* replace_escaped_spaces(const char *data, DWORD size, DWORD *new_size) > + char *a, *b, *new_data; > + a = b = (char*)data; a, b should be "const char*" as well. > + new_data = (char*)malloc(size*sizeof(char)); Don't use malloc in Wine. Use HeapAlloc & co. This is not c++, don't need to typecast (void*) pointer. > + new_size += b-a +1; You are modifying the new_size pointer instead of value it points to. > + if(!run_cmd(actual_cmd_data, actual_cmd_size)) > return; You leaking actual_cmd_data here. > + if(actual_cmd_data) > + free(actual_cmd_data); Don't need to check if pointer is NULL before freeing it. free() and HeapFree() do that already. Vitaliy.

Nov. 1, 2010

[RFC] cmd: Add a space at the end of the first echo'ed batch line [try5]

by GOUJON Alexandre

Hi everyone, I'm trying to fix the wine cmd behavior but as this 5th try differs greatly with the previous one, I'd like to have some feedback before submitting it. If you have any question, just let me know. Thanks is advance.

Nov. 1, 2010

Re: [try 2] crypt32/tests: Add tests for enveloped messages.

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 http://testbot.winehq.org/JobDetails.pl?Key=6658 Your paranoid android. === WNT4WSSP6 (32 bit msg) === msg: unhandled exception c0000005 at 5CF308F4

Nov. 1, 2010

[do not apply] Re: crypt32/tests: Add tests for enveloped messages.

by Alexander Morozov

Please do not apply this patch. Use [try 2]

Nov. 1, 2010

Re: [PATCH 2/2] comdlg32/tests: Add GetSaveFileName extension tests.

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 http://testbot.winehq.org/JobDetails.pl?Key=6657 Your paranoid android. === W98SE (32 bit filedlg) === filedlg.c:1094: Test failed: Filename is beef.txt, expected deadbeef === WNT4WSSP6 (32 bit filedlg) === filedlg.c:1094: Test failed: Filename is beef.txt, expected deadbeef === W2KPROSP4 (32 bit filedlg) === filedlg.c:1094: Test failed: Filename is beef.txt, expected deadbeef === WXPPROSP3 (32 bit filedlg) === filedlg.c:1094: Test failed: Filename is beef.txt, expected deadbeef === W2K3R2SESP2 (32 bit filedlg) === filedlg.c:1094: Test failed: Filename is beef.txt, expected deadbeef === WVISTAADM (32 bit filedlg) === filedlg.c:1094: Test failed: Filename is beef.txt, expected deadbeef === W2K8SE (32 bit filedlg) === filedlg.c:1094: Test failed: Filename is beef.txt, expected deadbeef === W7PRO (32 bit filedlg) === filedlg.c:1094: Test failed: Filename is beef.txt, expected deadbeef === W7PROX64 (32 bit filedlg) === filedlg: unhandled exception c0000005 at 750B4C19 === W7PROX64 (64 bit filedlg) === filedlg.c:1094: Test failed: Filename is beef.txt, expected deadbeef

Nov. 1, 2010

Re: [4/4] d3d9: Add a sRGB format test

by Henri Verbeet

On 1 November 2010 11:41, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > Am 01.11.2010 um 10:41 schrieb Henri Verbeet: > >> On 31 October 2010 22:53, Stefan Dösinger <stefan(a)codeweavers.com> wrote: >>> + static const struct >>> + { >>> + float x, y, z; >>> + float u, v; >>> + } >>> + quad[] = >>> + { >>> + {-1.0, -1.0, 0.1, 0.0, 0.0}, >>> + {-1.0, 1.0, 0.1, 1.0, 0.0}, >>> + { 1.0, -1.0, 0.1, 0.0, 1.0}, >>> + { 1.0, 1.0, 0.1, 1.0, 1.0} >>> + }; >> Not that I care all that much, but notice that those literals are >> actually doubles. > Now that I've fixed a number of those I guess we should stick to caring about that. You should probably do the Clear()'s too then.

Nov. 1, 2010

Re: [PATCH 2/4] include: Add macros for retrieving control message headers.

by Alexandre Julliard

Erich Hoover <ehoover(a)mines.edu> writes: > @@ -185,6 +185,25 @@ VOID WINAPI GetAcceptExSockaddrs(PVOID, DWORD, DWORD, DWORD, struct WS(sockaddr) > BOOL WINAPI TransmitFile(SOCKET, HANDLE, DWORD, DWORD, LPOVERLAPPED, LPTRANSMIT_FILE_BUFFERS, DWORD); > INT WINAPI WSARecvEx(SOCKET, char *, INT, INT *); > > +/* > + * Macros for retrieving control message data returned by WSARecvMsg() > + */ > +#define WSA_CMSG_DATA(cmsg) ((UCHAR*)((WSACMSGHDR*)(cmsg)+1)) > +#define WSA_CMSG_FIRSTHDR(mhdr) \ > + ((size_t) (mhdr)->Control.len >= sizeof(WSACMSGHDR) \ > + ? (WSACMSGHDR *) (mhdr)->Control.buf : (WSACMSGHDR *) 0) > +#define WSA_CMSG_ALIGN(len) (((len) + sizeof (size_t) - 1) \ > + & (size_t) ~(sizeof (size_t) - 1)) > +static inline WSACMSGHDR *WSA_CMSG_NXTHDR(WSAMSG *msg, WSACMSGHDR *cmsg) > +{ > + if ((size_t)(msg)->Control.len<sizeof(WSACMSGHDR)) return 0; > + cmsg = (WSACMSGHDR*)((unsigned char*)cmsg + WSA_CMSG_ALIGN(cmsg->cmsg_len)); > + if ((unsigned char*)(cmsg+1) > ((unsigned char*)msg->Control.buf + msg->Control.len) > + || ((unsigned char*)cmsg + WSA_CMSG_ALIGN(cmsg->cmsg_len) > ((unsigned char *)msg->Control.buf + msg->Control.len)) ) > + return 0; > + return cmsg; > +} This should go into ws2def.h. Also WSA_CMSG_NXTHDR is supposed to be a macro, not an inline function. -- Alexandre Julliard julliard(a)winehq.org

Nov. 1, 2010

Re: [4/4] d3d9: Add a sRGB format test

by Henri Verbeet

On 31 October 2010 22:53, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > + static const struct > + { > + float x, y, z; > + float u, v; > + } > + quad[] = > + { > + {-1.0, -1.0, 0.1, 0.0, 0.0}, > + {-1.0, 1.0, 0.1, 1.0, 0.0}, > + { 1.0, -1.0, 0.1, 0.0, 1.0}, > + { 1.0, 1.0, 0.1, 1.0, 1.0} > + }; Not that I care all that much, but notice that those literals are actually doubles. > + hr = IDirect3DDevice9_DrawPrimitiveUP(device, D3DPT_TRIANGLESTRIP, 2, quad, sizeof(float) * 5); Now that you're using a proper structure for "quad", "sizeof(float) * 5" is really just the same as "sizeof(*quad)".

Nov. 1, 2010

Re: Problems with Test

by Charles Davis

On 10/31/10 9:23 PM, James McKenzie wrote: > All: > > I'm trying to convert one integer number using a float number factor. > Here is the code: > > int ry = 125; > double ryf; > > ryf = ry/1440; > > The result is 0 and should be 0.06666666667 (or even more sixes.) And why should it be? None of the values in the expression 'ry/1440' are of type 'double'. They're both 'int's, so the compiler sees it as integer division instead of FP division. The C language spec doesn't require the compiler to infer that you wanted FP division when you assign to a variable of FP type. > What am I doing 'incorrectly'? Now, if your assignment looked like this: ryf = ry/1440.0; then it would work correctly. Now the 1440 is of type 'double', so the compiler emits a floating-point division. Chip

Nov. 1, 2010

Problems with Test

by James McKenzie

All: I'm trying to convert one integer number using a float number factor. Here is the code: int ry = 125; double ryf; ryf = ry/1440; The result is 0 and should be 0.06666666667 (or even more sixes.) BTW, if I change ry to 1440 the result is 1.00000. What am I doing 'incorrectly'? James McKenzie

Nov. 1, 2010