Re: gawk compl()

[Karel Zak]

On Mon, 2005-10-10 at 13:40 -0400, Andrew J. Schorr wrote:
> On Mon, Oct 10, 2005 at 07:27:29PM +0200, Karel Zak wrote:
> > On Mon, 2005-10-10 at 09:29 -0400, Andrew J. Schorr wrote:
> > > On Mon, Oct 10, 2005 at 02:19:49PM +0200, Karel Zak wrote:
> > > > $ gawk 'BEGIN {printf("%#x\n", compl(0xFFFF0000)) }'
> > > > 0x1fffff0000ffff
> > > > 
> > > > I see same output for 3.1.5, 3.1.4 and 3.1.3. It seems that version
> > > > 3.1.2 returns correct output (it means 0xffff).
> > > 
> > > Actually, the code seems to be working correctly.  Your code
> > 
> > >From my point of view it's regression between version 3.1.2 and >=3.1.3.
> > It means the code (or docs) is incorrect :-)
> 
> Well, the documentation on the bitwise functions says the following:
> 
>    http://www.gnu.org/software/gawk/manual/html_node/Bitwise-Functions.html
> 
>    For all of these functions, first the double-precision
>    floating-point value is converted to the widest C unsigned integer
>    type, then the bitwise operation is performed and then the result is
>    converted back into a C `double'. (If you don't understand this
>    paragraph, don't worry about it.)
> 
> An older version of the documentation (from 3.1.0) said the following:
> 
>    For all of these functions, first the double-precision floating-point value
>    is converted to a C unsigned long, then the bitwise operation is performed
>    and then the result is converted back into a C double. (If you don't
>    understand this paragraph, don't worry about it.)

Thanks. I think the best will be add there information about difference
between old and new version.

> So there was a clear change of language from "C unsigned long" to "the widest 
> C
> unsigned integer type".  And the code was patched to start using uintmax_t for
> the calculations instead of u_long.  I think this was done for good reasons:
> there are other situations where the old u_long behavior is not good.  The
> patch seems to have initially come up here:
> 
>    http://sources.redhat.com/ml/bug-gnu-utils/2003-03/msg00251.html
> 
> I agree the documentation is not terribly clear, and it's perhaps a mistake
> to encourage people to ignore the paragraph, particularly with respect to the
> compl() function.
> 
> I'm not sure what the proper solution is here, but it seems to me that
> the documentation is OK (not great), and the code works as described
> in the docs.  Perhaps some kind of warning message would be helpful.
> What do you suggest?  I doubt that reverting to the old behavior is
> an option...

It's problem found some good solution if there is only one common
numeric datetype.

        Karel

-- 
Karel Zak <address@hidden>