Hi Kai,
No, I'm not aware of the report. I can't see it in our bug tracker,
where can I find it?
Cheers,
Jacek
On 08/29/15 17:16, Kai Tietz wrote:
> 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
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 :
> On 08/17/15 20:20, David Grayson wrot
On 08/17/15 20:20, David Grayson wrote:
> On Tue, Aug 11, 2015 at 6:22 AM, Jacek Caban 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?
Sorry for the delay, I was hoping
Thanks, Jon! If you want to add warn_unused_result, that seems fine
to me. --David
On Mon, Aug 17, 2015 at 3:57 PM, JonY wrote:
> On 8/18/2015 02:20, David Grayson wrote:
>> On Tue, Aug 11, 2015 at 6:22 AM, Jacek Caban wrote:
>>> The patch looks good to me.
>>
>> I think it's good too, but it
On 8/18/2015 02:20, David Grayson wrote:
> On Tue, Aug 11, 2015 at 6:22 AM, Jacek Caban 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?
>
Does it make sense to add
On Tue, Aug 11, 2015 at 6:22 AM, Jacek Caban 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 un
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 a
On Mon, Aug 10, 2015 at 7:34 AM, Jacek Caban 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_
> +#pragma once
>
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 inc
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
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 sho
Hello, Jacek. Thanks for taking a look at my patch!
1) I will add "#if __GNUC__ >= 5" around the parts that use the new built-ins.
2) I'll remove the change to limits.h
3) I'll remove the link to my GitHub; I was hoping people would use my script
to regenerate the header but it's fine if they
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 e
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, signedne
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:
https://gcc.gnu.or
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" :
> 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
> some
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:
https://github.com/DavidEGrayson/intsafe/blob/1.1.0/gen
19 matches
Mail list logo
