This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [PATCH] Re: deletion of output files
- From: DJ Delorie <dj at redhat dot com>
- To: JBeulich at novell dot com
- Cc: ian at wasabisystems dot com, binutils at sources dot redhat dot com
- Date: Wed, 15 Dec 2004 08:41:11 -0500
- Subject: Re: [PATCH] Re: deletion of output files
- References: <s1c02fde.076@emea1-mh.id2.novell.com>
> 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.
Also, your mailer is corrupting your patch by line wrapping. (yes, I
saw the attached binary, just FYI).
> @@ -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?
> /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.
> +/*
> +
> +@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? ;-)
> + 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.