XOR operator

  • Thread starter Thread starter JJK
  • Start date Start date
J

JJK

I'd tried to port an application from vb6 to vb.net 2003. While testing is
I'd got a error in the XOR operator. This is an example:
dim c as Byte
....
mask = 190
Fileget(1,c)
c = c XOR mask
Fileput(2,c)

Run 1:
FileGet (1,c)
c = 77
c = c xor mask
c = 137
FilePut(2,c)

Run 2:
mask = 190
FileGet(1,c)
c = 137 ' That is OK
c = c XOR mask
c = 143 ' That is NOT my intention. I would it be 77 again
FilePut(1,c)


In vb6 I'd got in the second run as result of c = c Xor mask, c = 77 again
What is the matter?
 
JJK,
You do realize that:
Run 1:
c = 77
c = c xor mask
c = 137
Click to expand...

77 xor 190 = 243

And that:

243 xor 190 = 77

Where and how are you getting 137?

Hope this helps
Jay
 
I'm sorry, but I'd made a mistake in my initial question. This is what is
has to be:

mask = 190
Fileget(1,c)
'Here is c 44, and it is a character from a file ;-)
c = Asc(c) XOR mask
'And here I find c is truly 137.
Fileput(2,c)

Where in the 2nd run the files 1 and 2 has changed seats.
I'd tried it again and I got the same results as in my initial question.

The meaning is that this initial c value from the 1st run in the 2nd run the
same is as the result of:
c1st = 77 and
c2nd = Asc(c) Xor mask = 77 again.

If you have any questions about this, feel free to ask them, of course.

I hope you could help me any further.

Thanks in advance,

JJK
 
JJK,
c = Asc(c) XOR mask
Click to expand...

Why are you applying the Asc function to a Byte? "c" was byte in your
original post!

It looks like you are getting caught up in some strange Encoding/Decoding
problem/confusion.

Remember that Asc does decoding of a Char based on the current
TextInfo.ANSICodePage. I suspect (have not verified) that you do not have
Option Strict On, and that when you then assign this integer back to the
Char (if c is now a Char) that is is using ChrW which converts the char
based on Unicode. Any character above 128 is not the same in the ANSI code
page & the Unicode code page, which means that Asc will "shift" the value
for you...

I would strongly recommend you always run with Option Strict On, which means
you will also need to include the Chr function on your Xor mask statement if
you include the Asc function. This also means you will need to define c for
what it really is a Byte or a Char.

Hope this helps
Jay
 
I realized it me too when thinking about his problem. But your answer gives
me a confirmation of my thaughts, so that helped me very much. I'll try to
remove this from my algorithm. I'll place the results in the group.

Thank you very much,

JJK
 
I'm sorry, im the previous post I forgot to give an answer on your
questions:
1. I still didn't use Option Strict, but I'd changed it. I thought it was
standard on, but do you know if it is possible to set it standard on in
every new project, because I cloudn't find it in the Tools => Options...
menu.

I hope you does know this.

JJK
 
I tried to use the Strict On function, but then a got errors about implicit
type conversion. I had tried to dim the variables as the same as the result,
but than I got an error about buffer overflow, while using a file. What is
my fault?

JJK
 
JJK,
Use Option Strict On, use the proper conversion functions to convert from
one type to another. The conversion functions include, but are not limited
to, CByte, CInt, CChar, ChrW, AscW...

Based on your prevous posts I really do not know what you are attempting tod
do as you have only posted partial code fragments, that rely heavily on
implicit conversions, implicit conversions lead to problems, such as the one
you are currently having.

Be more specific on what exactly you are attempting to do, then I or someone
else should be able to help you.

Hope this helps
Jay
 
JJK said:
I know it, and I'll do it next time. I had thaught about posting the full
sourcecode, but that should cause a serious security issue. I was writing a
port of an encryption program.
Click to expand...

Posting the source code of an encryption scheme should never cause a
security issue. If the security of your encryption relies on people not
knowing the algorithm you've used, you basically don't *have* security
- it's easy enough to decompile code (native or managed) and find out
the algorithm. The algorithm itself should ensure the security.
 
Back
Top