encryption

#11

And the REALLY old programmers still use

i = 0
10 i = i + 1
if i > 100 goto 20
blah blah
goto 10
20 *

That's all the FOR/NEXT does anyway. Good code, except, of course, for
those dreaded GOTOs.

Mark Brown

"murthi" <c_xyz_murthi (AT) seeing_xyz_green (DOT) net> wrote

Quote:

Though of course, for us unreconstructed old assembly programmers, we note
that many Pick systems optimize Fors with an implict step of 1, ie:

FOR i = 1 TO 100 is different than FOR i = 1 TO 100 STEP 1 or FOR i =100
TO 1 STEP -1.

Saves ya a few nanoseconds!

Chandru

"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote in message
news:1122338781.465156.16930 (AT) g49g2000cwa (DOT) googlegroups.com...
And/or a 'trick?' I recently picked up, if you LIKE the idea of having
a LEN() in the loop, change the structure so it is

FOR CharCnt = LEN(inString) to 1 step -1

This way the LEN() is only executed once ... provided the order that
you traverse doesn't matter. Ditto for DCOUNTS etc

#12

Douglas:

Thanks for the heads up. :-)

Bill

<douglas (AT) pickteam (DOT) com> wrote

Quote:

Wouldn't it be better to not do the LEN every tiem the loop executes?

/just asking

#13

"Bill H" wrote

Quote:

Bob:

Try the following, encryption code courtesy of Mark Brown. Hope this helps.

snip source code

It looks like the encrypted text might take on any characters whatsoever;
does D3 barf much handling the segment marks <<CHAR(255)>> that must
come up from time to time? In other words, are there any D3
verbs you've had to avoid using with encrypted items?

#14

The U9D decryption/decription code is designed for encrypting single
"values", not strings with embedded delimiters. However...

Depending on the SEED you use, and the data you are encrypting, there
generally isn't any problem.

Any character < char(127), even doubled, won't produce a segment mark. But
if you're encrypting delimiters using low-value seed characters you could
have a problem. Or if you're using a 2- or 3-lock-box approach, where you
encrypt data with a seed, bury the seed in with the data and encrypt it
again for transmission, then there can be problems. But I have successfully
demonstrated 3-lock-box encoded data that (virtually) cannot be broken.

D3 will definitely terminate any string with an embedded segment mark,
losing all subsequent data in the string.

Try to avoid stuff like:

seed = char(2):char(3):char(4)
data = "now is the time":svm:"for all good men"
x = iconv(seed:@am:data,"u9d")

that will cause problems.

Mark Brown

"Frank Winans" <fwinans (AT) sbcglobal (DOT) net> wrote

Quote:

"Bill H" wrote
Bob:

Try the following, encryption code courtesy of Mark Brown. Hope this
helps.

snip source code

It looks like the encrypted text might take on any characters whatsoever;
does D3 barf much handling the segment marks <<CHAR(255)>> that must
come up from time to time? In other words, are there any D3
verbs you've had to avoid using with encrypted items?

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

encryption

comp.databases.pick comp.databases.pick

Re: encryption - 07-26-2005 , 11:46 AM

Re: encryption - 07-26-2005 , 01:02 PM

Re: encryption - 07-26-2005 , 03:43 PM

Re: encryption - 07-26-2005 , 04:05 PM