* [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
@ 2015-05-13 8:51 Iain Buclaw
2015-05-14 13:01 ` Jeff Law
0 siblings, 1 reply; 6+ messages in thread
From: Iain Buclaw @ 2015-05-13 8:51 UTC (permalink / raw)
To: gcc-patches, Ian Lance Taylor
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
If a symbol that has so far been valid abruptly ends then we will want
to fail the process rather than silently succeed.
---
libiberty/ChangeLog
2015-05-13 Iain Buclaw <ibuclaw@gdcproject.org>
* d-demangle.c (dlang_call_convention): Return NULL if have reached the
end of the symbol, but expected more.
(dlang_attributes): Likewise.
(dlang_function_type): Likewise.
(dlang_type): Likewise.
(dlang_identifier): Likewise.
(dlang_value): Likewise.
[-- Attachment #2: 0002-D-demangle-Fail-early-on-bad-symbols.patch --]
[-- Type: text/x-diff, Size: 1845 bytes --]
From e9806a182f8296d92a99d842edab6a4c29124eb1 Mon Sep 17 00:00:00 2001
From: Iain Buclaw <ibuclaw@gdcproject.org>
Date: Wed, 13 May 2015 08:50:55 +0200
Subject: [PATCH 2/7] D demangle: Fail early on bad symbols
---
libiberty/d-demangle.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libiberty/d-demangle.c b/libiberty/d-demangle.c
index fa01767..91c6d55 100644
--- a/libiberty/d-demangle.c
+++ b/libiberty/d-demangle.c
@@ -185,7 +185,7 @@ static const char *
dlang_call_convention (string *decl, const char *mangled)
{
if (mangled == NULL || *mangled == '\0')
- return mangled;
+ return NULL;
switch (*mangled)
{
@@ -221,7 +221,7 @@ static const char *
dlang_attributes (string *decl, const char *mangled)
{
if (mangled == NULL || *mangled == '\0')
- return mangled;
+ return NULL;
while (*mangled == 'N')
{
@@ -280,7 +280,7 @@ dlang_function_type (string *decl, const char *mangled)
size_t szattr, szargs, sztype;
if (mangled == NULL || *mangled == '\0')
- return mangled;
+ return NULL;
/* The order of the mangled string is:
CallConvention FuncAttrs Arguments ArgClose Type
@@ -380,7 +380,7 @@ static const char *
dlang_type (string *decl, const char *mangled)
{
if (mangled == NULL || *mangled == '\0')
- return mangled;
+ return NULL;
switch (*mangled)
{
@@ -600,7 +600,7 @@ static const char *
dlang_identifier (string *decl, const char *mangled)
{
if (mangled == NULL || *mangled == '\0')
- return mangled;
+ return NULL;
if (ISDIGIT (*mangled))
{
@@ -1061,7 +1061,7 @@ static const char *
dlang_value (string *decl, const char *mangled, const char *name, char type)
{
if (mangled == NULL || *mangled == '\0')
- return mangled;
+ return NULL;
switch (*mangled)
{
--
2.1.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
2015-05-13 8:51 [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string Iain Buclaw
@ 2015-05-14 13:01 ` Jeff Law
2015-05-14 13:47 ` Iain Buclaw
0 siblings, 1 reply; 6+ messages in thread
From: Jeff Law @ 2015-05-14 13:01 UTC (permalink / raw)
To: Iain Buclaw, gcc-patches, Ian Lance Taylor
On 05/13/2015 02:51 AM, Iain Buclaw wrote:
> If a symbol that has so far been valid abruptly ends then we will want
> to fail the process rather than silently succeed.
>
> ---
> libiberty/ChangeLog
>
> 2015-05-13 Iain Buclaw <ibuclaw@gdcproject.org>
>
> * d-demangle.c (dlang_call_convention): Return NULL if have reached the
> end of the symbol, but expected more.
> (dlang_attributes): Likewise.
> (dlang_function_type): Likewise.
> (dlang_type): Likewise.
> (dlang_identifier): Likewise.
> (dlang_value): Likewise.
I spot checked various callers of these functions that not return NULL
and they looked reasonable. Though I was a bit concerned about the
callers of dlang_type, dlang_value and dlang_identifier.
In those cases we'll often still do the string_append, string_setlength
and other calls in the caller of dlang_{value,type,identifier}. I'm
assuming that's safe (the error still appears to be bubbling up properly).
If you can confirm that we're OK in those cases, then this is OK for the
trunk.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
2015-05-14 13:01 ` Jeff Law
@ 2015-05-14 13:47 ` Iain Buclaw
2015-05-14 15:05 ` Jeff Law
0 siblings, 1 reply; 6+ messages in thread
From: Iain Buclaw @ 2015-05-14 13:47 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches, Ian Lance Taylor
On 14 May 2015 at 14:58, Jeff Law <law@redhat.com> wrote:
> On 05/13/2015 02:51 AM, Iain Buclaw wrote:
>>
>> If a symbol that has so far been valid abruptly ends then we will want
>> to fail the process rather than silently succeed.
>>
>> ---
>> libiberty/ChangeLog
>>
>> 2015-05-13 Iain Buclaw <ibuclaw@gdcproject.org>
>>
>> * d-demangle.c (dlang_call_convention): Return NULL if have reached
>> the
>> end of the symbol, but expected more.
>> (dlang_attributes): Likewise.
>> (dlang_function_type): Likewise.
>> (dlang_type): Likewise.
>> (dlang_identifier): Likewise.
>> (dlang_value): Likewise.
>
> I spot checked various callers of these functions that not return NULL and
> they looked reasonable. Though I was a bit concerned about the callers of
> dlang_type, dlang_value and dlang_identifier.
>
> In those cases we'll often still do the string_append, string_setlength and
> other calls in the caller of dlang_{value,type,identifier}. I'm assuming
> that's safe (the error still appears to be bubbling up properly).
>
The string routines should be safe for that (appending a string with a
zero length does nothing, for instance).
> If you can confirm that we're OK in those cases, then this is OK for the
> trunk.
>
I can start fuzzing mangle strings to test that failures actually fail
gracefully. There's already a fuzzer that exists for C++, I think the
only change that would be required for D is exchanging "_Z" for "_D"
and calling cplus_demangle with DMGL_DLANG.
Regards
Iain
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
2015-05-14 13:47 ` Iain Buclaw
@ 2015-05-14 15:05 ` Jeff Law
2015-05-14 19:25 ` Iain Buclaw
0 siblings, 1 reply; 6+ messages in thread
From: Jeff Law @ 2015-05-14 15:05 UTC (permalink / raw)
To: Iain Buclaw; +Cc: gcc-patches, Ian Lance Taylor
On 05/14/2015 07:36 AM, Iain Buclaw wrote:
> On 14 May 2015 at 14:58, Jeff Law <law@redhat.com> wrote:
>> On 05/13/2015 02:51 AM, Iain Buclaw wrote:
>>>
>>> If a symbol that has so far been valid abruptly ends then we will want
>>> to fail the process rather than silently succeed.
>>>
>>> ---
>>> libiberty/ChangeLog
>>>
>>> 2015-05-13 Iain Buclaw <ibuclaw@gdcproject.org>
>>>
>>> * d-demangle.c (dlang_call_convention): Return NULL if have reached
>>> the
>>> end of the symbol, but expected more.
>>> (dlang_attributes): Likewise.
>>> (dlang_function_type): Likewise.
>>> (dlang_type): Likewise.
>>> (dlang_identifier): Likewise.
>>> (dlang_value): Likewise.
>>
>> I spot checked various callers of these functions that not return NULL and
>> they looked reasonable. Though I was a bit concerned about the callers of
>> dlang_type, dlang_value and dlang_identifier.
>>
>> In those cases we'll often still do the string_append, string_setlength and
>> other calls in the caller of dlang_{value,type,identifier}. I'm assuming
>> that's safe (the error still appears to be bubbling up properly).
>>
>
> The string routines should be safe for that (appending a string with a
> zero length does nothing, for instance).
>
>> If you can confirm that we're OK in those cases, then this is OK for the
>> trunk.
>>
>
> I can start fuzzing mangle strings to test that failures actually fail
> gracefully. There's already a fuzzer that exists for C++, I think the
> only change that would be required for D is exchanging "_Z" for "_D"
> and calling cplus_demangle with DMGL_DLANG.
Your call whether to fuzz before or after committing the changes.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
2015-05-14 15:05 ` Jeff Law
@ 2015-05-14 19:25 ` Iain Buclaw
2015-05-14 20:42 ` Jeff Law
0 siblings, 1 reply; 6+ messages in thread
From: Iain Buclaw @ 2015-05-14 19:25 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc-patches, Ian Lance Taylor
On 14 May 2015 at 16:51, Jeff Law <law@redhat.com> wrote:
> On 05/14/2015 07:36 AM, Iain Buclaw wrote:
>>
>> On 14 May 2015 at 14:58, Jeff Law <law@redhat.com> wrote:
>>>
>>> On 05/13/2015 02:51 AM, Iain Buclaw wrote:
>>>>
>>>>
>>>> If a symbol that has so far been valid abruptly ends then we will want
>>>> to fail the process rather than silently succeed.
>>>>
>>>> ---
>>>> libiberty/ChangeLog
>>>>
>>>> 2015-05-13 Iain Buclaw <ibuclaw@gdcproject.org>
>>>>
>>>> * d-demangle.c (dlang_call_convention): Return NULL if have
>>>> reached
>>>> the
>>>> end of the symbol, but expected more.
>>>> (dlang_attributes): Likewise.
>>>> (dlang_function_type): Likewise.
>>>> (dlang_type): Likewise.
>>>> (dlang_identifier): Likewise.
>>>> (dlang_value): Likewise.
>>>
>>>
>>> I spot checked various callers of these functions that not return NULL
>>> and
>>> they looked reasonable. Though I was a bit concerned about the callers of
>>> dlang_type, dlang_value and dlang_identifier.
>>>
>>> In those cases we'll often still do the string_append, string_setlength
>>> and
>>> other calls in the caller of dlang_{value,type,identifier}. I'm assuming
>>> that's safe (the error still appears to be bubbling up properly).
>>>
>>
>> The string routines should be safe for that (appending a string with a
>> zero length does nothing, for instance).
>>
>>> If you can confirm that we're OK in those cases, then this is OK for the
>>> trunk.
>>>
>>
>> I can start fuzzing mangle strings to test that failures actually fail
>> gracefully. There's already a fuzzer that exists for C++, I think the
>> only change that would be required for D is exchanging "_Z" for "_D"
>> and calling cplus_demangle with DMGL_DLANG.
>
> Your call whether to fuzz before or after committing the changes.
>
> jeff
Iant commited in the changes first time around. I don't have write
after approval access in GCC just yet, probably should go about
getting that sorted out if this is to become a regular thing. I dealt
with copyright assignments back in September.
Iain.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string
2015-05-14 19:25 ` Iain Buclaw
@ 2015-05-14 20:42 ` Jeff Law
0 siblings, 0 replies; 6+ messages in thread
From: Jeff Law @ 2015-05-14 20:42 UTC (permalink / raw)
To: Iain Buclaw; +Cc: gcc-patches, Ian Lance Taylor
On 05/14/2015 01:15 PM, Iain Buclaw wrote:
> Iant commited in the changes first time around. I don't have write
> after approval access in GCC just yet, probably should go about
> getting that sorted out if this is to become a regular thing. I dealt
> with copyright assignments back in September.
Yea, let's get write access sorted out. I don't mind occasionally
committing changes for random contributors, but you're around here
enough that you should just have access.
See authenticated access on this page:
https://gcc.gnu.org/svnwrite.html
List me as your sponsor :-)
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-05-14 20:06 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-13 8:51 [PATCH 2/7] [D] libiberty: Fail if reached end of symbol string Iain Buclaw
2015-05-14 13:01 ` Jeff Law
2015-05-14 13:47 ` Iain Buclaw
2015-05-14 15:05 ` Jeff Law
2015-05-14 19:25 ` Iain Buclaw
2015-05-14 20:42 ` Jeff Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).