Update included popt to version 1.7

[Paul Slootman]

On Thu 15 May 2003, Max Bowsher wrote:

> Granted, these are mainly compilation fixes for popt itself, but they
> presumably indicate systems which often do not have a system popt. Not that
> I've ever seen any of these fairly obscure systems, but they should at least
> be mentioned in the release notes.

True.

> --- rsync/popt/popt.c:1.1.1.2 Wed May 14 17:21:03 2003
> +++ rsync/popt/popt.c Wed May 14 17:24:18 2003
> @@ -927,6 +927,9 @@
>        if ((opt->argInfo & POPT_ARG_MASK) == POPT_ARG_DOUBLE) {
>     *((double *) opt->arg) = aDouble;
>        } else {
> +#ifndef DBL_EPSILON
> +#define DBL_EPSILON 2.2204460492503131e-16
> +#endif
>  #define _ABS(a) ((((a) - 0.0) < DBL_EPSILON) ? -(a) : (a))
>     if ((_ABS(aDouble) - FLT_MAX) > DBL_EPSILON)
>         return POPT_ERROR_OVERFLOW;

Could indeed be an issue.

> @@ -1080,7 +1083,7 @@
>  int poptAddAlias(poptContext con, struct poptAlias alias,
>    /*@unused@*/ int flags)
>  {
> -    poptItem item = alloca(sizeof(*item));
> +    poptItem item = (poptItem) alloca(sizeof(*item));
>      memset(item, 0, sizeof(*item));
>      item->option.longName = alias.longName;
>      item->option.shortName = alias.shortName;

This is a non-issue, alloca returns a (void *) which doesn't need
casting. On systems where it might return a (char *) there might be a
warning, but it won't affect the compilation.

> diff -u rsync/popt/poptconfig.c:1.1.1.2 rsync/popt/poptconfig.c:1.5
> --- rsync/popt/poptconfig.c:1.1.1.2 Wed May 14 17:21:03 2003
> +++ rsync/popt/poptconfig.c Wed May 14 17:24:19 2003
> @@ -18,7 +18,7 @@
>      /*@=type@*/
>      const char * entryType;
>      const char * opt;
> -    poptItem item = alloca(sizeof(*item));
> +    poptItem item = (poptItem) alloca(sizeof(*item));
>      int i, j;
> 
>  /*@-boundswrite@*/

Ditto.

> diff -u rsync/popt/popthelp.c:1.1.1.2 rsync/popt/popthelp.c:1.4
> --- rsync/popt/popthelp.c:1.1.1.2 Wed May 14 17:21:04 2003
> +++ rsync/popt/popthelp.c Wed May 14 17:24:19 2003
> @@ -146,19 +146,23 @@
>      case POPT_ARG_VAL:
>      case POPT_ARG_INT:
>      { long aLong = *((int *)opt->arg);
> - le += sprintf(le, "%ld", aLong);
> + sprintf(le, "%ld", aLong);
> + le += strlen(le);
>      } break;
>      case POPT_ARG_LONG:
>      { long aLong = *((long *)opt->arg);
> - le += sprintf(le, "%ld", aLong);
> + sprintf(le, "%ld", aLong);
> + le += strlen(le);
>      } break;
>      case POPT_ARG_FLOAT:
>      { double aDouble = *((float *)opt->arg);
> - le += sprintf(le, "%g", aDouble);
> + sprintf(le, "%g", aDouble);
> + le += strlen(le);
>      } break;
>      case POPT_ARG_DOUBLE:
>      { double aDouble = *((double *)opt->arg);
> - le += sprintf(le, "%g", aDouble);
> + sprintf(le, "%g", aDouble);
> + le += strlen(le);
>      } break;
>      case POPT_ARG_STRING:
>      { const char * s = *(const char **)opt->arg;
> @@ -289,7 +293,8 @@
>    *le++ = '=';
>    if (negate) *le++ = '~';
>    /*@-formatconst@*/
> -  le += sprintf(le, (ops ? "0x%lx" : "%ld"), aLong);
> +  sprintf(le, (ops ? "0x%lx" : "%ld"), aLong);
> +  le += strlen(le);
>    /*@=formatconst@*/
>    *le++ = ']';
>       }

This is one that could bite someone.
In fact, it's bitten me in the (distant) past :-)
SunOS4 is one that returns a (useless) pointer to the string instead of
the number of bytes written.

> diff -u rsync/popt/system.h:1.1.1.2 rsync/popt/system.h:1.4
> --- rsync/popt/system.h:1.1.1.2 Wed May 14 17:21:04 2003
> +++ rsync/popt/system.h Wed May 14 17:24:19 2003
> @@ -51,8 +51,15 @@
>  #  ifdef _AIX
>  #pragma alloca
>  #  else
> -#   ifndef alloca /* predefined by HP cc +Olibcalls */
> +#   if HAVE_ALLOCA
> +#    ifndef alloca /* predefined by HP cc +Olibcalls */
>  char *alloca ();
> +#    endif
> +#   else
> +#    ifdef alloca
> +#     undef alloca
> +#    endif
> +#    define alloca(sz) malloc(sz) /* Kludge this for now */
>  #   endif
>  #  endif
>  # endif

Yuck :-)


Perhaps these should be forwarded to the popt maintainer i.e. Erik Troan
<ewt at redhat.com>, so that it can be fixed at the source? Or was that
already done at the time these patches were made in the rsync source (as
I should hope) ?  Of course, I've heard it mention that he often doesn't
respond to email :-(


Paul Slootman