Re: The "-W|--wide" option?

[Carlos O'Donell <carlos_odonell at mentor dot com>]

On 9/27/2011 5:20 AM, Nick Clifton wrote:
>> However, without a clear statement about *what* to do with long
>> lines, the correct fix is unclear.
> 
> Hmm, OK, then how about this:
> 
> When do_wide is *not* enabled and an output line would pass the 80th
> column then it must either be wrapped, truncated or abbreviated.

OK.

> For preference the output should be abbreviated.  Failing that
> truncation should be used.  If however the output is part of a new
> feature and truncation would likely hinder its comprehension then
> wrapping should be employed.  The intention here is that without
> --wide specified the output should be short and concise, not long and
> wordy.

Just to be clear wrapping includes word wrapping and line 
breaking?

> If the output is wrapped, then some clear indication should be given
> that wrapping has occurred.  If the output is abbreviated then a
> description of the abbreviation(s) used should be included, either in
> the output or the documentation or both.  If the output is truncated
> then it should be possible for a user, under reasonable 
> circumstances, to tell that truncation has occurred.
 
OK.

>> How strict are we going to be? Must this code remain as-is?
> 
> No.  In my opinion this is a bug, and the output should be truncated
> to 80 characters.  Consumers that rely upon finding the full filename
> should be invoking readelf with the --wide option enabled.  Failure
> to do this means that they should expect to see truncated filenames.

OK.
 
> Essentially the purpose of -W is to prevent truncation, usually of
> filenames or function names.  Tools that use the output from readelf
> must decide if they want full or truncated names and invoke the tool
> appropriately.

Thanks, I appreciate your input Nick.

We'll put together a patch to fix this.

Cheers,
Carlos.
-- 
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos@codesourcery.com
+1 (613) 963 1026