[PATCH] Re: deletion of output files

[Jan Beulich]

>> tmpnam.c						\
>>  	vasprintf.c vfork.c vfprintf.c vprintf.c vsnprintf.c
>> vsprintf.c	\
>>
+	unlink-if-ordinary.c						\
>
>This list is supposed to be in alphabetical order.

I saw that, I just misplaced it by a line.

>Also, your mailer is corrupting your patch by line wrapping.  (yes, I
>saw the attached binary, just FYI).

I know, but can't (at present) do anything about it.

>> @@ -973,6 +975,13 @@ $(CONFIGURED_OFILES): stamp-picdir
>>  	else true; fi
>>  	$(COMPILE.c) $(srcdir)/tmpnam.c $(OUTPUT_OPTION)
>>  
>> +./unlink-if-ordinary.o: $(srcdir)/unlink-if-ordinary.c config.h
>> $(INCDIR)/ansidecl.h \
>> +	$(INCDIR)/libiberty.h
>> +	if [ x"$(PICFLAG)" != x ]; then \
>> +	  $(COMPILE.c) $(PICFLAG) $(srcdir)/unlink-if-ordinary.c -o
>> pic/$@; \
>> +	else true; fi
>> +	$(COMPILE.c) $(srcdir)/unlink-if-ordinary.c $(OUTPUT_OPTION)
>> +
>
>Did you use "make maint-deps" to produce this part, or cut and paste?

Just cut-and-paste. I wasn't sure how Makefile.in would get generated
(namely the one in cvs), and for this simple case it seemed appropriate
to do this by hand. Just for my understanding of the processes here: if
I regenerated it, would I still list this in the patch (and apply the
delta once approved)?

>>
/home/jbeulich/src/binutils/mainline/2004-12-03.13.35/libiberty/unlink-if-ordinary.c	1970-01-01
>> 01:00:00.000000000 +0100
>> +++ 2004-12-03.13.35/libiberty/unlink-if-ordinary.c	2004-12-15
>> 12:14:37.960124016 +0100
>> @@ -0,0 +1,49 @@
>> +/* unlink-if-ordinary.c - remove link to a file unless it is
special
>> */
>
>Copyright block required.

Odd (as so many things). I used another of the source files as
template, and that one (getpwd.c) didn't have one either. But of course
it's no big deal to copy one from one of those files that have it.

>> +/*
>> +
>> +@deftypefn Supplemental int unlink_if_ordinary (const char*)
>> +
>> +Unlink the named file, unless it is special (e.g. a device file).
>> +Returns 0 when the file was unlinked, a negative value (and errno
set)
>> when
>> +there was an error deleting the file, and a positive value if no
>> attempt
>> +was made to unlink the file because it is special.
>
>Hmmm... I wonder if returning an error condition when it doesn't
>attempt an unlink is accurate.  After all, it correctly did what it
>was supposed to do.  Any bets on how often programmers forget to
check
>for this?  ;-)

Depends on whether you see this as an error condition. Many functions
return negative values (and not just non-zero) as error condition, which
is why I selected this method.
Btw., none of the call sites in binutils actually check the return
value.

>> +    return unlink (name);
>> +
>> +  return 1;
>> +}
>
>I wonder if we should set errno to something useful if we return 1.
>Else, we should document that errno is unspecified in that case.

Since I don't view this as an error condition, I intentionally didn't
set errno.

Jan