James Gallagher <[EMAIL PROTECTED]> writes:
> I've found what appears to be a stack corruption when using regexec()
> on a PPC Mac running OS/X 10.3.9. I was wondering if this is a known
> problem?
I don't know of any such problem. Looks like you may have to debug it.
> After the call to regexe
I've found what appears to be a stack corruption when using regexec()
on a PPC Mac running OS/X 10.3.9. I was wondering if this is a known
problem? Or maybe just an obvious goof on my part???
I am calling regexec() using:
int result = regexec(&d_preg, ss.substr(pos, len).c_str(), 1,
pmat
>> With glibc, if p is not null, realloc (p, 0) always returns NULL.
>
> And free's p, presumably?
Yes.
> The glibc behaviour here seems like something we shouldn't encourage
> IMHO.
Ah, then we probably shouldn't document it either. (:-)
Here's the updated module. Note the slight documentation change since
my e-mail to Bruno.
Index: lib/read-file.c
===
RCS file: lib/read-file.c
diff -N lib/read-file.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ lib/read-file.c
Bruno Haible <[EMAIL PROTECTED]> writes:
> Simon Josefsson wrote:
>> Here's the module. Only lighted tested, mostly to get feedback on the
>> approach, but if you agree with it, detailed review would be useful.
>
> Looks already quite good. Only minor nits:
>
>> +/* Read a STREAM and return a new
Simon Josefsson wrote:
> Here's the module. Only lighted tested, mostly to get feedback on the
> approach, but if you agree with it, detailed review would be useful.
Looks already quite good. Only minor nits:
> +/* Read a STREAM and return a newly allocated string with the content,
> + and set
Paul Eggert <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> What about this instead?
>
> Unfortunately that is buggy too, if the goal is to emulate glibc.
> With glibc, if p is not null, realloc (p, 0) always returns NULL.
And free's p, presumably?
> Conversely, re
Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> * Paul Eggert wrote on Thu, Jun 01, 2006 at 10:20:58AM CEST:
>> Simon Josefsson <[EMAIL PROTECTED]> writes:
>>
>> > What about realloc (NULL, ...)?
>>
>> In practice that is as portable as free (NULL). They were
>> standardized at the same time.
>
>
Simon Josefsson <[EMAIL PROTECTED]> writes:
> What about this instead?
Unfortunately that is buggy too, if the goal is to emulate glibc.
With glibc, if p is not null, realloc (p, 0) always returns NULL.
Conversely, realloc (NULL, 0) is equivalent to malloc (0) and
typically returns non-NULL. It
* Paul Eggert wrote on Thu, Jun 01, 2006 at 10:20:58AM CEST:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
> > What about realloc (NULL, ...)?
>
> In practice that is as portable as free (NULL). They were
> standardized at the same time.
Well, with the difference being here that realloc, simi
Simon Josefsson <[EMAIL PROTECTED]> writes:
> What about realloc (NULL, ...)?
In practice that is as portable as free (NULL). They were
standardized at the same time.
For read-file, I looked at realloc, and can't help but feel it is
buggy. Here is the function:
void *
rpl_realloc (void *p, size_t n)
{
if (n == 0)
{
n = 1;
/* In theory realloc might fail, so don't rely on it to free. */
free (p);
p = NULL;
}
if (p == NULL)
Paul Eggert <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> I think we should be able to assume free (NULL) works though
>
> Yes. To my knowledge the last major system for which the 'free'
> module was needed was SunOS 4.1.4 aka Solaris 1.1.2. Sun stopped
> patchin
13 matches
Mail list logo
