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: Sat, 25 Nov 2000 20:34:08 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: Patch #3 for dtou.c
Message-ID: <3A202240.26816.EFC738@localhost>
References: <Pine DOT A41 DOT 4 DOT 05 DOT 10011251321540 DOT 82314-100000 AT ieva06 DOT lanet DOT lv>
In-reply-to: <927D321561@HRZ1.hrz.tu-darmstadt.de>
X-mailer: Pegasus Mail for Win32 (v3.12c)
Reply-To: djgpp-workers AT delorie DOT com

On 25 Nov 2000, at 17:44, Juan Manuel Guerrero wrote:

> Date: Sat, 25 Nov 2000 14:18:19 +0200 (WET)
> From: Andris Pavenis <pavenis AT lanet DOT lv>
> > Some initial comments:
> >
> > Perhaps there is no need to convert argv[0] to lowercase to print usage
> > info. Function strlwr() used for this purpose is not portable (not ANSI,not
> > POSIX). As result dtou.c is not compiling for me on Linux (glibc-2.2) and
> > under AIX 4.3.1 on RS6000. Also we should strip path from argv[0] for
> > displaying usage info
>  I have no access to AIX, HP-UX, linux, etc. etc etc machines so I will let
> you make all the changes needed.
> I have forgotten to check if strlwr() is POSIX. Sorry. This must be corrected.
> Usualy, the GNU programs print their full path when you isue a command like: tar.
> This is the reason why I have tried to copy the same behaviour.

Ok it's even simplier.
> 
> > Also I think it's better to return 0 unless return code is explicitly
> > requested by some command line parameter.
> Sorry but I do not understand this. This will completely break backward
> compatibility. If this is wanted, a new "compatibility" switch must be
> invented for dtou.

Forget this note. I looked more detailed and current version is Ok. 
 
> > About -v and -vv: I think that we should use verbose=2 instead of
> > vverbose=1 (so if we change to getopt() each -v increases variable 
> > verbose) 
> >
> > This version of dtou will also not work for example if we want to convert
> > single file '-v' (it's veird of course). So I think it's better to use
> > getopt() for parsing options (so one can use 'dtou -- -v')
> I do not know about this. I have no preferences. I will let djgpp-workers
> decide this. But I would like to know the decision as soon as possible
> so I can start rewriting dtou.c and reuse as much as possible of this
> code in utod.c

There are examples of software where additional -v simply increases 
verbosity level. First example which comes into mind is bzip2.

> 
> > I'm including patch with following fixes:
> >
> >	- IS_DIR_SEPARATOR is system specific ('\\' and ':' is a
> >		separator not for all systems)
> >	- stripping path from executable name when displaying usage info
> >	- removal on non-portable function strlwr()
> >	- adding missing '\n' at end of output of usage info
> IS_DIR_SEPARATOR issue is OK.
> The executable path issue. I do not know. AFAIK gnu programs
>  always print the executable path.

Let it be so

> Removal of strlwr()issue. This is OK.
> Missing '\n' issue. The '\n' has **not** been forgotten. This was intentional.
> I wanted that the complete help text fits into **one** screen without scrolling
>  the first line out of the screen.

In this case we should add 

#if !defined(MSDOS) && !defined(_Windows)
	"\n"
#endif

at end of string as for example in Linux no extra LF is appended (I 
tested CVS version of dtou on Linux). 

Andris