Re: printf failure on HP/UX 10.20 with 6.9.92

[Peter Fales]

I've got a little more information...

1) The problem stil occurs with 6.10

2) I can see what's happening, though I'm not quite sure how it's supposed
   to work.   When the gnulib vsnprintf("%*s",-3,"x") is called, it
   ends up eventually calling the the system snprintf through the SNPRINTF_BUF
   macro as  snprint(result+length, maxlen, "%-*s%n", -3, "x", &count);

   It looks like the system snprintf is buggy.  I suspect the '-' character
   in the format specification is negating the value of the -3 argument.

   On the system in question, this test program

        main()
        {
                int count;
                
                printf("1 %*s%n\n",-3,"x",&count);
                printf("1 %-*s%n\n",-3,"x",&count);
                printf("1 %-*s%n\n",3,"x",&count);
        }

    prints 

        1 x  
        1   x
        1 x  

    But on other systems (such as Linux) it prints

        1 x  
        1 x  
        1 x  

    Perhaps a fix would be to change the a.arg[] value to positive when
    the '-' character is inserted into the format string.  That fix
    appears to work (at least make check now passes) but I'm not sure
    if there are any side effects of changing the a.arg values.

On Thu, Jan 31, 2008 at 08:03:29PM +0100, Jim Meyering wrote:
> Peter Fales <address@hidden> wrote:
> > I'm trying to port coreutils-6.9.92 to HP/UX 10.20 and getting a test
> > failure...
> >
> > With the command
> >
> >     printf  '1 %*sy\n' -3 x
> >
> > the expected result (and the result from 6.8+) is:
> >
> >     1 x  y
> >
> > But with 6.9.92, I'm getting:
> >
> >     1   xy
> >
> > Any ideas where to look?
> 
> Maybe that system has a *printf function that
> misinterprets a negative field width?
> It's suspicious that your result is what this prints:
> (i.e., same command but using a width of 3, rather than -3)
> 
>       printf  '1 %*sy\n' 3 x
> 
> Just in case something changed between 6.9.92 and 6.10,
> it'd be better if you would test the latter stable release.
> 
> To figure out which function is at fault, the easiest might
> be to use a debugger.  Set breakpoints at xprintf,
> rpl_vfprintf, and vfprintf for starters.  From there,
> single step until you hit a function with no symbols
> (then maybe blame HP's C library), or until you see that
> some of the replacement machinery from gnulib is misbehaving.
> 
> Just knowing whether you're using the replacement vfprintf
> function would be nice.  Here's what I see on a system where
> rpl_vfprintf is used:
> 
>   $ grep VFPRINT config.status
>   S["GNULIB_VFPRINTF_POSIX"]="1"
>   S["REPLACE_VFPRINTF"]="1"

-- 
Peter Fales
Alcatel-Lucent
Member of Technical Staff
2000 Lucent Lane
Room: 1C-436
Naperville, IL 60566-7033
Email: address@hidden
Phone: 630 979 8031