From:	pavenis AT lanet DOT lv
To:	"Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>,
	djgpp-workers AT delorie DOT com
Date:	Thu, 23 Nov 2000 12:03:14 +0200
MIME-Version:	1.0
Subject:	Re: New patch for dtou.c
Message-ID:	<3A1D0782.8231.5A370A@localhost>
References:	<Pine DOT A41 DOT 4 DOT 05 DOT 10011230909400 DOT 21330-100000 AT ieva06 DOT lanet DOT lv>
In-reply-to:	<5A4F5D3251@HRZ1.hrz.tu-darmstadt.de>
X-mailer:	Pegasus Mail for Win32 (v3.12c)
X-MIME-Autoconverted:	from Quoted-printable to 8bit by delorie.com id FAA06865
Reply-To:	djgpp-workers AT delorie DOT com

On 23 Nov 2000, at 9:34, Juan Manuel Guerrero wrote:

I think that Eli's wishlist was only a draft to think about.

> > 
> > It's OK if we are processing only one file. But one could write something
> > like
> > 	dtou `find foo -name '*.cc' -or -name '*.h'`
> > under bash. How to interpret return values in this case (if we have many
> > files processed). I think only reasonable way is to provide this info when
> > verbose output is required. 
> Sorry, but I do not unterstand this at all. The numbers in the table are the return code
> of main() to the calling environment. **No** text at all will ever be outputed.
> The text in the table is only for the djgpp-workers' information and will never be send to
> stdin nor stderr. The above table is the same table that I have added to the util.tex file
> for user's information. Only the numbers (return codes/exit status) are of importance
> and will be seen by the calling context (bash in your example).
> The return code of main() is always the return code generated by the last processed file
> as usual.

I think returning code for last file processed is rather useless if we are 
processing more than one file. Maybe it would be better to assign a bit
for each type of change and return this bit when for processing at 
least one file this bit was set. 

Anyway I think its better to move such information to verbose output
and always return 0 (as any conversion done is not really an error).

Andris

- Raw text -