Omair Majid wrote:
:
It looks like this patch still has not been applied to OpenJDK7. I have prepared
a webrev that updates this patch so it applies cleanly:
http://cr.openjdk.java.net/~omajid/webrevs/stack-overflow-ParserLocale/01/
I would appreciate it if someone could take a quick look. I
On 05/18/2011 09:56 AM, Alan Bateman wrote:
Omair Majid wrote:
:
It looks like this patch still has not been applied to OpenJDK7. I
have prepared
a webrev that updates this patch so it applies cleanly:
http://cr.openjdk.java.net/~omajid/webrevs/stack-overflow-ParserLocale/01/
I would
Andrew Haley wrote:
Xueming Shen wrote:
Andrew Haley wrote:
}
if (mapLookup(locale_aliases, temp, p)) {
-strcpy(temp, p);
+temp = realloc(temp, strlen(p)+1);
+if (temp == NULL) {
+
Xueming Shen wrote:
Andrew Haley wrote:
}
if (mapLookup(locale_aliases, temp, p)) {
-strcpy(temp, p);
+temp = realloc(temp, strlen(p)+1);
+if (temp == NULL) {
+JNU_ThrowOutOfMemoryError(env,
Andrew Haley wrote:
Xueming Shen wrote:
Andrew Haley wrote:
}
if (mapLookup(locale_aliases, temp, p)) {
-strcpy(temp, p);
+temp = realloc(temp, strlen(p)+1);
+if (temp == NULL) {
+
https://bugs.openjdk.java.net/show_bug.cgi?id=100057
GetJavaProperties has a stack-allocated fixed size buffer for holding a copy of
a string returned by setlocale(3). However, there is no guarantee that the
string will fit into this buffer.
This one is probably due to Solaris code being reused
Hi Andrew,
If you use malloc then you have to check for a NULL return and deal with
the error possibility.
Alternatively use strncpy to make sure it's safe and continue to assume
that it will be big enough.
Cheers,
David Holmes
Andrew Haley said the following on 05/22/09 21:10:
Andrew Haley wrote:
https://bugs.openjdk.java.net/show_bug.cgi?id=100057
GetJavaProperties has a stack-allocated fixed size buffer for holding a copy of
a string returned by setlocale(3). However, there is no guarantee that the
string will fit into this buffer.
This one is probably due to
David Holmes - Sun Microsystems wrote:
If you use malloc then you have to check for a NULL return and deal with
the error possibility.
Alternatively use strncpy to make sure it's safe and continue to assume
that it will be big enough.
It's just following the style used throughout that
Andrew Haley said the following on 05/22/09 21:45:
David Holmes - Sun Microsystems wrote:
If you use malloc then you have to check for a NULL return and deal with
the error possibility.
Alternatively use strncpy to make sure it's safe and continue to assume
that it will be big enough.
It's
Andrew Haley wrote:
:
OK. I'll check for the NULL, then. If I have to change the patch that's
been in IcedTea for ages then I'll use strdup instead of malloc. But what
is one supposed to do if the allocation fails? Simply emit an error
message to stderr and call abort() ?
David Holmes - Sun Microsystems wrote:
If you use malloc then you have to check for a NULL return and deal with
the error possibility.
Alternatively use strncpy to make sure it's safe and continue to assume
that it will be big enough.
I'm working on fixing this properly, but I just came
Alan Bateman wrote:
Andrew Haley wrote:
https://bugs.openjdk.java.net/show_bug.cgi?id=100057
GetJavaProperties has a stack-allocated fixed size buffer for holding
a copy of
a string returned by setlocale(3). However, there is no guarantee
that the
string will fit into this buffer.
This
Andrew Haley wrote:
:
I've reworked the patch.
I tried to refactor the code to make it cleaner and easier to follow,
but I ended up touching so many places that it bacame a major change,
and there's no way I could possibly test it all, especially the special
cases for Solaris.
So, I backed off
Alan Bateman wrote:
Andrew Haley wrote:
:
I've reworked the patch.
I tried to refactor the code to make it cleaner and easier to follow,
but I ended up touching so many places that it bacame a major change,
and there's no way I could possibly test it all, especially the special
cases for
Andrew Haley wrote:
:
Yes, you're right. :-(
I reworked this silly patch so many times that I couldn't see it any
more. As you say, encoding_variant needs to be at least the size of temp.
Thanks for perseveringly with it. The latest patch looks good to me.
-Alan.
16 matches
Mail list logo
