putting Ptrace back to 64-bit

putting Ptrace back to 64-bit

[Andrew Cagney]

Mark,

I don't understand the rationale behind this change:

2007-07-30  Mark Wielaard  <mwielaard@redhat.com>

        * FileDescriptor.java (read): Make start and length ints.
        (write): Likewise.
        * Ptrace.java (peek): Make length and offset ints.
        * StatelessFile.java (pread): Make start and length ints.
        (pwrite): Likewise.
        * TestFileDescriptor.java (IO.op): Likewise.
        (assertArrayIndexOutOfBounds): Likewise.
        (testReadOutOfBounds): Likewise.
        (testWriteOutOfBounds): Likewise.
        * TestPtrace.java (verifyOutOfBounds): Make length and offset ints.
        * TestStatelessFile.java: Make start and length ints.
        * cni/Errno.cxx (verifyBounds): Make start and length ints.
        * cni/Errno.hxx: Likewise.
        * cni/FileDescriptor.cxx (read): Make start and length jints.
        (write): Likewise.
        * cni/Ptrace.cxx (peek): Make length and offset jints.
        * cni/StatelessFile.cxx (pread): Make start and length jints.
        (pwrite): Likewise.

It forces calling code to contend with Java's bone-head "int" is 32-bits 
and be damed.  Having all of these "long", which I only just went 
through and cleaned up, avoided all that.

The only thing missing was for inua to be matched to this style.

Andrew

Re: putting Ptrace back to 64-bit

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

Hi Andrew,

On Wed, 2007-08-01 at 22:58 -0400, Andrew Cagney wrote:
> I don't understand the rationale behind this change:

It was proposed and explained as a follow up for the LogicalMemoryBuffer
under "A couple of things to note, questions and upcoming work" at:
http://sourceware.org/ml/frysk/2007-q3/msg00163.html
And the rationale was again added when the actual patch to implement it
was posted: http://sourceware.org/ml/frysk/2007-q3/msg00216.html

> It forces calling code to contend with Java's bone-head "int" is 32-bits 
> and be damed.

No, the patch carefully only changes those calls that take a 32-bit
(actually positive "int" byte[]) container in the first place so that
the calling code is consistent and calls to these methods get flagged at
compile time if they provide inconsistent arguments. None of the
arguments that actually are 64-bit were changed of course.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: putting Ptrace back to 64-bit

[Andrew Cagney]

Mark Wielaard wrote:
> Hi Andrew,
>
> On Wed, 2007-08-01 at 22:58 -0400, Andrew Cagney wrote:
>   
>> I don't understand the rationale behind this change:
>>     
>
> It was proposed and explained as a follow up for the LogicalMemoryBuffer
> under "A couple of things to note, questions and upcoming work" at:
> http://sourceware.org/ml/frysk/2007-q3/msg00163.html
> And the rationale was again added when the actual patch to implement it
> was posted: http://sourceware.org/ml/frysk/2007-q3/msg00216.html
>   

Please run such things directly past me.
>   
>> It forces calling code to contend with Java's bone-head "int" is 32-bits 
>> and be damed.
>>     
>
>   
That is Java's 32-bit bonehead ism.  This exports a 64-bit interface; 
we'll keep it that way.



> No, the patch carefully only changes those calls that take a 32-bit
> (actually positive "int" byte[]) container in the first place so that
> the calling code is consistent and calls to these methods get flagged at
> compile time if they provide inconsistent arguments. None of the
> arguments that actually are 64-bit were changed of course.
>
> Cheers,
>
> Mark
>   

Re: putting Ptrace back to 64-bit

[Mark Wielaard]

Hi Andrew,

On Thu, 2007-08-02 at 08:37 -0400, Andrew Cagney wrote:
> Mark Wielaard wrote:
> > On Wed, 2007-08-01 at 22:58 -0400, Andrew Cagney wrote:
> >> I don't understand the rationale behind this change:
> >
> > It was proposed and explained as a follow up for the LogicalMemoryBuffer
> > under "A couple of things to note, questions and upcoming work" at:
> > http://sourceware.org/ml/frysk/2007-q3/msg00163.html
> > And the rationale was again added when the actual patch to implement it
> > was posted: http://sourceware.org/ml/frysk/2007-q3/msg00216.html   
> 
> Please run such things directly past me.

I am happy for people to review my patches before committing. But you
have to give me some guidance here since till now we didn't have any
formal reviews, but were relying on unit tests to catch any badness. In
this case I thought it was a simple cleanup refactoring to make the real
work that I was doing easier and the code safer (as explained in that
first email). What kind of changes do you want to have reviewed first
and by who. Do you want people to be CCed on such patches? Can't we just
make it so that if a patch is posted to the list anybody can review it
to make sure it is sane?

Cheers,

Mark