Re: [bug-gawk] bitwise functions with negative values

[Andrew J. Schorr]

On Wed, Oct 05, 2016 at 03:45:59PM +0200, Manuel Collado wrote:
> El 05/10/2016 2:16, Andrew J. Schorr escribió:
> >[...]
> >Also, I think it's pretty weird that bits2str in the doc uses
> >zero-padding on the left. That gives strange results for negative values.
> >
> >It's not clear how to address these various issues. One idea is to stop
> >supporting negative values with these bitwise functions. And I'm not sure
> >whether compl makes any sense at all. Thoughts?
> 
> Perhaps the simplest approach is to consider bitwise functions as operations
> on bit strings of fixed length, regardless of their possible numeric
> interpretation.

That does seem conceptually simplest, and I think that's sort of what the
existing regular (not -M) code tries to do, effectively for 53 or 54 bits,
the IEEE 754 precision. But there's some weird behavior at the edges. For
example:

bash-4.3$ ./gawk 'BEGIN {print compl(0)}'
9007199254740991
bash-4.3$ ./gawk 'BEGIN {print compl(1)}'
18014398509481982

The compl(0) result uses 53 bits, and the compl(1) result uses 54.
And -M is totally different.

So perhaps we should set a fixed width, such as 53 bits, and make both
regular and -M honor that width. Is that what you have in mind?

> For right shifts (similar for left shifts), there are usually three
> variants:
> 
> - Logical, padding with zeros.
> - "Arithmetic", propagating the leftmost bit.
> - Circular, recycling the rightmost bit.
> 
> IMHO, all these distinct variants could/should be provided.

So do you propose to extend these bitwise functions by adding an additional
argument to select which variant is used? I'm not sure it is a good idea
to add more complexity. I wonder if we would be better off if the bitwise
functions were in an extension library instead of inside core gawk, but it's
probably not a great idea to remove them at this point. We could certainly
add a more complete bitwise library in an extension, although we still
haven't grappled with how to handle MPFR support in extensions...

Regards,
Andy