Fix failure

Fix failure
  ../runtime/vm/object.cc:7149: error: unimplemented code
  Abort
in standalone tests when run with 64bit dart.

The ioctl function when used with FIONREAD was being passed a 64 bit
argument which is incorrect.

Documentation on ioctl:
FIONREAD
The FIONREAD ioctl returns the number of data bytes (in all data
messages queued) in the location pointed to by the arg parameter. The
ioctl returns a 32-bit quantity for both 32-bit and 64-bit
application., Therefore, code that passes the address of a long
variable needs to be changed to pass an int variable for 64–bit
applications.
Committed: https://code.google.com/p/dart/source/detail?r=3250

[regis, 2012-01-12 02:34:51]

LGTM!!

Thank you for hunting this one down.

-- Regis

[Søren Gjesse, 2012-01-12 07:32:47]

lgtm - just some after the fact comments.

http://codereview.chromium.org/9194002/diff/5001/bin/fdutils_macos.cc
File bin/fdutils_macos.cc (right):

http://codereview.chromium.org/9194002/diff/5001/bin/fdutils_macos.cc#newcode41
bin/fdutils_macos.cc:41: intptr_t FDUtils::AvailableBytes(intptr_t fd) {
I have it on my TODO list to change all these uses of intptr_t in system calls
to the types actually used in the .h files where the calls are declared.

http://codereview.chromium.org/9194002/diff/5001/bin/fdutils_macos.cc#newcode42
bin/fdutils_macos.cc:42: int32_t available;
Shouldn't we just use int here as that is what is specified on the ioctl_list
man page?

http://codereview.chromium.org/9194002/diff/5001/bin/socket_stream.dart
File bin/socket_stream.dart (right):

http://codereview.chromium.org/9194002/diff/5001/bin/socket_stream.dart#newco...
bin/socket_stream.dart:12: if (bytesToRead <= 0) return null;
I think we should assert that available is never negative and make sure that
available throws an exception if -1 is returned from the system call. We have it
on our OKRs to go through the error handling in the IO subsystem.

[siva, 2012-01-12 19:30:50]

Thanks.

http://codereview.chromium.org/9194002/diff/5001/bin/fdutils_macos.cc
File bin/fdutils_macos.cc (right):

http://codereview.chromium.org/9194002/diff/5001/bin/fdutils_macos.cc#newcode41
bin/fdutils_macos.cc:41: intptr_t FDUtils::AvailableBytes(intptr_t fd) {
Ok.

On 2012/01/12 07:32:47, Søren Gjesse wrote:
> I have it on my TODO list to change all these uses of intptr_t in system calls
> to the types actually used in the .h files where the calls are declared.

http://codereview.chromium.org/9194002/diff/5001/bin/fdutils_macos.cc#newcode42
bin/fdutils_macos.cc:42: int32_t available;
I would prefer int32_t as opposed to int as it makes it clear that we are
dealing with a 32 bit quantity here.
But I agree you are worried if the kernel has a different interpretation of
'int' from 'int32_t' this would break again.
Changed to use 'int'


On 2012/01/12 07:32:47, Søren Gjesse wrote:
> Shouldn't we just use int here as that is what is specified on the ioctl_list
> man page?

http://codereview.chromium.org/9194002/diff/5001/bin/socket_stream.dart
File bin/socket_stream.dart (right):

http://codereview.chromium.org/9194002/diff/5001/bin/socket_stream.dart#newco...
bin/socket_stream.dart:12: if (bytesToRead <= 0) return null;
Removed this check here and added an asserion in the native code for available
being always >= 0.
When you do your cleanup you can take care of this.

On 2012/01/12 07:32:47, Søren Gjesse wrote:
> I think we should assert that available is never negative and make sure that
> available throws an exception if -1 is returned from the system call. We have
it
> on our OKRs to go through the error handling in the IO subsystem.