Hi Jacek,
no I don't mind at all. The reason I comment on this thread is a
recent report about issues with current master's direct-x support. it
might be related to this.
Are you aware of this report?
Cheers,
Kai
2015-08-18 12:47 GMT+02:00 Jacek Caban ja...@codeweavers.com:
On 08/17/15
On Tue, Aug 11, 2015 at 6:22 AM, Jacek Caban ja...@codeweavers.com wrote:
The patch looks good to me.
I think it's good too, but it looks like it (intsafe_2.2.1.patch)
hasn't been committed to the git repository. Can someone commit it?
--David
Hi David,
On 08/10/15 18:11, David Grayson wrote:
Here is a quick summary of the remaining possible compatibility issues
between our version and the PSDK version of intsafe.h:
- We include wtypesbase.h to define our types
- Our error result is always 0, they use ~0.
- They have some
On 8/10/2015 3:34 AM, Jacek Caban wrote:
I'm sorry for the delay, I was sure I already replied.
That's fine, I'm not paying you. :-)
We use #ifndef guards all over the place. PSDK headers usually use both.
That's find to add the pragma, but please don't delete existing guards.
OK, I have
On Mon, Aug 10, 2015 at 7:34 AM, Jacek Caban ja...@codeweavers.com wrote:
Hi David,
I'm sorry for the delay, I was sure I already replied. The patch looks
mostly good and ready to be committed IMO. There is one minor thing:
-#ifndef _INTSAFE_H_INCLUDED_
-#define _INTSAFE_H_INCLUDED_
Hi David,
On 08/04/15 18:37, David Grayson wrote:
On 8/4/2015 9:02 AM, David Grayson wrote:
Thanks, Jacek. I have included a new patch with all of your
suggestions (version 2.1.0). As always, it's in the public domain.
Please ignore the last patch. Here is a new one (2.2.0) that includes
On 08/03/15 19:08, David Grayson wrote:
8) Even with FORCEINLINE, you still sometimes need to have a non-inline
definition of the function available, for example if you are doing any
operations on a function pointer to one of the intsafe.h functions. (Or is
that not something a user should
On 8/4/2015 9:02 AM, David Grayson wrote:
Thanks, Jacek. I have included a new patch with all of your suggestions
(version 2.1.0). As always, it's in the public domain.
Please ignore the last patch. Here is a new one (2.2.0) that includes 79 (!)
more conversion functions I just discovered
Thanks, Jacek. I have included a new patch with all of your suggestions
(version 2.1.0). As always, it's in the public domain.
On 8/4/2015 3:48 AM, Jacek Caban wrote:
I'd personally call build system that mixes char types as broken, but
it's valid so we can support it. How about simply using
Hi David,
That's a nice work, thanks!
On 08/02/15 21:17, David Grayson wrote:
Hello. Attached is version 2.0.0 of the patch, which is very
different and only supports GCC 5 and above, because it uses new
built-in functions. This version is only 331 lines long (down from
~1600). It is easy
Thanks for your contribution. I would like to see Jacek's comment on this
before it gets applied.
Kai
Am 02.08.2015 05:57 schrieb David Grayson davidegray...@gmail.com:
Hello. Attached is a patch that adds a complete implementation of
intsafe.h that I generated and tested using Ruby. It
Thank you, Kai.
Before Jacek or anyone spends too much time checking my
add/subtract/multiply operations, please note that I just learned
about GCC's integer overflow built-ins, and I will be rewriting the
math operations to use those and submitting a new version of this
patch:
Hello. Attached is version 2.0.0 of the patch, which is very different and
only supports GCC 5 and above, because it uses new built-in functions. This
version is only 331 lines long (down from ~1600). It is easy for anyone to
check it because it makes no assumptions about the sizes,
Hello. Attached is a patch that adds a complete implementation of intsafe.h
that I generated and tested using Ruby. It would be great if someone could
merge it in.
The version of intsafe.h included in this patch can also be viewed here:
14 matches
Mail list logo
