Re: PATCH RFA: Permit objcopy -add-section to work with /dev/null

[Ian Lance Taylor <iant at google dot com>]

Nick Clifton <nickc@redhat.com> writes:

>> +	    /* We don't use get_file_size so that we can do
>> +	         --add-section .note.GNU_stack=/dev/null
>> +	       get_file_size doesn't work on /dev/null.  */
>
> You know this worries me a bit.  If we do not check for ordinary files
> then the user could be tripped up if they accidentally specify some
> special file.  Apart from /dev/null I cannot think of any other file
> that they might reasonably want to use.
>
> Plus you are using /dev/null as a shorthand for creating an empty file
> and referring to that.  Maybe it would just be simpler to enhance the
> --add-section option so that if no filename is specified an empty
> section is created.  Ie:
>
>   --add-section .note.GNU_stack
>
> creates an empty .note.GNU_stack section and:
>
>   --add-section .note.GNU_stack=foo.note
>
> creates a .note.GNU_stack section containing a copy of the contents of
> the foo.note file.

I will do that if you like but I don't agree with your reasoning.  One
of the strengths of Unix is that it presents a unified namespace which
covers a number of different data sources.  All objcopy wants is a
sequence of bytes, and that can come from anywhere.  I don't see why
anybody would ever want to use --add-section with /dev/stdin or with a
named pipe, but I also don't see why objcopy should reject that.
Working with different file types is a feature, not a bug.  Rejecting
file types which can work is a bug, not a feature.  We can protect the
user from things that are clearly wrong, but we should not protect the
user from doing something that is not clearly wrong merely because we
don't have the imagination to see that it could potentially be right.


>> First, it fails because objcopy silently fails when --add-section is
>> used with a zero length file:
>>
>> 	    size = get_file_size (s + 1);
>> 	    if (size < 1)
>> 	      {
>> 		status = 1;
>> 		break;
>> 	      }
>>
>> That just seems like an obvious bug.
>
> Well I would agree that the silently failing is a bug.  Generating a
> warning message but continuing would probably be a more appropriate
> action.

Silently failing was a bug, and rejecting a zero-length file was also
a bug.

Ian