A couple of semantic questions...

[Jonathan Allen]

> Exposing them in a public method's
> signature is what you want to avoid

You know darn well that's what I meant.

--
Jonathan Allen


"Jeff Peil" <jpeil@bigfoot.com> wrote in message
news:3a79f6a1$1@news.devx.com...
>
> "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
> news:3a79ebe7@news.devx.com...
> > FYI: Unsigned integers are not CLS compliant, so you shouldn't use them
in
> > public methods.
>
> Jonathan,
>
> Using them in a public method is fine. Exposing them in a public method's
> signature is what you want to avoid (and more specifically you can still
do
> that, but if you do, and you want the class to be cls compliant that
method
> needs to be specifically marked as not being cls compliant, and you should
> consider providing an alternative method that would be useful for
languages
> that cannot use unsigned types.)
>
>

[Jeff Peil]

"Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
news:3a7a143e@news.devx.com...
> > Exposing them in a public method's
> > signature is what you want to avoid
>
> You know darn well that's what I meant.
>

Jonathan,

While I figured you had meant to say that, however not everyone who read
your message would know that,so it seemed worth correcting for the benefit
of other people who read this group...it was not meant as a personal attack

[Jonathan Allen]

See everybody, I was right. He did know what I was talking about, even if no
one else did.

--
Jonathan Allen


"Jeff Peil" <jpeil@bigfoot.com> wrote in message
news:3a7a4bfd$1@news.devx.com...
>
>
> Jonathan,
>
> While I figured you had meant to say that, however not everyone who read
> your message would know that,so it seemed worth correcting for the benefit
> of other people who read this group...it was not meant as a personal
attack
>
>

[Eric Gunnerson]

As I said, operators like int are only defined for int, uint, long, and
ulong. Your example will result in an int.

Many would argue that it *should* produce an int, since 40000 + 40000 is not
a ushort value.

"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3a79df5f@news.devx.com...
> Eric,
>
> > If you search through the language ref, you'll find that the operators
> +, -,
> > *, and / are only defined for certain variable types. 7.7.5 says that
the
> > only versions of subtraction available require one of (int, int), (uint,
> > uint), (long, long), or (ulong, ulong). Since 1 is an int, you'll get an
> int
> > result, and you can't get from that back to i without an explicit cast.
>
> I was seeing the same error with this:
>
> ushort i = 1;
> ushort j = 2;
>
> i = i + j;
>
> That shouldn't require a cast.
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
>

[Eric Gunnerson]

"Sean Woods" <sdwood@ieee.org> wrote in message
news:3a7a06c1@news.devx.com...
> "Eric Gunnerson" <ericgu@no.spam.microsoft.com> wrote in message
> news:3a79d4ac@news.devx.com...
> > There's no nice way around it with different specifications; even if you
> > specify 1 as an unsigned value '1u', you're still not going to be
> converting
> > it implicitly back to a ushort. The fix is to use an int instead of a
> > ushort; in C#, int is a much more natural type, and this is true in the
> > frameworks as general. C# has unsigned types, but you would usually
choose
> > the signed version by default, and rarely go below an int in size.
>
> Unfortunately I am working with a situation (strong encryption) that
> requires the variables to be a certain size. I am not so much interested
in
> a ushort as I am in something that holds 16 bits and treats them as
unsigned
> in regard to shift operations. So using an int it out... I guess I will
> just be decorating my code with lots of explicit casts.
>
> > sizeof() is unsafe because the only times you need to know that
> information
> > are in unsafe contexts.
>
> I am not sure I agree. While sizeof may have uses in unsafe contexts it
> comes in handy when performing encryption. There are uses beyond working
> with pointers. But, I am not so much concerned with it being unsafe.
>
> I still would be curious as to how to determine the number of bytes a
> varible is occupying at runtime. It seems one of the following would be
> most logical, but they give compiler errors.
>
> Either
> ushort t = 5;
> sizeof(t.GetType());
> or even nicer would be
> object t = (ushort)5;
> sizeof(t.GetType());
>
> > > public class SecBlock
> > > {
> > > private ushort size;
> > > private Array ptr;
> > >
> > > public SecBlock(ushort size, Type t)
> > > {
> > > this.size = size;
> > > ptr = Array.CreateInstance(t, size);
> > > }
> > >
> > > public object this[ushort column]
> > > {
> > > get
> > > {
> > > return ptr[column];
> > > }
> > > set
> > > {
> > > ptr[column] = value;
> > > }
> > > }
> > > }
> >
> > You should just use an object[] instead of trying to be tricky. Since
your
> > indexer is of type object, you aren't gaining anything by trying to have
> > another type of array internally.
>
> So what you are saying is in the above I should simply declare ptr like
> this:
> private object ptr;

No

private object[] arr;

>
> And then in the constructor for the class I can still do this:
> ptr = Array.CreateInstance(t, size);

arr = new object[size];

>
> But trying that just leads to "(20): Cannot apply indexing with [] to an
> expression of type 'object'." Which is exactly the same thing I get when
I
> use Array in the declaration. If I use object[] in the declaration then
> what I end up with is "(13): Cannot implicitly convert type 'System.Array'
> to 'object[]'."
>
> So how can I declare the array as an array of objects, let the user decide
> the type that the array will hold at run time and then ensure that type
goes
> in there.

If you create an array of objects, an element can hold *any* type the user
could ever specify.

>
> In essence what I am looking for here is a way to set aside a block of
> memory that could either hold bytes, ushorts, uints, or ulongs.

Well, in that case you're dealing with value types, and there isn't a
general way to write the routine in C#. What you need are parameterized
types, which won't be in the first version of the language.

Efficiency aside, couldn't you just create an array of ulongs?


> These
> blocks will be holding sensitive stuff. And as soon as the user knows
that
> they are done with that block then a dispose method would come through and
> over write that block with 0s.

[Jonathan Wood]

Eric,

> As I said, operators like int are only defined for int, uint, long, and
> ulong. Your example will result in an int.

I understand what you are saying. My point is "why?" Whether the solution is
to convert implicitly or to define those operators for other types such as
ushort, I'm not sure. Being familiar with a number of different languages,
that just does not seem right to me.

BTW, I'm working my way through your book. Good timing, eh? The product
isn't even available yet. Unfortunately, what I really need is a book on the
frameworks. I have too many questions on how to do this or that and the
online help is proving nearly impossible to answer those type of questions.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Jonathan Allen]

> I understand what you are saying. My point is "why?"

I don't think they intend for you to use unsigned integers in calculations.
The only reason they even exist may be for use with legacy code.

--
Jonathan Allen


"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3a7b11c7@news.devx.com...
> Eric,
>
> > As I said, operators like int are only defined for int, uint, long, and
> > ulong. Your example will result in an int.
>
> I understand what you are saying. My point is "why?" Whether the solution
is
> to convert implicitly or to define those operators for other types such as
> ushort, I'm not sure. Being familiar with a number of different languages,
> that just does not seem right to me.
>
> BTW, I'm working my way through your book. Good timing, eh? The product
> isn't even available yet. Unfortunately, what I really need is a book on
the
> frameworks. I have too many questions on how to do this or that and the
> online help is proving nearly impossible to answer those type of
questions.
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
>

[Jonathan Wood]

Jonathan,

> I don't think they intend for you to use unsigned integers in
calculations.
> The only reason they even exist may be for use with legacy code.

Ack! No adding unsigned numbers, eh? What's the point then?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com

[Eric Gunnerson]

"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3a7b11c7@news.devx.com...
> Eric,
>
> > As I said, operators like int are only defined for int, uint, long, and
> > ulong. Your example will result in an int.
>
> I understand what you are saying. My point is "why?" Whether the solution
is
> to convert implicitly or to define those operators for other types such as
> ushort, I'm not sure. Being familiar with a number of different languages,
> that just does not seem right to me.

On most "modern" architectures, your perf is better is your using int or
bigger.

Because of the way the type system is defined, if you add operators for
additional types, you end up with some really ugly ambiguities.

>
> BTW, I'm working my way through your book. Good timing, eh? The product
> isn't even available yet. Unfortunately, what I really need is a book on
the
> frameworks. I have too many questions on how to do this or that and the
> online help is proving nearly impossible to answer those type of
questions.

Agreed. I wish *I* had a book on the frameworks. The msnews.microsoft.com
newsgroups are an okay place to start, however.

[Jonathan Allen]

> Ack! No adding unsigned numbers, eh? What's the point then?

Like I said, it looks like it is mainly for talking to legacy code. Unsigned
integers (as arguments) are usually used for bit flags and handles, neither
of which need addition. But really this is all conjuncture, some guy at MS
may just hate unsigned integers.

--
Jonathan Allen


"Jonathan Wood" <jwood@softcircuits.com> wrote in message
news:3a7b18b1@news.devx.com...
> Jonathan,
>
> > I don't think they intend for you to use unsigned integers in
> calculations.
> > The only reason they even exist may be for use with legacy code.
>
> Ack! No adding unsigned numbers, eh? What's the point then?
>
> --
> Jonathan Wood
> SoftCircuits Programming
> http://www.softcircuits.com
>
>

[Sean Woods]

Eric Gunnerson <ericgu@no.spam.microsoft.com> wrote in message
news:3a7b0f32$1@news.devx.com...
> Well, in that case you're dealing with value types, and there isn't a
> general way to write the routine in C#. What you need are parameterized
> types, which won't be in the first version of the language.

Indeed, the C++ code that I have been trying to see if I could recode in C#
(as my test of C#) uses generics in this case. I was hoping I could find a
work around, but it appears that generics really is the best way to do what
I am wanting done, and so I will wait to the MS research teams comes up with
the next version of C# that includes generics.

> Efficiency aside, couldn't you just create an array of ulongs?

No... Like I said... I need something that holds 16 bits (or 32 bits)
explicitly. And treats them as unsigned with respect to shifts and rotates.

But, it doesn't really matter... My littling porting effort has shown me the
pitfalls that I will need to watch out for in C#. Instead of trying to port
the entire crypto library that I was working on I will probably just focus
my efforts on extending the Security.Cryptography classes to include more
modern crypto algorithms. While I think the crypto library I was working
with has a slightly better object model, the one under Security.Cryptography
is substantially better than CryptoAPI and if worth extending.

So my only question now is... does .NET have rotate instructions? These are
easily implmented with shifts, but if they are already availible then no
sense in recreating them. When I look in the documentation the only ones
they bring up are the _lrotl and _lrotr instructions from C++.

Thanks

Sean

[Jonathan Allen]

> Indeed, the C++ code that I have been trying to see if I could recode in
C#
> (as my test of C#) uses generics in this case.

If you are going to be twiddling bits and such, you might as well leave it
as a C++ project and just add managed extensions to it. Cryptography is best
left to systems languages like C++, not glue languages like C# and VB.Net.

--
Jonathan Allen

"When considering performance, one must rate accuracy over speed. No one
cares how fast you can give the wrong answer." - Anonymous


"Sean Woods" <sdwood@ieee.org> wrote in message
news:3a7f0d60@news.devx.com...
> Eric Gunnerson <ericgu@no.spam.microsoft.com> wrote in message
> news:3a7b0f32$1@news.devx.com...
> > Well, in that case you're dealing with value types, and there isn't a
> > general way to write the routine in C#. What you need are parameterized
> > types, which won't be in the first version of the language.
>
> Indeed, the C++ code that I have been trying to see if I could recode in
C#
> (as my test of C#) uses generics in this case. I was hoping I could find
a
> work around, but it appears that generics really is the best way to do
what
> I am wanting done, and so I will wait to the MS research teams comes up
with
> the next version of C# that includes generics.
>
> > Efficiency aside, couldn't you just create an array of ulongs?
>
> No... Like I said... I need something that holds 16 bits (or 32 bits)
> explicitly. And treats them as unsigned with respect to shifts and
rotates.
>
> But, it doesn't really matter... My littling porting effort has shown me
the
> pitfalls that I will need to watch out for in C#. Instead of trying to
port
> the entire crypto library that I was working on I will probably just focus
> my efforts on extending the Security.Cryptography classes to include more
> modern crypto algorithms. While I think the crypto library I was working
> with has a slightly better object model, the one under
Security.Cryptography
> is substantially better than CryptoAPI and if worth extending.
>
> So my only question now is... does .NET have rotate instructions? These
are
> easily implmented with shifts, but if they are already availible then no
> sense in recreating them. When I look in the documentation the only ones
> they bring up are the _lrotl and _lrotr instructions from C++.
>
> Thanks
>
> Sean
>
>

[Sean Woods]

Jonathan Allen <greywolfcs@bigfoot.com> wrote in message
news:3a7f2990@news.devx.com...
> > Indeed, the C++ code that I have been trying to see if I could recode in
> C#
> > (as my test of C#) uses generics in this case.
>
> If you are going to be twiddling bits and such, you might as well leave it
> as a C++ project and just add managed extensions to it. Cryptography is
best
> left to systems languages like C++, not glue languages like C# and VB.Net.

Yeah... But at the time it seemed the best test case for a "how much trouble
might I really run into using C#" test. In truth, the three problems I ran
into would not discourage me from using C# in place of C++ even for crypto.
The case where generics were used above was to implement "secure memory"
that wiped its self before it was destroyed. That is easy enough to do in
C# simply by calling the .Clear() on an array before it goes out of scope.
The problem I had with sizeof() was tiny... I only used it in the C++ code
because of the use of generics. The addition of two ushorts yielding an int
still seems wrong to me. I would prefer to be told that there was an
overflow by exception rather than check it myself, but since the compiler
gives me the nice warning about doing the implicit conversion it is simple
enough to load up on explicit conversions to get things done.

Was the .NET framework written in C, C++, C#, or a mix? Just curious if MS
did the Security.Cryptography classes in C++ or C#? My suspicion is C++
simply because they didn't expose any rotate commands which they would have
to of written in C#, but with C++ the could simply call Intel intrinsics to
get the job done.

[Jonathan Allen]

> Was the .NET framework written in C, C++, C#, or a mix?

Some things, like the VB compatibility dll, were written in VB.Net. However,
most of it is mix of C++ and C#.

--
Jonathan Allen

"When considering performance, one must rate accuracy over speed. No one
cares how fast you can give the wrong answer." - Anonymous


"Sean Woods" <sdwood@ieee.org> wrote in message
news:3a7f2e1a$1@news.devx.com...
> Jonathan Allen <greywolfcs@bigfoot.com> wrote in message
> news:3a7f2990@news.devx.com...
> > > Indeed, the C++ code that I have been trying to see if I could recode
in
> > C#
> > > (as my test of C#) uses generics in this case.
> >
> > If you are going to be twiddling bits and such, you might as well leave
it
> > as a C++ project and just add managed extensions to it. Cryptography is
> best
> > left to systems languages like C++, not glue languages like C# and
VB.Net.
>
> Yeah... But at the time it seemed the best test case for a "how much
trouble
> might I really run into using C#" test. In truth, the three problems I
ran
> into would not discourage me from using C# in place of C++ even for
crypto.
> The case where generics were used above was to implement "secure memory"
> that wiped its self before it was destroyed. That is easy enough to do in
> C# simply by calling the .Clear() on an array before it goes out of scope.
> The problem I had with sizeof() was tiny... I only used it in the C++ code
> because of the use of generics. The addition of two ushorts yielding an
int
> still seems wrong to me. I would prefer to be told that there was an
> overflow by exception rather than check it myself, but since the compiler
> gives me the nice warning about doing the implicit conversion it is simple
> enough to load up on explicit conversions to get things done.
>
> Was the .NET framework written in C, C++, C#, or a mix? Just curious if
MS
> did the Security.Cryptography classes in C++ or C#? My suspicion is C++
> simply because they didn't expose any rotate commands which they would
have
> to of written in C#, but with C++ the could simply call Intel intrinsics
to
> get the job done.
>
>