I think you've gone about this in the right way, but need to handle the
various cases a bit more broadly. Specifically, you can't assume that
everyone has strerror() at all (Solaris 8 doesn't, for example) nor that
everyone who uses int strerror_r() will also define either _XOPEN_SOURCE
or _PO
chromatic via RT wrote:
On Monday 15 September 2008 23:21:26 Christoph Otto wrote:
--- src/pmc/os.pmc (revision 31173)
+++ src/pmc/os.pmc (working copy)
@@ -31,9 +31,6 @@
#include "parrot/parrot.h"
-/* XXX Check if we need to deallocate strerror strings */
-/* XXX apparently, strer
After looking around Parrot and realizing that there were several other places
where strerror is used, I'm trying a different approach. The attached patch
adds config/gen/platform/generic/strerror.c, which contains a new function
Parrot_strerror. This is just a wrapper to abstract away the non
Will Coleda via RT wrote:
On Tue Jul 22 23:34:13 2008, [EMAIL PROTECTED] wrote:
Christoph Otto via RT wrote:
This version of the patch should dtrt with all versions of
strerror_r. It
works on my Debian/x86 box and I'll be testing it on any *nix I can
get my
hands on Tuesday. If it works f
Christoph Otto via RT wrote:
This version of the patch should dtrt with all versions of strerror_r. It
works on my Debian/x86 box and I'll be testing it on any *nix I can get my
hands on Tuesday. If it works fine there, if someone can test it on windows
and if the patch looks OK, I'll commi
Andy Dougherty via RT wrote:
On Thu, 17 Jul 2008, Christoph Otto via RT wrote:
On Thu Jul 17 15:53:12 2008, julianalbo wrote:
On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
trick. The attached patch (v5) properly fixes the problem on my system.
There shou
On Thu, 17 Jul 2008, Christoph Otto via RT wrote:
> On Thu Jul 17 15:53:12 2008, julianalbo wrote:
> > On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
> > <[EMAIL PROTECTED]> wrote:
> >
> trick. The attached patch (v5) properly fixes the problem on my system.
> There shouldn't be any rem
On Thu, Jul 17, 2008 at 7:44 PM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
> On Thu Jul 17 15:53:12 2008, julianalbo wrote:
>> On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
>> <[EMAIL PROTECTED]> wrote:
>>
>> > With this patch, the new tests still pass on Linux/x86. The patch uses
On Thursday 17 July 2008 15:44:36 NotFound wrote:
> <[EMAIL PROTECTED]> wrote:
> > With this patch, the new tests still pass on Linux/x86. The patch uses
> > STRING->strstart to avoid leaking a malloc'd buffer when throwing an
> > exception, which may or may not be considered kosher in this situa
On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT
<[EMAIL PROTECTED]> wrote:
> With this patch, the new tests still pass on Linux/x86. The patch uses
> STRING->strstart to avoid leaking a malloc'd buffer when throwing an
> exception, which may or may not be considered kosher in this situatio
On Nov 28, 2007, at 1:29 AM, Joe Sadusk via RT wrote:
Heh, ok, grammar fixed and resubmitted. And yes, I've tested it on
Linux (Fedora 7) and Windows with MSVC 2005. I don't have a non-glibc
unix to try it out with however.
Joe
On Mon Nov 26 09:50:28 2007, [EMAIL PROTECTED] wrote:
On Sunda
On Sunday 25 November 2007 21:48:01 Joe Sadusk via RT wrote:
> Ok, here's try two. Platform specific stuff has been moved into
> config/gen/platform, and non-win32 platforms use strerror_r directly.
Change "its" to "it's" in the comment before #define ERRBUF_SIZE and this
patch looks reasonable
On Nov 22, 2007 9:03 PM, Joe Sadusk via RT
<[EMAIL PROTECTED]> wrote:
> Reposting this because this is my first patch, and it didn't occur to me
> that if I don't CC perl6-internals, no one would notice it.
>
> It turns out that strerror_r is POSIX only, and windows has the slightly
> different str
13 matches
Mail list logo
