Here's another....file I/O difficulties. - Printable Version +- Qbasicnews.com (http://qbasicnews.com/newforum) +-- Forum: Qbasic "like" compilers/interpreters (http://qbasicnews.com/newforum/forum-5.html) +--- Forum: FB Discussion & Programming Help (http://qbasicnews.com/newforum/forum-15.html) +--- Thread: Here's another....file I/O difficulties. (/thread-8714.html) |
Here's another....file I/O difficulties. - Moneo - 01-12-2006 Stylin: The new code now works fine, matching the Winer encrypted text. Nice job, and nice explanation. The business of chr$(0) terminating a string in FB, is a sticky wicket. Others who have not considered this, like you have, could have problems with strings whose bytes can be modified by bitwise operations. The worst part is that they may work most of the time and then suddenly... ***** Here's another....file I/O difficulties. - Zack - 01-12-2006 Thanks for the explanation. I remember a bit of that from C. If you ask me, FB ought to have a way to declared fixed-length strings, regardless of CHR$(0) terminators. ZSTRING*n can almost do this, but still uses CHR$(0). Here's another....file I/O difficulties. - stylin - 01-12-2006 Quote:Thanks for the explanation.You can declare fixed-length strings, but I think the issue here might be a bug: notice that passing a string by value (making a copy of it) acts differently than initializing a new string with a reference value (making a copy of it). I'm going to ask @ fb.net and see what the deal is. Here's another....file I/O difficulties. - stylin - 01-12-2006 Sorry for the double-post. For those interested: How strings get passed by value So, it seems that null-spersed-strings passed by value get truncated "by design", since a pointer is passed instead of the descriptor - which means we no longer have explicit length information; length must be determined incrementally - thus the truncation. Moral of the story: for strings that may possibly contain a null character, pass by reference (if you can't safely ignore truncation). For non-modifiable strings that are guaranteed not to have a null character, pass by value, otherwise pass by reference. (if you're passing a string by reference and you don't want it modified [text, key, for example], prefer to create a local copy [result] and only use that copy throughout the function. update: the above behavior will be changing in an indefinent amount of time . strings passed by value will be deep-copied instead of having an address passed instead. happy happy, joy joy Here's another....file I/O difficulties. - stylin - 01-14-2006 Zack, you've gotten me hooked on neat little encryption methods. Here's one I just finished. It's sort of like a combination of your original algorithm, with Winer's. Here's the procedure: Code: '' original Code: option explicit Here's another....file I/O difficulties. - Moneo - 01-15-2006 Albert Einstein said: "We need to make things simple, but not simpler". ***** Here's another....file I/O difficulties. - Zack - 01-15-2006 Wicked. :o I wonder how easy it is to crack XOR encryption. I used to send my encrypted files to a buddy of mine and he'd always be able to crack them. Here's another....file I/O difficulties. - red_Marvin - 01-15-2006 If you use a key that is as long as the message I think it would be impossible. Here's another....file I/O difficulties. - Zack - 01-16-2006 Interesting...imagine encrypting a file with another file of equal length. Or a string. I suppose the only risk would be someone getting their hands on the password string. Here's another....file I/O difficulties. - DrV - 01-16-2006 That'd essentially be a one-time pad - unbreakable encryption. However, both parties would need to get the password, which is a problem sometimes. |