Re: [Bug default/19434] invalid character in attribute value

Re: [Bug default/19434] invalid character in attribute value

[Dodji Seketeli]

> Is dropping the name on the floor the best thing to do? Wouldn't it be
> better to encode the non-ascii parameter name into 7b clean ascii sort
> of like uuencode does.

For now, we don't use the parameter name anyway.  In change reports,
function parameters are referred to using their position.

Furthermore, I think that since we don't know the actual encoding of the
characters, if we are sure they are not ASCII (which is the case here),
I don't think trying to encode each of the byte value can provide us
with any usable information.  It's just like if we had garbage.  We
won't be able to show any useable information to the user anyway.  Hence
my inclination to drop the name altogether.

But if one day we know the actual encoding of the parameter names, then
we can decode them.  At that point we'll change the code again and avoid
dropping the name if it's not ascii.  If it's, say, UTF-8, then we'll be
able to decode the byte stream, knowing that it's an UTF-8 stream.

-- 
		Dodji

[Bug default/19434] invalid character in attribute value

[woodard at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19434

--- Comment #1 from Ben Woodard <woodard at redhat dot com> ---
Created attachment 8886
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8886&action=edit
reproducing elf file

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/19434] invalid character in attribute value

[dodji at seketeli dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=19434

--- Comment #5 from dodji at seketeli dot org ---
> Is dropping the name on the floor the best thing to do? Wouldn't it be
> better to encode the non-ascii parameter name into 7b clean ascii sort
> of like uuencode does.

For now, we don't use the parameter name anyway.  In change reports,
function parameters are referred to using their position.

Furthermore, I think that since we don't know the actual encoding of the
characters, if we are sure they are not ASCII (which is the case here),
I don't think trying to encode each of the byte value can provide us
with any usable information.  It's just like if we had garbage.  We
won't be able to show any useable information to the user anyway.  Hence
my inclination to drop the name altogether.

But if one day we know the actual encoding of the parameter names, then
we can decode them.  At that point we'll change the code again and avoid
dropping the name if it's not ascii.  If it's, say, UTF-8, then we'll be
able to decode the byte stream, knowing that it's an UTF-8 stream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/19434] invalid character in attribute value

[woodard at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19434

--- Comment #4 from Ben Woodard <woodard at redhat dot com> ---
Is dropping the name on the floor the best thing to do? Wouldn't it be better
to encode the non-ascii parameter name into 7b clean ascii sort of like
uuencode does.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/19434] New: invalid character in attribute value

[woodard at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19434

            Bug ID: 19434
           Summary: invalid character in attribute value
           Product: libabigail
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: default
          Assignee: dodji at redhat dot com
          Reporter: woodard at redhat dot com
                CC: libabigail at sourceware dot org
  Target Milestone: ---

bash-4.1$ ~/bin/abidw --abidiff
/collab/usr/global/tools/totalview/r/toolworks/totalview.8.12.0-1/linux-x86-64/bin/tvdsvrmain_mic 
/tmp/libabigail-tmp-file-HC4EVK:21019: parser error : invalid character in
attribute value
      <parameter type-id='type-id-481' name='$5'/>
                                              ^
/tmp/libabigail-tmp-file-HC4EVK:21019: parser error : attributes construct
error
      <parameter type-id='type-id-481' name='$5'/>
                                              ^
/tmp/libabigail-tmp-file-HC4EVK:21019: parser error : Couldn't find end of
Start Tag parameter
      <parameter type-id='type-id-481' name='$5'/>
                                              ^
Could not read temporary XML representation of elf file back

This looks like it is a new one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/19434] invalid character in attribute value

[woodard at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19434

--- Comment #2 from Ben Woodard <woodard at redhat dot com> ---
This was with 1.0 RC1 from the git tree.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/19434] invalid character in attribute value

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19434

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug default/19434] invalid character in attribute value

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19434

dodji at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #3 from dodji at redhat dot com ---
So this is due to some function parameter names which contain ASCII *control*
characters.  I am not sure why this would happen.  Maybe this is because the
source code file was encoded in something that is not proper ASCII? 
Unfortunately, I am not aware of any way to detect the encoding of the source
file, from the DWARF information; so I am assuming it should be ASCII.

The fix involves detecting characters that are not simple ASCII identifier
characters in parameter names.  If there is any, the parameter name is dropped
on the floor.

The fix has landed into the master branch at
https://sourceware.org/git/?p=libabigail.git;a=commit;h=c3869ecc7bbd6f8370ca29446afdcc1d2631e33d.

-- 
You are receiving this mail because:
You are on the CC list for the bug.