Re: proposed patch to allocsa, vasnprintf for Tandem NSK (OSS)

[Paul Eggert]

mwoehlke <address@hidden> writes:

> j=1
> shc=1
> sample1=a84e715a515523b4
> sample2=0

This was test_integer_sshift, right?  In that case, the C standard
says that the behavior of sample1>>shc is implementation-defined if
sample1 is negative, which is the case here.  So Tandem C is within
its rights to behave this way.  Some GNU code assumes that signed
right shifts propagate the sign, but as a general rule I think
coreutils does not assume that, and if it's easy to fix any places
where it does mistakenly do that then we should do so.

If you filter out the failures involving signed right shifts of
negative numbers, are there any other failures?  If so, I'd like to
turn one of those failures into a test case, that we can use to reject
this buggy implementation.  (If I recall, the bugs occur only with -O,
so you can work around them by not using -O; but we should test for
the bugs anyway.)