Re: gawk compl()

[Andrew J. Schorr]

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.)

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...

Regards,
Andy