Computer Science Canada Encryption |
Author: | Tallguy [ Fri Nov 18, 2011 2:00 pm ] | ||||
Post subject: | Encryption | ||||
hello, hello So what i need help is - we are doing a simple encryption program where the user in COMMAND LINE arguments (-d/-h etc) then have a key # for encryption (21,30 etc) and the CMD would look like..
the # is how many roll overs we have to the char hex vaule (A => F with a key of 5 (65=>70)) I have the arguments done, the issue i have is when i open the file with the initial text (called test.txt for me), i cant CLOSE the read file, it just spits out random characters that i have no idea where its coming from. and never goes into my for loop..
|
Author: | DemonWasp [ Fri Nov 18, 2011 2:09 pm ] |
Post subject: | RE:Encryption |
Err...why are you trying to open a file entitled " ", rather than the "test.txt" file name you mentioned earlier? It doesn't look like your code ever captures the file name given as an argument, never mind actually using it. |
Author: | Tallguy [ Fri Nov 18, 2011 2:14 pm ] |
Post subject: | RE:Encryption |
whoops..i tried it severally diff ways, when i have "test.txt" i get "this is a sentence? ??a?0??a?0??a???$?;VZc" 'this is a sentence' is what is inside the .txt file, but i have ZERO print statements for it ?? |
Author: | DemonWasp [ Fri Nov 18, 2011 2:32 pm ] | ||
Post subject: | RE:Encryption | ||
You never open() fout, which means that the value is garbage from the stack. There are a number of hard-numbered "files" that can be accessed, such as stdin / stdout / stderr, so I suppose it's possible--though unlikely--that you're getting 1 (stdout) or 2 (stderr). It's also possible that if the file descriptor is invalid then it gets piped to stderr (though, why anyone would want that is beyond me). Then, there's also the problem that you never check exactly how many bytes are read. Since your file is considerably smaller than your buffer (19-22 bytes of file, 80 bytes of buffer), you should only be able to read that many bytes, even though you requested up to 80. The rest of your buffer is then filled with garbage (whatever happened to be in memory there last). When you write() 80 bytes from your buffer, it includes that garbage. As a general rule:
|
Author: | Tallguy [ Fri Nov 18, 2011 8:09 pm ] | ||||||||
Post subject: | Re: Encryption | ||||||||
thank you for your continually help..much appreciated so i strted over again to work at it in a different angle, i want to pass the arguments to separate functions (encrypt, decrypt etc) this is my input file
and code..
i keep getting 02_process.c:19: error: conflicting types for ?encrypt? /usr/include/unistd.h:586: error: previous declaration of ?encrypt? was here 02_process.c:97: error: conflicting types for ?encrypt? /usr/include/unistd.h:586: error: previous declaration of ?encrypt? was here and dont know why im passing
into
and getting an error? |
Author: | Tony [ Fri Nov 18, 2011 8:33 pm ] |
Post subject: | RE:Encryption |
1 - isn't argv of "const char *" type? 2 - you already have "encrypt" declared in an included file, causing conflicts |
Author: | DemonWasp [ Fri Nov 18, 2011 8:35 pm ] |
Post subject: | RE:Encryption |
This kind of error is pretty specific but not very intuitive. Here's what's going on: 1. You included <unistd.h> 2. In unistd.h, encrypt is defined as void encrypt(char block[64], int edflag) . 3. In your code, encrypt is defined as void encrypt (char *). 4. These are not equivalent declarations, so they cannot share the same name (in C*) 5. Since you have encrypt declared twice (once as a forward declaration), it complains about the same thing twice. * If you compile as C++, then you can do that, though I don't recommend that course of action. The simplest thing to do here is probably to rename your function to something that isn't already taken, such as shift_cipher_encrypt, which is what it looks like you're implementing. @Tony: no, argv is char **. In fact, it's acceptable practice for programs to change the value of argv[0] to change the name they appear to be running under; see this page, under the bit about Apple/Darwin specific extensions: http://en.wikipedia.org/wiki/Main_function#C_and_C.2B.2B |
Author: | Tallguy [ Fri Nov 18, 2011 8:53 pm ] |
Post subject: | RE:Encryption |
@DemonWasp i love you..just saying..will work on it and post final solution |
Author: | Tony [ Fri Nov 18, 2011 9:27 pm ] |
Post subject: | RE:Encryption |
@DemonWasp -- must have been thinking of something else. Thx. |
Author: | Tallguy [ Sat Nov 19, 2011 3:34 pm ] | ||
Post subject: | Re: Encryption | ||
the highest number i can encrypt to is 127, every # >127 is given a char value of '?' cant the ascii char go up to 255? <- may be smthing rly small ... |
Author: | Tony [ Sat Nov 19, 2011 4:08 pm ] |
Post subject: | RE:Encryption |
what is "count" supposed to be? I suspect that you want it to equal the return value of "read (fin,buffer,BUFFER_SIZE)" (why is that in the loop? If the file is larger than the buffer, it would simply overwrite the buffer) |
Author: | Tallguy [ Sat Nov 19, 2011 4:17 pm ] |
Post subject: | RE:Encryption |
count is the actually size of the contents of buffer, as it prop wont take the entire size of BUFFER_SIZE, then when i do a for loop up to content i see my actually data and not junk data that happens to be present |
Author: | Tony [ Sat Nov 19, 2011 4:41 pm ] |
Post subject: | RE:Encryption |
if I'm reading this code correctly: lets say you buffer size is 4 and the input file is "aaaab" (size 5) after first read: count = 1 buffer = "aaaa" after second read: count = 2 buffer = "baaa" (or "b\0aa", depending on what read does about terminating strings) after looking for NULL in buffer: count = 6 or 4 (depending if NULL is found or not) This is probably not what you are expecting. |
Author: | DemonWasp [ Sat Nov 19, 2011 4:46 pm ] |
Post subject: | Re: Encryption |
The reason that numbers beyond 127 display as '?' is that traditional ASCII is a 7-bit code, and only handles values 0 to 127. Values in the range 128-255 are only defined in extended-ASCII or other character encodings. Your terminal is probably UTF8, which means that while the first 127 characters are exactly the same as ASCII, the range 128-255 defines the start of a multi-byte character sequence. Don't worry about it too much: your cipher should be keeping letters in the range of printable, type-able ASCII characters (letters and numbers) anyway. Also, Tony is right: your count value is unhelpful. See the example from one of my previous posts -- you need to set count to the return value of the read method, not the number of times read() has been called. |
Author: | Tallguy [ Fri Nov 25, 2011 10:54 am ] |
Post subject: | RE:Encryption |
i'll repost code once i get it work properly... |
Author: | Tallguy [ Fri Nov 25, 2011 11:46 am ] | ||
Post subject: | Re: Encryption | ||
**Thank you all for your help**
-rly changed the way I was doing it -thanks you for patience -may still have a few bugs |