On Thu, Jun 17, 2010 at 9:21 AM, Jeff Johnson wrote:
> Meanwhile in the future, if you could send a patch against some POPT
> release that I can find
>
Sorry about that. I sent you a patch for the rsync popt by mistake. Here's
one I just made against 1.16 that now includes a couple tests for t
On Mon, Jun 7, 2010 at 9:40 AM, Jeff Johnson wrote:
> The added tyrrany of forcing every application that currently has
> -lpopt
> to change to
> -ljdod
> will be rate-determining to adoption (and glacially/tectonically slow imho)
>
For me, if popt 2 is not compatible with popt 1 then I would ra
On Mon, Jun 7, 2010 at 9:14 AM, Jeff Johnson wrote:
> And without some deterministic way to tell whether its a POPT 1.x <-> 2.x
> table being fed to the POPT API/ABI, well, only a deliberately
> "incompatible" POPT 2.0 data structure with some deterministic
> version identifier is possible.
>
On
On Sat, Jun 5, 2010 at 8:56 AM, Jeff Johnson wrote:
> but
>--foo bar
> returns bar in the argument list?
>
Yes. The user may well have wanted it to be in the arg list. There's no
way for the program to know that the user didn't just toss some options in
the middle of some args (which I
Here's something that was recently fixed for the popt that is included
with rsync: rejecting an arg to an option that doesn't take an arg.
Attached is a patch. A new error code, POPT_ERROR_UNWANTEDARG, was
created to make the error message nice. This handles both -l=value
and --long-arg=value wh
I made a couple more places use stpcpy() in the code, optimizing away a
couple strlen() calls in the process. I also tweaked the help code that
was abbreviating a long value using "..." to allow a string to fit if it
can, rather than always reserving space for the "..." chars. I.e. if we
had room
On Sun, Mar 09, 2008 at 07:00:52PM -0700, Wayne Davison wrote:
> +} else if (prtshort) {
> + left[0] = '-';
> + left[1] = opt->shortName;
> +} else if (prtlong) {
Oops, there should have been a left[2]
On Sun, Mar 09, 2008 at 08:27:25PM -0400, Jeff Johnson wrote:
> Using xmalloc just opens up a can-of-worms while lusers fuss about
> non-gcc compiler extension portability.
Aha, I had failed to notice that the "? :" bit was a gcc extension.
What I don't like is that normal users get some memory f
On Sun, Mar 09, 2008 at 07:10:21PM -0400, Jeff Johnson wrote:
> Your original patch for -c=foo is now checked in.
Cool! You should also be able to uncomment the extra tests now.
..wayne..
__
POPT Library
On Sun, Mar 09, 2008 at 07:26:31PM -0400, Jeff Johnson wrote:
> There are some subtleties however with xstrdup. [... mtrace related
> issues ...]
Right, that's why I preserved the HAVE_MCHECK_H version using its own
malloc() call (it's unchanged from your version) and just made the non-
HAVE_MCHEC
I'm curious why the xmalloc() function (and its brethren) exits with a
fatal error on only some systems and not on all systems? I would think
that the code should use the exiting functions in all cases, and just
provide differing versions of xstrdup() so that the HAVE_MCHECK_H
version does a mallo
On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote:
> Running test test1 - 9.
> Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1:
> 0 arg2: foo"
I can get that failure if the line I added does not replace the prior
assignment (which makes it affect the case where *o
On Sun, Mar 09, 2008 at 10:51:42AM -0400, Jeff Johnson wrote:
> [EMAIL PROTECTED] popt]$ /bin/echo --foo --bar
> --bar
> [EMAIL PROTECTED] popt]$ /bin/echo -- --foo --bar
> --foo --bar
OK, Let's hope that your echo will not drop anything if the first arg
passed to it is a non-option (such as "args
On Sun, Mar 09, 2008 at 10:51:42AM -0400, Jeff Johnson wrote:
> Meanwhile, below is a rewrite of POPT_fprintf, essentially identical
> to the "man vsnprintf" example. See what you think ...
Looks good. I did some tweaking based on this code. The attached patch
changes what you checked-in to CVS.
On Sun, Mar 09, 2008 at 12:42:37AM -0500, Jeff Johnson wrote:
> /bin/echo on my system is unmodified from
> Fedora 9 coreutils-6.10-4.fc9.i386
Interesting. So, what do you get with a manual run?
/bin/echo --foo --bar
/bin/echo -- --foo --bar
I see all the option information output lit
On Sat, Mar 08, 2008 at 10:42:36AM -0800, Wayne Davison wrote:
> (i.e. -1 could be mapped to the limit-value+1 without need to compute
> the real overflow length because popt doesn't ever call snprintf()
> expecting to find out how much bigger its buffer needs to be
This is appare
There are some UNIX systems that have their own _ABS() define in the
system header files, so the redefinition of _ABS() in popt.c can cause
problems. I changed the define to be POPT_ABS(). Also, some systems
don't seem to have DBL_EPSILON, so I define that if it is missing.
See attached patch.
.
On Sat, Mar 08, 2008 at 06:11:09PM -0500, Jeff Johnson wrote:
> Hmmm, we appear to have different behavior wrto echo. Your
> patch changes testit.sh to include an explicit "--", which (when
> I last fixed testit.sh like 3 weeks ago) does not appear in the
> output I am (and was) seeing.
I tried i
In rsync I eliminated all use of sprintf(), strcpy(), and strcat(),
replacing them with snprintf(), strlcpy(), and strlcat(). Would you be
interested in such changes if appropriate compatibility functions were
defined?
For instance, I could imagine a configure test to see if snprintf()
returns a
On Sat, Mar 08, 2008 at 12:10:52PM -0500, Jeff Johnson wrote:
> Test "test1 -2 foo" failed with: "arg1: 0 arg2: rest: foo" != "arg1:
> 0 arg2: foo"
I'm not seeing that error with the CVS version. I do note that my prior
patch to fix the longArg pointer (e.g. "./test1 -2foo=bar") isn't there,
b
The attached patch turns on more extensive warnings in gcc (-W) and then
fixes a bunch of unused-arg warnings and one signed/unsigned comparison
warning. Non-gcc compilers should be unaffected.
This should help to find problems in the future, and will allow other
packages (such as rsync) to compi
I think it would be nice to allow an equal to separate a short option
letter from its abutting argument. e.g. these commands using the test1
executable would all work the same:
./test1 -2 foo
./test1 -2=foo
./test1 -2foo
./test1 --arg2 foo
./test1 --arg2=foo
Since this has been a syntax err
Popt has a bug where a short option with an abutting arg is parsed
incorrectly if there is an equal sign in the arg. This can be seen
using the "test1" executable:
% ./test1 -2foo-bar
arg1: 0 arg2: foo-bar
% ./test1 -2foo=bar
test1: bad argument -2foo=bar: invalid numeric value
% ./test1 -21=bar
23 matches
Mail list logo
