Option Strict On

[Vijay]

With the option strict On set.....

Dim fs As FileStream = File.OpenRead(strFile)

With fs
Dim buffer(fs.Length) As Byte ' <--- Option Strict On disallows implicit
conversions from 'Long' to 'Integer'.
' other stuff..
End With

been a while i did VB code... can somebody help me what I am doing wrong
here...

Vijay

 

[Renze de Waal]

Op Fri, 31 Mar 2006 15:12:05 -0600 schreef Vijay:

With the option strict On set.....

Dim fs As FileStream = File.OpenRead(strFile)

With fs
Dim buffer(fs.Length) As Byte ' <--- Option Strict On disallows implicit
conversions from 'Long' to 'Integer'.
' other stuff..
End With

been a while i did VB code... can somebody help me what I am doing wrong
here...

Vijay

Vijay,

The report is about the array bound. fs.length is a long (64 bits signed
integer) and the dim statement expects an integer. VB would have to
implicitely convert the long to an integer (32 bits signed integer).

Unles you have really big files, the type conversion will be safe here.
Make it explicit by using ctype(fs.length,integer) instead of fs.length.

Another note in case you don't realise: value fs.length is the upper bound
of the array. The array starts at index 0, so you are declaring an array of
fs.length + 1 long.

Renze.

 

[zacks]

The length of an array is defined as a 32-bit integer. The Length
property in the FileStream class is a Long. Convert it to an Int, but
you should really check to see if the length of the file yo are trying
to read isn't too large to fit in a 32-bit int.

 

[Vijay]

Thanks Renze.. I just posted here to make sure I was not typing something
wrong... its been a while I did VB coding...

Vijay

 

[Vijay]

But the point.. I am reading files as a stream from my app display window to
create zip files the users can export... I am hoping nobody hits the Integer
mark...

VJ

 

[Vijay]

Ok here is some MSDN documentation I found... that helps... gives peace of
mind...

You can convert the Integer data type to Long, Single, Double, or Decimal
without encountering a System.OverflowException error.

I guess if the above is true... VB should not complain... the C# complier
does not .. why is VB complaining...

Vijay

 

[Cor Ligthert [MVP]]

Vijay,

In addition to Renze.

VB has very simple convert methods.

Dim buffer(CInt(fs.Length)) As Byte '

I hope this helps,

Cor

 

[Renze de Waal]

p Fri, 31 Mar 2006 16:30:26 -0600 schreef Vijay:

But the point.. I am reading files as a stream from my app display window to
create zip files the users can export... I am hoping nobody hits the Integer
mark...

VJ

Vijay,

If your files can be that long, try to avoid having to keep the file in
memory. I am not quite sure what you are doing, but maybe you can process
the files in parts.

Renze.

 

[Vijay]

The confusion for me here is C-Sharp does not seem to complain. VB being
simple enough why is there this problem? Maybe they have not changed the
underlying type from VB??

VJ

 

[Larry Lard]

The confusion for me here is C-Sharp does not seem to complain. VB being
simple enough why is there this problem? Maybe they have not changed the
underlying type from VB??

It would appear this is one the very few times when VB.NET is stricter
than C#. To wit, and to recap for C#ers just joining us:

C#
int[] f = new int[3000000000];
// compiles, throws System.OverflowException at run time

VB.NET
Dim f(3000000000) As Integer
' Will not compile: error is 'Constant expression not representable in
type Integer'

So here, the VB.NET compiler can work out at compile time that 3
billion is bigger than an Int32, and thus can't be used as an array
size (a CLS limitation I would suspect); but the C# compiler can't, or
doesn't care.

Your particular example can be examined also:

C#
long l = 3000000000;
int[] f = new int[l];
// compiles, throws System.OverflowException at run time

VB.NET
Dim l As Long = 3000000000
Dim f(l) As Integer
' Will not compile under Option Strict On:
' error is 'Option Strict On disallows implicit conversions from
'<type1>' to '<type2>''
' WILL compile with Option Strict Off: throws System.OverflowException
at run time

So for me the question is, why does C# allow this unstated cast from
long to int to compile? To that end I have xposted to the C# group

 

[Larry Lard]

The confusion for me here is C-Sharp does not seem to complain. VB being
simple enough why is there this problem? Maybe they have not changed the
underlying type from VB??

It would appear this is one the very few times when VB.NET is stricter
than C#. To wit, and to recap for C#ers just joining us:

C#
int[] f = new int[3000000000];
// compiles, throws System.OverflowException at run time

VB.NET
Dim f(3000000000) As Integer
' Will not compile: error is 'Constant expression not representable in
type Integer'

So here, the VB.NET compiler can work out at compile time that 3
billion is bigger than an Int32, and thus can't be used as an array
size (a CLS limitation I would suspect); but the C# compiler can't, or
doesn't care.

Your particular example can be examined also:

C#
long l = 3000000000;
int[] f = new int[l];
// compiles, throws System.OverflowException at run time

VB.NET
Dim l As Long = 3000000000
Dim f(l) As Integer
' Will not compile under Option Strict On:
' error is 'Option Strict On disallows implicit conversions from
'<type1>' to '<type2>''
' WILL compile with Option Strict Off: throws System.OverflowException
at run time

So for me the question is, why does C# allow this unstated cast from
long to int to compile? To that end I have xposted to the C# group

 

[VJ]

Yea seems like at some point VB.NET is smarter or strict here... I took all
the trouble to move from VB to C# over last 2 years.. now you have given me
some reason to come back.. Actually speaking I should be a loyalist here
for VB, because my initials are VB...

Vijay

The confusion for me here is C-Sharp does not seem to complain. VB being
simple enough why is there this problem? Maybe they have not changed the
underlying type from VB??

It would appear this is one the very few times when VB.NET is stricter
than C#. To wit, and to recap for C#ers just joining us:

C#
int[] f = new int[3000000000];
// compiles, throws System.OverflowException at run time

VB.NET
Dim f(3000000000) As Integer
' Will not compile: error is 'Constant expression not representable in
type Integer'

So here, the VB.NET compiler can work out at compile time that 3
billion is bigger than an Int32, and thus can't be used as an array
size (a CLS limitation I would suspect); but the C# compiler can't, or
doesn't care.

Your particular example can be examined also:

C#
long l = 3000000000;
int[] f = new int[l];
// compiles, throws System.OverflowException at run time

VB.NET
Dim l As Long = 3000000000
Dim f(l) As Integer
' Will not compile under Option Strict On:
' error is 'Option Strict On disallows implicit conversions from
'<type1>' to '<type2>''
' WILL compile with Option Strict Off: throws System.OverflowException
at run time

So for me the question is, why does C# allow this unstated cast from
long to int to compile? To that end I have xposted to the C# group

 

[VJ]

Sorry wrong post... I was another group..

VJ

Yea seems like at some point VB.NET is smarter or strict here... I took
all the trouble to move from VB to C# over last 2 years.. now you have
given me some reason to come back.. Actually speaking I should be a
loyalist here for VB, because my initials are VB...

Vijay

The confusion for me here is C-Sharp does not seem to complain. VB being
simple enough why is there this problem? Maybe they have not changed the
underlying type from VB??

It would appear this is one the very few times when VB.NET is stricter
than C#. To wit, and to recap for C#ers just joining us:

C#
int[] f = new int[3000000000];
// compiles, throws System.OverflowException at run time

VB.NET
Dim f(3000000000) As Integer
' Will not compile: error is 'Constant expression not representable in
type Integer'

So here, the VB.NET compiler can work out at compile time that 3
billion is bigger than an Int32, and thus can't be used as an array
size (a CLS limitation I would suspect); but the C# compiler can't, or
doesn't care.

Your particular example can be examined also:

C#
long l = 3000000000;
int[] f = new int[l];
// compiles, throws System.OverflowException at run time

VB.NET
Dim l As Long = 3000000000
Dim f(l) As Integer
' Will not compile under Option Strict On:
' error is 'Option Strict On disallows implicit conversions from
'<type1>' to '<type2>''
' WILL compile with Option Strict Off: throws System.OverflowException
at run time

So for me the question is, why does C# allow this unstated cast from
long to int to compile? To that end I have xposted to the C# group

 

[VJ]

Yea seems like at some point VB.NET is smarter or strict here... I took all
the trouble to move from VB to C# over last 2 years.. now you have given me
some reason to come back.. Actually speaking I should be a loyalist
here
for VB, because my initials are VB...

 

[Mike Schilling]

The confusion for me here is C-Sharp does not seem to complain. VB being
simple enough why is there this problem? Maybe they have not changed the
underlying type from VB??

It would appear this is one the very few times when VB.NET is stricter
than C#. To wit, and to recap for C#ers just joining us:

C#
int[] f = new int[3000000000];
// compiles, throws System.OverflowException at run time

VB.NET
Dim f(3000000000) As Integer
' Will not compile: error is 'Constant expression not representable in
type Integer'

So here, the VB.NET compiler can work out at compile time that 3
billion is bigger than an Int32, and thus can't be used as an array
size (a CLS limitation I would suspect); but the C# compiler can't, or
doesn't care.

Your particular example can be examined also:

C#
long l = 3000000000;
int[] f = new int[l];
// compiles, throws System.OverflowException at run time

VB.NET
Dim l As Long = 3000000000
Dim f(l) As Integer
' Will not compile under Option Strict On:
' error is 'Option Strict On disallows implicit conversions from
'<type1>' to '<type2>''
' WILL compile with Option Strict Off: throws System.OverflowException
at run time

So for me the question is, why does C# allow this unstated cast from
long to int to compile? To that end I have xposted to the C# group

There's no cast involved; the C# spec says, regarding the sizes used in
creating a new array: (section 7.5.10.2
Array creation expressions)

Each expression in the expression list must be of type int, uint, long,
or ulong, or of a
type that can be implicitly converted to one or more of these types

It also says it's a compile-time error if a constant expression evaluates to
a negative, but is silent about what happens if it evaluates to a number
that's too large. In fact, nothing I can see in the spec refers to the
largest possible size of an array being limited to what fits in an int.
Apparently the language has no such restriction.

 

[Jon Skeet [C# MVP]]

There's no cast involved; the C# spec says, regarding the sizes used in
creating a new array: (section 7.5.10.2
Array creation expressions)

Each expression in the expression list must be of type int, uint, long,
or ulong, or of a
type that can be implicitly converted to one or more of these types

It also says it's a compile-time error if a constant expression evaluates to
a negative, but is silent about what happens if it evaluates to a number
that's too large. In fact, nothing I can see in the spec refers to the
largest possible size of an array being limited to what fits in an int.
Apparently the language has no such restriction.

Having looked at the generated code, it looks like it will overflow on
a 32-bit system, but not on a 64-bit system. A conv.of.i instruction is
used, which converts to a native int and throws an exception if the
value is too large to be stored in a native int.

So, I think you could look at this in two ways. VB.NET stops you making
silly mistakes on 32-bit systems, but prevents you from creating arrays
of more than 2GB on 64-bit systems. C# does the reverse. Personally, on
this matter I think I prefer the VB.NET approach.

I'll raise this as a point of ambiguity in the spec though.

 

[Willy Denoyette [MVP]]

| > > So for me the question is, why does C# allow this unstated cast from
| > > long to int to compile? To that end I have xposted to the C# group
| >
| > There's no cast involved; the C# spec says, regarding the sizes used in
| > creating a new array: (section 7.5.10.2
| > Array creation expressions)
| >
| > Each expression in the expression list must be of type int, uint,
long,
| > or ulong, or of a
| > type that can be implicitly converted to one or more of these types
| >
| > It also says it's a compile-time error if a constant expression
evaluates to
| > a negative, but is silent about what happens if it evaluates to a number
| > that's too large. In fact, nothing I can see in the spec refers to the
| > largest possible size of an array being limited to what fits in an int.
| > Apparently the language has no such restriction.
|
| Having looked at the generated code, it looks like it will overflow on
| a 32-bit system, but not on a 64-bit system. A conv.of.i instruction is
| used, which converts to a native int and throws an exception if the
| value is too large to be stored in a native int.
|
| So, I think you could look at this in two ways. VB.NET stops you making
| silly mistakes on 32-bit systems, but prevents you from creating arrays
| of more than 2GB on 64-bit systems. C# does the reverse. Personally, on
| this matter I think I prefer the VB.NET approach.
|

Managed Array's (just like any other object)are limited to 2GB anyway, also
on 64bit windows.

Willy.

 

[Jon Skeet [C# MVP]]

| So, I think you could look at this in two ways. VB.NET stops you making
| silly mistakes on 32-bit systems, but prevents you from creating arrays
| of more than 2GB on 64-bit systems. C# does the reverse. Personally, on
| this matter I think I prefer the VB.NET approach.

Managed Array's (just like any other object)are limited to 2GB anyway, also
on 64bit windows.

Hmm... that may be a limitation of .NET rather than the CLI spec
though. The CLI spec states that the newarr instruction take a number
of elements which is of type native int - and doesn't specify any
limit.

It could be that while current implementations have more restrictions,
a future implementation may be able to create larger arrays.

Of course, it could equally be two different people on the spec writing
team who didn't talk to each other quite enough...

 

[Willy Denoyette [MVP]]

| > | So, I think you could look at this in two ways. VB.NET stops you
making
| > | silly mistakes on 32-bit systems, but prevents you from creating
arrays
| > | of more than 2GB on 64-bit systems. C# does the reverse. Personally,
on
| > | this matter I think I prefer the VB.NET approach.
| >
| > Managed Array's (just like any other object)are limited to 2GB anyway,
also
| > on 64bit windows.
|
| Hmm... that may be a limitation of .NET rather than the CLI spec
| though. The CLI spec states that the newarr instruction take a number
| of elements which is of type native int - and doesn't specify any
| limit.
|

Actually it says "native int or int32", which is rather confusing IMO, and I
noticed that it's an int32 even on the 64-bit CLR.


| It could be that while current implementations have more restrictions,
| a future implementation may be able to create larger arrays.
|

Sure, it's a .NET limitation, it's possible that the next version of the CLR
supports a larger value, but as far as I know nothing like this has been
announced publically.

| Of course, it could equally be two different people on the spec writing
| team who didn't talk to each other quite enough...
|

I don't think so. IMO the limitation is a conscious design decision. Imagine
what happens on a system when a single application allocates a single 8GB
array (contigious memory) and starts to access it in a sparse/random order,
you'll end in a world of pain unless you have a ton of physical memory
available.

Willy.

 

[Jon Skeet [C# MVP]]

| Hmm... that may be a limitation of .NET rather than the CLI spec
| though. The CLI spec states that the newarr instruction take a number
| of elements which is of type native int - and doesn't specify any
| limit.

Actually it says "native int or int32", which is rather confusing IMO, and I
noticed that it's an int32 even on the 64-bit CLR.

Perhaps we're looking at different specs, or different places? I was
looking at partition 3 of the ECMA spec, in the definition of newarr.
It's rather odd.

| It could be that while current implementations have more restrictions,
| a future implementation may be able to create larger arrays.

Sure, it's a .NET limitation, it's possible that the next version of the CLR
supports a larger value, but as far as I know nothing like this has been
announced publically.

Right. My guess is that in 10 years time the limitation might seem
somewhat severe - although I would have thought that the spec could
have been expanded at that time.

| Of course, it could equally be two different people on the spec writing
| team who didn't talk to each other quite enough...

I don't think so. IMO the limitation is a conscious design decision. Imagine
what happens on a system when a single application allocates a single 8GB
array (contigious memory) and starts to access it in a sparse/random order,
you'll end in a world of pain unless you have a ton of physical memory
available.

But that situation may well be reasonably common in 10 years.

Put it this way - future expansion is the only reason I can see for
array lengths being allowed to be longs in C#.