Have I got this right?
Thanks,
-- Andy.
---
Changelog:
winedos: Initializations fix.
diff --git a/dlls/winedos/int21.c b/dlls/winedos/int21.c
index 0c7967f..cbce913 100644
--- a/dlls/winedos/int21.c
+++ b/dlls/winedos/int21.c
@@ -2182,6 +2182,7 @@ static BOOL INT21_FileAttributes( CONTEXT86
Oops! Please ignore this one: I only changed the prototype of MapLS() and
forgot to change the definition.
--
Andy.
Francois Gouget wrote:
I could not find MapLS declared in winbase.h in any of the SDKs I have
here. However I found it in win_me/inc16/thunks.h in an old DDK
(Microsoft Windows 2000 DDK) but the declaration was:
DWORD WINAPI MapLS(DWORD);
But this being what looks like a 16bit include
Andrew Talbot wrote:
It's a tabs vs spaces thing, but it looks way out on my system.
You might wish to ignore this patch. I had my tab stops set to four spaces
instead of eight, which exaggerated the distortion.
--
Andy.
Andrew Talbot wrote:
The TRACE() potentially reporting the value of newpath must be placed
after where that variable is first set.
I suspect that this patch still doesn't fix the problem. Feedback or expert
intervention is welcomed!
Thanks.
--
Andy.
Francois Gouget wrote:
So dlls/rsaenh/mpi.c defines 13 functions that are only used there. So
they could be made static by tweaking mpi.c and tomcrypt.h.
However my understanding is that this files has been imported in Wine
from another project so maybe it's not a good idea to diverge
Francois Gouget wrote:
The bug is with -O3 which is not the default and which I would not
personally care about. I'd be more open about maintenance issues.
My inclination would be to make the functions static. However, how to handle
the comments is an issue to consider. Also, I probably made
Eric Pouech wrote:
looks like a bit strange to me that you get a null typename here
can you send me the DLL/.so file on which you get the seg fault
A+
No known segfaults; I'm just doing static analysis. But
stabs_pts_read_type_def() is called several times within stabs.c passing
NULL as a
Eric Pouech wrote:
however the last trace should be protected (and debugstr_a is a better
choice than testing for a null string)
A+
Thanks, Eric. I've sent a replacement patch (with a revised title).
--
Andy.
Alexandre Julliard wrote:
The types are local to the C file so there is no clash. If some tools
don't understand that they need to be fixed.
Not arguing, just clarifying:
File #1: joystick_input.c has a non-static struct tag called JoystickImpl.
File #2: joystick_linuxinput.c has a
Alexandre Julliard wrote:
Static is for variables, not for types. Types are local to the file they
are declared in, that's why you need header files when you want to share
type declarations.
Ah, yes. It seems that only objects (i.e., named regions of storage) and
functions with external
Hi Michael,
Michael Stefaniuc wrote:
Andrew Talbot wrote:
-if (!szConvertedList || dwFileCount == -1)
+if (!szConvertedList || (LONG)dwFileCount == -1)
This one could be replaced by a comparison with either -1u or ~0.
bye
michael
The first of these would work; the second
Andrew Talbot wrote:
(The reason I say
decimal zero is because decimal constants are signed, whereas
hexadecimal constants are unsigned[!] Thus, ~0x0 would be a viable
alternative.)
In fact, I have just tried both ~0 and ~0x0 and neither worked. (I can't figure
out why the latter fails
Andrew Talbot wrote:
Andrew Talbot wrote:
(The reason I say
decimal zero is because decimal constants are signed, whereas
hexadecimal constants are unsigned[!] Thus, ~0x0 would be a viable
alternative.)
In fact, I have just tried both ~0 and ~0x0 and neither worked. (I can't
figure
James Hawkins wrote:
On Sat, Aug 2, 2008 at 4:09 PM, Andrew Talbot
[EMAIL PROTECTED] wrote:
Changelog:
fusion: Use proper function pointer.
diff --git a/dlls/fusion/fusion.c b/dlls/fusion/fusion.c
index ac01cf4..637346c 100644
--- a/dlls/fusion/fusion.c
+++ b/dlls/fusion/fusion.c
You might want to forget this one. I guess no one is compiling Wine on a
broken, pre-ANSI compiler. So the expansion of macro parameters inside
string literals may well, in effect, be a non-issue.
--
Andy.
Hi,
Is it possible to sneak in a bit of patch cleaning within the new software? It
would be useful to incidentally remove any trailing white space that happens to
exist within the scope of a patch.
--
Andy.
Juan Lang wrote:
Hi Andy,
+LONG last_error;
ret = CryptGetObjectUrl(URL_OID_CERTIFICATE_CRL_DIST_POINT,
rgpvContext[i], 0, NULL, cbUrlArray, NULL, NULL, NULL);
-if (!ret GetLastError() == CRYPT_E_NOT_FOUND)
+last_error =
Juan Lang wrote:
Yes, I know what the value of CRYPT_E_NOT_FOUND is, and what the type
of GetLastError is. My point is, Microsoft confused signed and
unsigned types for their last error values. We have to live with it.
Indeed. (And sorry, I didn't mean to sound patronizing.)
I don't
James Hawkins wrote:
On Tue, Sep 9, 2008 at 3:54 PM, Andrew Talbot
[EMAIL PROTECTED] wrote:
Fix for Coverity error CID: 762.
[...]
-RegCloseKey(userdata);
+if (userdata) RegCloseKey(userdata);
return rc;
Please don't add another NULL-before-free check.
Hi James,
Sorry
James Hawkins wrote:
Sorry, I don't understand what I have done wrong. RegCloseKey() will
return ERROR_INVALID_HANDLE if called with hkey==NULL.
...and we don't care what value it returns.
Ah, of course! Thanks, James (and Juan).
--
Andy.
Austin English wrote:
This-baseShader.device;
int i;
-unsigned int extra_constants_needed = 0;
+unsigned int i, extra_constants_needed = 0;
You forgot to remove 'int i' here.
Thanks, Austin. Good catch!
--
Andy.
Please do not apply this patch, it is wrong.
--
Andy.
Juan Lang wrote:
Hi Andy,
-if (pbEncoded[1] + 1 cbEncoded)
+if (pbEncoded[1] + 1U cbEncoded)
Is this change necessary? The resulting code is less clear than the
original, IMO. It's clearly a spurious warning: a BYTE (max value
255) + 1 can't yield a value that
Hi Juan,
Juan Lang wrote:
The case I objected to is a curious one. I had a look at KR's type
promotion rules (2nd edition, section A6.5) and I'm confused what the
compiler is doing here. The if-block is:
if (pbEncoded[1] + 1 cbEncoded)
Rewriting the parenthesized expression as types
On Fri Dec 12 0:58 , Michael Stefaniuc sent:
Andrew Talbot wrote:
What is wrong with this patch, please?
If I may venture a guess: You have replaced a nice and concise for loop
into and ugly 4 line while loop.
bye
michael
Hi Michael,
Ugly? Andrew Koenig and Barbara Moo show
On Fri Dec 12 10:29 , Michael Stefaniuc mstef...@redhat.com sent:
Andrew Talbot wrote:
But how would you then fix the sign-compare violation, or would you just let
this
one go?
I had to look twice as the initial warning was in a for loop above:
Either leave it as is for now as the warning
It appears that the following vtables and Wine debug channels are not being
used, so I am considering removing them. Please let me know, therefore, if you
have plans for any of them and want them kept.
Vtables:
IDirectXFileBinary_Vtbl d3dxof/d3dxof.c
IDirectXFileObject_Vtbl
James Hawkins wrote:
Why would you remove any of them? That's like removing stub functions
because we don't know if they're ever called.
OK. I get the message; I shall leave the vtables alone. May I take out the
unused debug channels, though? I presume they can easily be re-introduced
Ken Thomases wrote:
On Dec 15, 2008, at 3:41 PM, Andrew Talbot wrote:
It appears that the following vtables and Wine debug channels are
not being used, so I am considering removing them. Please let me
know, therefore, if you have plans for any of them and want them kept.
Wine debug
Christian Costa wrote:
Hi Andrew,
BTW, if the vtable are removed, there may be some unused functions. Will
they be removed as well ?
Bye,
Christian
Hi Christian,
Because I was mindful not to remove such things lightly, that is why I
sought feedback from the community, and I shall
On Thu Dec 18 22:41 , 'James Hawkins' trui...@gmail.com sent:
I didn't write jscript, so I'm not the expert, but create_string is
internal, so we should probably crash if str is NULL instead of hiding
the error. What is this patch for?
--
James Hawkins
Hi James,
create_string() is called
Jacek Caban wrote:
The string was always zero-terminated without your patch. It's fine to
call create_string with NULL str argument as long as len is 0 and
current implementation works fine in this case.
Jacek
Hi Jacek,
Technically, behavior is undefined if the pointers do not each
Dan Kegel wrote:
I updated http://wiki.winehq.org/Wine64 with a list
of some win64 apps. There are lots more than I
expected.
Some of the top chess engines, such as Rybka (www.rybkachess.com) have
64-bit versions.
Jacek Caban wrote:
I'm not fan of such fixes, but if you want to fix it, you should check
len, not str, in your patch and you may move zero-terminating outside
if..else statement.
Jacek
Thank you, I shall fix it in the better way that you describe here.
--
Andy.
Francois Gouget wrote:
I have attached a script that identifies functions that should be made
static (among other things). There are approximately 450 of them, there
should be pretty efw false positives, and I will look into them
eventually. But if someone beats me to it I sure won't
Or wineoss.drv:..., to be precise.
Francois Gouget wrote:
Thanks for the help with this task. With the last round of patches we
are now down to about 280 warnings so there's definite progress. Here's
the updated list:
[...]
Here are the apparently unused functions I have encountered in the dlls so
far. Please speak up for
Francois Gouget wrote:
Also, for everyone's information, there's more calls to malloc() and
free().
There are also many calls to realloc() - a function with complexities of its
own - and other functions with realloc in their name.
--
Andy.
Andrew Talbot wrote:
Sorry, title should be:
winedos: Replace [m|c]alloc() with HeapAlloc()
--
Andy.
Dmitry Timoshkov wrote:
Andrew Talbot [EMAIL PROTECTED] wrote:
-typedef void *MSIITERHANDLE;
+typedef void*MSIITERHANDLE;
+typedef const void *MSICITERHANDLE;
Personally I don't like MSICITERHANDLE typedef at all. It' not obvious
that 'C' in the name marks constness
Dmitry Timoshkov wrote:
Andrew Talbot [EMAIL PROTECTED] wrote:
The last formal argument of MCIWndCreate() is not const-qualified in the
SDK.
It is in my version of the PSDK headers, but it is not in the PSDK docs.
Not having access to any version of the SDK, my only source of reference
Francois Gouget wrote:
Actually they are in recent PSDKs (for instance the Windows 2003 SP2
PSDK).
So this patch should not be applied.
Acknowledged with thanks to Dmitry and yourself.
-- Andy.
Huw Davies wrote:
On Wed, Nov 08, 2006 at 09:56:54PM +, Andrew Talbot wrote:
@@ -666,16 +672,20 @@
if(psA-cPasteEntries 0)
{
UINT i;
-for(i = 0; i psA-cPasteEntries; i++)
+
+for(i = psA-cPasteEntries; i != 0;)
Was there any need for this?
Huw
In qcap/pin.c, the function OutputPin_GetDeliveryBuffer() shows the
parameters tStart and tStop as being of type const REFERENCE_TIME *.
Looking at the SDK web site, I see a function called
CBaseOutputPin::GetDeliveryBuffer() that has similar parameters that are
non-const.
May I deconstify these
Dimi Paun wrote:
On Wed, November 15, 2006 5:02 pm, Andrew Talbot wrote:
- static const WCHAR szProperty[] = {
+ static WCHAR szProperty[] = { '{','D','0','F','C','A','4','2','0',
If they aren't constant, shouldn't they be non-static too?
Hi Dimi,
As I understand it, declaring them
On Wed, November 15, 2006 5:02 pm, Andrew Talbot wrote:
- static const WCHAR szProperty[] = {
+ static WCHAR szProperty[] = { '{','D','0','F','C','A','4','2','0',
If they aren't constant, shouldn't they be non-static too?
--
Dimi Paun dimi at lattica.com
http://www.winehq.org/mailman
Dimi Paun wrote:
On Thu, November 16, 2006 12:42 pm, Andrew Talbot wrote:
As I understand it, declaring them static means that the storage will be
assigned and initialised at compile time, rather than run time, since the
size and contents are already known.
Correct. However
Paul Vriens wrote:
Just out of curiosity. Why is the HeapFree superfluous? It is allocated
a few lines above and not free-ed in this fail condition.
Cheers,
Paul.
Hi Paul,
The fail condition is that no memory was available, therefore, what is there
to free?
-- Andy.
Hi Andy,
the failing allocation was for lpNewFormat-Name. The freeing was for
lpNewFormat on line 516 (original).
Cheers,
Paul.
Whoops! You're right. Thank you for pointing it out; I shall post a please
ignore to wine-patches.
-- Andy.
Sorry, I made a mess of titling this patch, twice. Please find and use
the version whose subject line and changelog entry refer to winedump, not
winedbg.
Thanks,
-- Andy.
Mike McCormack wrote:
Andrew Talbot wrote:
-if( n 0 )
+if( (LONG)n 0 )
Why not change the type of n to LONG rather than using a cast?
Mike
Hi Mike,
Long answer (no pun intended):
There were two ways to jump: I could either have, as you say, made n long,
so it could
Hi,
Apart from any oversights, I have completed my run of cast-qual fixes for
the dlls and dlls/tests directories.
The one file that most distorts the picture when -Wcast-qual is applied
is unicode.h, since its wide-string functions are inlined and it is
included quite widely.
I have posted a
Alexandre Julliard wrote:
Andrew Talbot [EMAIL PROTECTED] writes:
I believe these identifiers are POSIX ones (from sys/stat.h), so they
should not possess one leading underscore (unlike the similar ones in
msvcrt).
These defines are meant for Windows, where they do have underscores.
I
Alexandre Julliard wrote:
On any decent Unix the S_ISCHR etc. macros are defined by sys/stat.h,
so our defines are never used.
Right. I now see that Splint represents S_ISCHR() and the like as functions
(despite containing a comment saying that they're macros virtually
everywhere), so the
Hi,
I am intending to send in a few patches to remove some unused Wine variables
and functions from the dlls. Please accept that my good faith is tempered
by a degree of ignorance, and advise me of suitable markup if any seemingly
redundant piece of code I seek to remove must remain for a
Robert Shearman wrote:
Did you try compiling linking this? WINAPI is usually only applied to
exported functions.
Hi Rob,
My patch was totally wrong: I think I must have compiled and linked
the before version. I infer that an exported function (in the DLL sense)
must have external linkage
Marcus Meissner wrote:
Err, why?
They are clearly exported from the .spec file and you just killed the
exports?
They likely are used by Windows programs.
Ciao, Marcus
Hi Marcus,
I trusted the comment just before the declarations, which says:
/* The following data items are not
Robert Shearman wrote:
However, it had an implicit ... but they are exported from this DLL.
Right. My brain has just caught up with you.
As you can see, I'm trawling through the dlls looking for anything I can
legitimately take out of the global namespace. I am trying to be as careful
as I
Alexandre Julliard wrote:
There is no reason to add a lot of complexity to fix leaks in
short-lived apps like winegcc.
Acknowledged.
Thanks,
-- Andy.
I was looking at Coverity bug report #CID294, and that has led me to ask about
the base and limit values of the DLLSPEC structure.
In winebuild/utils.c, we have:
spec-base = MAX_ORDINALS;
spec-limit = 0;
Is that the correct way round?
Thanks,
-- Andy.
Hi,
I just thought I should mention that the timestamps for Last message date:
and Archived on: at
http://www.winehq.org/pipermail/wine-cvs/2007-January/ are currently given
as CDT times, whereas those of the individual patches are correctly shown
as CST.
Thanks,
-- Andy.
Michael Stefaniuc wrote:
-SIMPLE(LONG64, LONG, VarI8FromI4);
Are you removing a test here?
Hi Michael,
I'm not sure what you mean. All I know is that the SIMPLE() macro - also
in oleaut32/vartype.c - is defined as follows.
/* Inline return type */
#define RETTYP inline static HRESULT
/*
Sorry. This patch breaks compilation. Please do not apply.
-- Andy.
Marcus Meissner wrote:
This is not a good idea, it will optimize those functions away, since gcc
cannot look into the DEFINE_REGS_ENTRYPOINT() assembly.
Ciao, Marcs
Hi Marcus,
Thanks for putting me straight. I accidentally submitted this patch before
realising that I had forgotten to
Felix Nawothnig wrote:
Andrew Talbot wrote:
-BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPSTR lpSubBlock,
+BOOL WINAPI VerQueryValueA( LPVOID pBlock, LPCSTR lpSubBlock,
This is wrong - in the PSDK headers it's LPSTR (the first parameter
should be const though).
Felix
I've seen
Scott Ritchie wrote:
On several occasions I have received emails referring to Wine version
0.9.3. One person even told me about a regression from 0.9.28 to 0.9.3.
Presumably, this version is being confused with Wine 0.9.30 in these
letters, however I have been unable to tell whether people
The problem seems to be that the INTERNET_CACHE_ENTRY_INFO structure has a
member lpHeaderInfo that is a LPBYTE, but the corresponding parameter of
CommitURLCacheEntry() - sorry, I truncated its name in the original
posting - ought to be a LPTSTR. It is not yet clear to me what is required.
--
Andrew Talbot wrote:
... but the corresponding parameter of
CommitURLCacheEntry() [...] ought to be a LPTSTR
Or rather, a LPCTSTR.
So, is there any scope to constify, here?
-- A.
James Hawkins wrote:
#ifndef USE_FIXED_COMMIT_URL_CACHE_ENTRY
// Temporary state of affairs until we reconcile our apis.
Thanks, James. Maybe one day, then. :)
-- Andy.
Assuming it is valid and does what is required, maybe the following pragma
would be more precise.
#pragma GCC diagnostic warning -Wwrite-strings
-- Andy.
Of course, what I should have written was:
Assuming it is valid and does what is required, maybe the following pragma
would be more precise.
#pragma GCC diagnostic ignored -Wcast-qual
Sorry. I did too much cutting and pasting, and not enough thinking.
-- Andy.
Mike Schaadt wrote:
I attempted using the suggested '#pragma GCC diagnostic ignored
-Wcast-qual' in replace of what I submited, however I received the
warning 'ignoring #pragma GCC diagnostic' message, plus the normal
warnings from unicode.h
My guess is that I might be using an older
James Hawkins wrote:
Are you checking with the SDK to make sure these changes are legit?
This isn't how the Windows SDK fdi.h has these defined.
I ascertained that the function-pointer parameters of FDICreate() should
have the same signatures as the corresponding low-level file functions
James Hawkins wrote:
That's not how it works. PFNOPEN, et al., has a specific definition
that is similar to, but not the same as, the corresponding low-level
file IO function. If you make a change to a public header, you need
to check the same header in the SDK and make sure that the change
Ivan Gyurdiev wrote:
Why should inline static be replaced with static inline.
Does it improve compatibility with certain compilers?
Also, does wine aim to be compliant with ANSI, C99, or somewhere in
between (-gnu89)?
Hi Ivan,
Although declaration specifiers (i.e., storage-class
Alexandre Julliard wrote:
Andrew Talbot [EMAIL PROTECTED] writes:
+++ b/dlls/comctl32/draglist.c 2007-03-24 10:29:36.0 +
@@ -91,7 +91,7 @@
}
/* cleans up after dragging */
-static void DragList_EndDrag(HWND hwnd, DRAGLISTDATA * data)
+static void DragList_EndDrag
On Saturday 07 April 2007 21:00, Eric Pouech wrote:
I don't see the point of still having return; as last statement of
function. It can be safely removed
A+
Thanks, Eric. I've now posted a return-less version.
--
Andy.
Hi,
I run an app (Blitzin2) that displays scrolling text with various
highlightings in a rich edit control. When displaying hyperlinks comprising
normal words, they are rendered in blue and underlined, and whatever
follows is rendered appropriately. However, if the displayed link text
happens to
Robert Shearman wrote:
Andrew Talbot wrote:
diff -urN a/dlls/ole32/rpc.c b/dlls/ole32/rpc.c
--- a/dlls/ole32/rpc.c 2007-03-28 12:43:32.0 +0100
+++ b/dlls/ole32/rpc.c 2007-04-12 20:20:48.0 +0100
@@ -1352,7 +1352,7 @@
TRACE(ipid = %s, iMethod = %d\n
James Hawkins wrote:
Read Andrew's last sentence. Technically no return is needed, but it
can be added for aesthetics.
Thanks, James (and everyone). If the patch gets rejected, I shall resubmit
it with added returns.
-- Andy.
Robert Shearman wrote:
Andrew Talbot wrote:
typedef BOOL (WINAPI *CryptDecodeObjectFunc)(DWORD, LPCSTR, const BYTE
*,
DWORD, DWORD, void *, DWORD *);
typedef BOOL (WINAPI *CryptDecodeObjectExFunc)(DWORD, LPCSTR, const BYTE
*,
- DWORD, DWORD, PCRYPT_DECODE_PARA, void *, DWORD
Robert Shearman wrote:
Andrew Talbot wrote:
*/
static HRESULT WINAPI DEVENUM_IClassFactory_CreateInstance(
LPCLASSFACTORY iface,
-LPUNKNOWN pUnkOuter,
+const IUnknown *pUnkOuter,
REFIID riid,
LPVOID *ppvObj)
I'm not sure what the point of this is.
Hi
I have just sent in a patch to use Wine's sql.h instead of the system one,
because I noticed that the latter includes sqltypes.h, which appears to
redefine DWORD as unsigned long, based on its reckoning that the size of a
long integer is four bytes on default platforms, whereas - with _MSC_VER
It looks like I needed to tell my linting tool to search the local include
directory before searching the system one.
-- Andy.
Misha Koshelev wrote:
So is the general recommendation for wine that we not use Hungarian
notation then?
Misha
IMHO, a prefix is of little value if it merely echos the declared type of
the variable it represents, especially in a small-scope situation. To be of
value, a prefix needs to
Apologies for the duplicates: the originals were slow to arrive, so I
presumed they got lost and sent them again.
-- Andy.
Please note: I set the indentation of some amended lines to match that in
the majority of the surrounding functions.
--
Andy.
Hi,
I want to patch msi:action.c:ITERATE_WriteEnvironmentString() so that it
only calls RegCloseKey(env), in the cleanup, if env has been initialized
(to fix Coverity report CID-562). I can bypass the call to RegCloseKey()
for any early exit that occurs prior to calling RegOpenKeyExW(), and I can
Tom Spear wrote:
At the risk of looking like an idiot, I'll take a stab at this.. If
you RegCloseKey on env, and it is not initialized, then RegCloseKey
will generate ERROR_INVALID_HANDLE, so I personally think that
something like the first approach would be the better one to go with.
env
Paul Vriens wrote:
Wouldn't it be easier to set env to NULL when declaring it and do a:
if (env) RegCloseKey(env);
Cheers,
Paul.
Indeed it would! I shall submit a vastly simplified retry, accordingly. :)
--
Thanks,
Andy.
James Hawkins wrote:
Please don't check env for NULL; RegCloseKey will just fail harmlessly
if env is NULL. We spent a lot of time removing such checks.
OK, I shall re-post my first effort as Try 3.
--
Andy.
Hi,
In ole32/ifs.c:RemoveMemoryLocation(), should the parameter be a LPVOID *,
or should it be just a LPVOID (or LPCVOID, to be more precise)? I want to
constify it, but I'm uncertain if its current depth of indirection is
correct.
Thanks,
--
Andy.
Rob Shearman wrote:
-static OLEFontImpl* OLEFontImpl_Construct(LPFONTDESC fontDesc);
+static OLEFontImpl* OLEFontImpl_Construct(const FONTDESC *fontDesc);
static void OLEFontImpl_Destroy(OLEFontImpl* fontDesc);
static ULONGWINAPI OLEFontImpl_AddRef(IFont* iface);
Even if
Rob Shearman wrote:
-static OLEFontImpl* OLEFontImpl_Construct(LPFONTDESC fontDesc);
+static OLEFontImpl* OLEFontImpl_Construct(const FONTDESC *fontDesc);
static void OLEFontImpl_Destroy(OLEFontImpl* fontDesc);
static ULONG WINAPI OLEFontImpl_AddRef(IFont* iface);
Even if the compiler allows
Misha Koshelev wrote:
On a more stylistic note, any reason for all these single line if
statements that have their contents enclosed in {}'s? (i.e., instead of:
if (a) {
call_b();
}
why not just:
if (a)
call_b();
If anything, this adds one unnecessary line with the single }
Yes. It seems that the corresponding MSDN web page is out of step.
--
Andy.
Michael Stefaniuc wrote:
Jacek,
I'm not sure about this patch. gcc 3.1.1 produced a warning about a
double const. The rules of what is const depending on where in the
declaration it is placed are mind bongling (especially at 1am) and I
don't know what the intention was here so please
Andrew Talbot wrote:
So, in case anyone is still awake and interested:
static const REFIID tid_ids[];
is equivalent to
static const GUID *const const tid_ids[]; (Note the erroneous double
const.)
or
static GUID const *const const tid_ids[];
as I would prefer to put
Kuba Ober wrote:
You calculating center wrong:
+ ret = (props-lMax-props-lMin)/2;
This won't work for min=1000 max=2000.
But it does. Maybe you meant if min/max were switched? In such case
ret = (props-lMax-props-lMin)/2;
if (props-lMax props-lMin) ret = -ret;
Cheers, Kuba
If
1 - 100 of 233 matches
Mail list logo
