This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Re: deletion of output files


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]