|
Getting a runtime error::"The instruction at 0x004010b4 referencedmemory at 0x00000000. The memory could not be read
Ok here is this program to compress a given file using run-length
encoding. This technique reduces the size of the file by replacing the original bytes with the repetition count and the byte to be repeated. Ex: if the file to be compressed starts with the following sequence of bytes:: 46 6F 6F 6F 2B 2B 9C 81 81 81 81 84 84 84 7A 7A 7A The compressed file will contain the following bytes:: 01 46 03 6F 02 2B 01 9C 04 81 03 84 03 7A And the output file will have a .rle extension along with the original file name that was provided when the program was run. here is the program i wrote::: #include <stdio.h> #include <stdlib.h> #include <ctype.h> #define MAXBUFF 5000 int main(int argc, char *argv[]) { FILE *fp,*gp; int ch, a[MAXBUFF],o[MAXBUFF],n=0,i,k; int *p=a,*r=a,*q=o; if(argc ==1) { fprintf(stderr,"Too few arguments"); exit(1); } if(fp=fopen(*++argv,"rb")==NULL) { fprintf(stderr,"Can't open file",*argv); exit(2); } if(gp=fopen(*argv[1]+".rle","wb")==NULL) { fprintf(stderr,"Can't open file"); exit(2); } while(fscanf(fp,"%.2X",&ch)==1) { *p++=ch; ++n; }*p='\0'; for(i=0;i<n;i++) { int j=*(r+i),m=0; for(k=0;k<n;k++) { if(j==*(r+k)) { ++m; } } *q++=m; *q++=j; }*q='\0'; while(*q!='\0') { putc(*q,gp); q++; } } It got compiled well but when i run it it gives me the following error::"The instruction at "0x004010b4" referenced memory at "0x00000000". The memory could not be read." Please help, i can't seem to figure it out |
Re: Getting a runtime error::"The instruction at 0x004010b4 referenced memory at 0x00000000. The memory could not be read
Maxx <grungeddd.maxx@gmail.com> wrote:
> Ok here is this program to compress a given file using run-length > encoding. This technique reduces the size of the file by replacing the > original bytes with the repetition count and the byte to be repeated. > Ex: if the file to be compressed starts with the following sequence of > bytes:: > 46 6F 6F 6F 2B 2B 9C 81 81 81 81 84 84 84 7A 7A 7A > The compressed file will contain the following bytes:: > 01 46 03 6F 02 2B 01 9C 04 81 03 84 03 7A Do you realize that in the worst possible case (when no bytes are ever repeated) this will result in a file twice as long as the original one? It looks as if you don't since your output buffer isn't larger than that for the input... There is also another case that you don't seem to consider: what do you do if there are more than 255 repetitions? > And the output file will have a .rle extension along with the original > file name that was provided when the program was run. here is the > program i wrote::: > #include <stdio.h> > #include <stdlib.h> > #include <ctype.h> > #define MAXBUFF 5000 > int main(int argc, char *argv[]) > { > FILE *fp,*gp; > int ch, a[MAXBUFF],o[MAXBUFF],n=0,i,k; > int *p=a,*r=a,*q=o; > if(argc ==1) > { > fprintf(stderr,"Too few arguments"); > exit(1); > } > if(fp=fopen(*++argv,"rb")==NULL) > { > fprintf(stderr,"Can't open file",*argv); > exit(2); > } > if(gp=fopen(*argv[1]+".rle","wb")==NULL) > { > fprintf(stderr,"Can't open file"); > exit(2); > } The problems with the above have already been pointed out, i.e. that you don't get any file pointers into 'fp' and 'gp' (the compiler should have warned you about that if you had used suitable warning flags...) That probably is already is the reason for the error message you got. But things don't get any better afterwards. > while(fscanf(fp,"%.2X",&ch)==1) I guess that should be while ( fscanf( fp, "%2X", &ch ) == 1 ) but then 'ch' should be an unsigned int - that's what you tell fscanf() via "%X". Of course, 'p' should then also be pointer to unsigned int and 'a' an array of unsigned ints. But the main problem would appear to be that you seem to be reading a binary file (or why open it explicitely with "rb"?) but you are reading it as if it would contain ASCII data, which is what fscanf() is meant for. If you want to read data from a binary file use fread(). > { > *p++=ch; > ++n; > }*p='\0'; How do you protect against reading more than MAXBUFF-1 times? You don't so there's no protection against writing past the end of the 'a' buffer. And what's it good for to append a 0 to the end? That looks like cargo-cult programming... Since you're done now with the input file you should close it now. > for(i=0;i<n;i++) > { > int j=*(r+i),m=0; > for(k=0;k<n;k++) > { > if(j==*(r+k)) > { > ++m; > } > } This has obvioulsy nothing to do with your stated goal of doing run-length encoding. You count here how often the value at position 'i' appears in _all_ of the buffer (and that for _all_ positions in the input buffer). To make any sense at all you would need something similar to for ( i = 0; i < n; i = k ) { int j = a[ i ], m = 1; for ( k = i + 1; k < n && j == a[ k ]; k++ ) m++; i = k; This stil doesn't address the problem of a byte being repeated more than 255 times, that would maje things a bit more interesting;-) Note that I use the original array 'a' instead of the extra pointer 'r' - using pointers just for the sake of using poin- ters won't magically make your program any faster or better in other respects, just harder to read. > *q++=m; > *q++=j; The way you have written the program the output buffer always needs to be twice as large as the input buffer... > }*q='\0'; > while(*q!='\0') > { > putc(*q,gp); > q++; > } > } Well, to begin with you start the loop with 'q' pointing to the last element written to (with 0), so this loop will never be run (you would need to reset 'q' first to point again to the start of the 'o' buffer). But also then this again would hardly any sense since you don't seem to grasp the difference between binary and ASCII data (putc() is for ASCII data, but you are dealing with bi- nary) it also fails because one of the data values in the output array could be 0, thus making you stop prematurely - adding a 0 at the end makes only sense when you're dealing with strings (which can't contain any '\0'), not for other data. And when you're done you should also close the output file and return an int from the program (either 0 or EXIT_SUCCESS would come to mind). Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
Re: Getting a runtime error::"The instruction at 0x004010b4referenced memory at 0x00000000. The memory could not be read
On Dec 24, 4:56*pm, Maxx <grungeddd.m...@gmail.com> wrote:
> * * * * if(fp=fopen(*++argv,"rb")==NULL) /* bug */ > [more code whose functionality, or lack thereof, > is irrelevant] My comment is intended not just for Maxx, but for Arnuld and a few others who post here. I've been programming for quite a while now, and make relatively few mistakes, yet I *STILL* will compile and run code before it's finished, just to do piecemeal verification. Perhaps I should be embarrassed to admit it, but sometimes I even have something like printf("Last arg is *%s*\n", argv[argc-1]); just to make sure I've not gone off-by-one somewhere. Yet we see complicated programs posted with the first line wrong! :-) Long ago I worked in a 24-hour turnaround environment: code as much as you can accurately in a day, and study the coredump because *you only get one compile-and-go per day!* Those days are gone now. Use the compiler interactively and let it be your friend! James Dow Allen |
Re: Getting a runtime error::"The instruction at 0x004010b4referenced memory at 0x00000000. The memory could not be read
On Dec 24, 2:05*am, Ered China Luin <chine.b...@yahoo.com> wrote:
> In article <f3324c5c-c33e-4edd-bed8-7f1c8fb16...@f20g2000prn.googlegroups..com>, > > *Maxx <grungeddd.m...@gmail.com> wrote: > > error::"The instruction at "0x004010b4" referenced memory at > > "0x00000000". The memory could not be read." > > You dereferenced a NULL. > > > * *if(fp=fopen(*++argv,"rb")==NULL) > > This is equivalent to > * * * * if ( fp = (fopen(*++argv,"rb")==NULL) ) > > You probably meant > * *if((fp=fopen(*++argv,"rb"))==NULL) > > > * *if(gp=fopen(*argv[1]+".rle","wb")==NULL) > > This adds two addresses instead of appending a string. To append a string you > have to allocate the string and then write into it. > > * * char name[strlen(argv[1])+5]; > * * sprintf(name, "%s.rle", argv[1]); > > and then as above > > * * if((gp=fopen(name,"wb"))==NULL) > > -- > Damn the living - It's a lovely life. * * * * * I'm whoever you want me to be. > Silver silverware - Where is the love? * * * At least I can stay in character. > Oval swimming pool - Where is the love? * *Annoying Usenet one post at a time. > Damn the living - It's a lovely life. * * *And All is vaneš the cock replied. Oh i get it, i forgot to put the braces. And that string concatenation was exactly the thing i was looking for.Thanks a lot |
Re: Getting a runtime error::"The instruction at 0x004010b4referenced memory at 0x00000000. The memory could not be read
On Dec 24, 3:23*am, j...@toerring.de (Jens Thoms Toerring) wrote:
> Maxx <grungeddd.m...@gmail.com> wrote: > > Ok here is this program to compress a given file using run-length > > encoding. This technique reduces the size of the file by replacing the > > original bytes with the repetition count and the byte to be repeated. > > Ex: if the file to be compressed starts with the following sequence of > > bytes:: > > 46 6F 6F 6F 2B 2B 9C 81 81 81 81 84 84 84 7A 7A 7A > > The compressed file will contain the following bytes:: > > 01 46 03 6F 02 2B 01 9C 04 81 03 84 03 7A > > Do you realize that in the worst possible case (when no bytes > are ever repeated) this will result in a file twice as long as > the original one? It looks as if you don't since your output > buffer isn't larger than that for the input... > > There is also another case that you don't seem to consider: what > do you do if there are more than 255 repetitions? > > > > > And the output file will have a .rle extension along with the original > > file name that was provided when the program was run. here is the > > program i wrote::: > > #include <stdio.h> > > #include <stdlib.h> > > #include <ctype.h> > > #define MAXBUFF 5000 > > int main(int argc, char *argv[]) > > { > > * * * * FILE *fp,*gp; > > * * * * int ch, a[MAXBUFF],o[MAXBUFF],n=0,i,k; > > * * * * int *p=a,*r=a,*q=o; > > * * * * if(argc ==1) > > * * * * { > > * * * * * * * * fprintf(stderr,"Too few arguments"); > > * * * * * * * * exit(1); > > * * * * } > > * * * * if(fp=fopen(*++argv,"rb")==NULL) > > * * * * { > > * * * * * * * * fprintf(stderr,"Can't open file",*argv); > > * * * * * * * * exit(2); > > * * * * } > > * * * * if(gp=fopen(*argv[1]+".rle","wb")==NULL) > > * * * * { > > * * * * * * * * fprintf(stderr,"Can't open file"); > > * * * * * * * * exit(2); > > * * * * } > > The problems with the above have already been pointed out, > i.e. that you don't get any file pointers into 'fp' and > 'gp' (the compiler should have warned you about that if > you had used suitable warning flags...) That probably is > already is the reason for the error message you got. But > things don't get any better afterwards. > > > * * * * while(fscanf(fp,"%.2X",&ch)==1) > > I guess that should be > > * * * * *while ( fscanf( fp, "%2X", &ch ) == 1 ) > > but then 'ch' should be an unsigned int - that's what you tell > fscanf() via "%X". Of course, 'p' should then also be pointer > to unsigned int and 'a' an array of unsigned ints. > > But the main problem would appear to be that you seem to be > reading a binary file (or why open it explicitely with "rb"?) > but you are reading it as if it would contain ASCII data, > which is what fscanf() is meant for. If you want to read data > from a binary file use fread(). > > > * * * * { > > * * * * * * * * *p++=ch; > > * * * * * * * * ++n; > > * * * * }*p='\0'; > > How do you protect against reading more than MAXBUFF-1 times? > You don't so there's no protection against writing past the > end of the 'a' buffer. And what's it good for to append a 0 to > the end? That looks like cargo-cult programming... > > Since you're done now with the input file you should close > it now. > > > * * * * for(i=0;i<n;i++) > > * * * * { > > * * * * * * * * int j=*(r+i),m=0; > > * * * * * * * * for(k=0;k<n;k++) > > * * * * * * * * { > > * * * * * * * * * * * * if(j==*(r+k)) > > * * * * * * * * * * * * { > > * * * * * * * * * * * * * * * * ++m; > > * * * * * * * * * * * * } > > * * * * * * * * } > > This has obvioulsy nothing to do with your stated goal of > doing run-length encoding. You count here how often the > value at position 'i' appears in _all_ of the buffer (and > that for _all_ positions in the input buffer). To make any > sense at all you would need something similar to > > * * * * * * for ( i = 0; i < n; i = k ) > * * * * * * { > * * * * * * * * *int j = a[ i ], > * * * * * * * * * * * * * * * * * * *m = 1; > * * * * * * * * *for ( k = i + 1; k < n && j == a[ k ]; k++ ) > * * * * * * * * * * * m++; > * * * * * * * * *i = k; > > This stil doesn't address the problem of a byte being > repeated more than 255 times, that would maje things a > bit more interesting;-) > > Note that I use the original array 'a' instead of the extra > pointer 'r' - using pointers just for the sake of using poin- > ters won't magically make your program any faster or better > in other respects, just harder to read. > > > * * * * * * * * *q++=m; > > * * * * * * * * *q++=j; > > The way you have written the program the output buffer always > needs to be twice as large as the input buffer... > > > * * * * }*q='\0'; > > * * * * while(*q!='\0') > > * * * * { > > * * * * * * * * putc(*q,gp); > > * * * * * * * * q++; > > * * * * } > > } > > Well, to begin with you start the loop with 'q' pointing > to the last element written to (with 0), so this loop > will never be run (you would need to reset 'q' first to > point again to the start of the 'o' buffer). > > But also then this again would hardly any sense since you > don't seem to grasp the difference between binary and ASCII > data (putc() is for ASCII data, but you are dealing with bi- > nary) it also fails because one of the data values in the > output array could be 0, thus making you stop prematurely - > adding a 0 at the end makes only sense when you're dealing > with strings (which can't contain any '\0'), not for other > data. > > And when you're done you should also close the output > file and return an int from the program (either 0 or > EXIT_SUCCESS would come to mind). > > * * * * * * * * * * * * * * Regards, Jens > -- > * \ * Jens Thoms Toerring *___ * * *j...@toerring.de > * *\__________________________ * * *http://toerring.de Yeah i was aware of the worst possible scenario. actually i found this program in that K. N. King c programming book, the best case and the worst case was pointed out by the author. and that 255 repetition thing could have sent my program haywire, i realized it afterwards. Actually i by binary i thought it included all types of files, more like a super-set.So i was aiming to read a pair of bytes("2X") from the input file and store them in a array. i should have used array indices there, my mistake, that would really be a lot easier. And thanks a lot for correcting the program. |
Re: Getting a runtime error::"The instruction at 0x004010b4referenced memory at 0x00000000. The memory could not be read
On Dec 24, 4:25*am, James Dow Allen <jdallen2...@yahoo.com> wrote:
> On Dec 24, 4:56*pm, Maxx <grungeddd.m...@gmail.com> wrote: > > > * * * * if(fp=fopen(*++argv,"rb")==NULL) /* bug */ > > *[more code whose functionality, or lack thereof, > > * is irrelevant] > > My comment is intended not just for Maxx, but for > Arnuld and a few others who post here. > > I've been programming for quite a while now, and make > relatively few mistakes, yet I *STILL* will compile > and run code before it's finished, just to do piecemeal > verification. *Perhaps I should be embarrassed to > admit it, but sometimes I even have something like > * * printf("Last arg is *%s*\n", argv[argc-1]); > just to make sure I've not gone off-by-one somewhere. > > Yet we see complicated programs posted with the > first line wrong! *:-) > > Long ago I worked in a 24-hour turnaround environment: > code as much as you can accurately in a day, and > study the coredump because *you only get one > compile-and-go per day!* *Those days are gone now. > Use the compiler interactively and let it > be your friend! > > James Dow Allen I'm very new in programming. only have been learning C past 2 months now. And these sort of mistakes keep coming up, although i try to correct most of the compiler errors but run time error drive me crazy, i just couldn't figure out how to solve it. Thanks to usenet and thanks to this group i started learning more about these errors and more about C |
Re: Getting a runtime error::"The instruction at 0x004010b4 referenced memory at 0x00000000. The memory could not be read
Maxx <grungeddd.maxx@gmail.com> wrote:
> Yeah i was aware of the worst possible scenario. actually i found this > program in that K. N. King c programming book, the best case and the > worst case was pointed out by the author. Well, when you're programming you always have to cater for the worst possible case, so if you know that the worst case is that the output buffer could potentially be twice as large as the input buffer then you need to make it twice as large (or come up with some clever trick to avoid the problem some other way)... > and that 255 repetition thing could have sent my program haywire, i > realized it afterwards. The most simple way to get around that is probably to stop counting when you have found 255 repetitions and simply write that out and continue, pretending that you found a "new" value after the 255 repetitions. Of course, the program that re- translates from the run-lenth encoded file back into a normal file must expect this behaviour. > Actually i by binary i thought it included all types of files, more > like a super-set.So i was aiming to read a pair of bytes("2X") from > the input file and store them in a array. What you actually seem to want to read is a single byte. When you write in your post e.g. > 46 6F 6F 6F 2B 2B 9C 81 81 81 81 84 84 84 7A 7A 7A then the "6F" is a human readable representation of a single byte with the bit pattern '01101111' (the first four bits can be seen as a 6 and the second set of four bits as 15 or hexa- decimal 'F'). But a file doesn't contain human readable repre- sentations but real "raw" bytes. And when you do run-length encoding you count how many bytes with the same value are in the file and replace that with a count and the bytes value. So you are supposed to read single bytes and count them. And if you read "raw" bytes it's nearly always more appropriate to use functions like fread(). A function like fscanf() when used with "%2X" expects to find a hexadecimal ASCII representation (some- thing literally like the two characters '6' and 'F') in the file and converts that to a "raw" byte for use with the program. But the file already contains "raw" bytes you want to read, so unsigned char c; fread( &c, 1, 1, fp ); is the way to get that into 'c' (an unsigned char is a good type of variable to hold "raw" bytes) with a value that may have a human readable hexadecimal representation like "6F". And then you would have another unsigned char, let's say named 'count', for counting how many bytes of the same value you read (the problem with 255 stems from an unsigned char not being guaranteed to be able to hold a larger value). So you read single bytes until you arrive at one that's different from the ones before (or you reach the end of the file!) and then you write both the count and the value by e.g. fwrite( &count, 1, 1, gp ); fwrite( &c, 1, 1, gp ); That will write two "raw" bytes in the file, first the count and then the byte's value itself. I would recommend that you start this simple and, for the first version of the program, just read single bytes and deal with them. When that works (you should also write a program that reads in the encoded file and converts it back to the original one, so you can check if things work correctly) as the next step you can consider how to read in larger chunks of bytes in one go. This will make the program probably quite a bit faster, but it's also more complicated - at least you got a lot more chances to make mistakes;-) But before you start with that it's important that you get a firm grasp of how values are stored in a file and the difference between e.g. the ASCII representation of a value and what's really in the file. Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
Re: Getting a runtime error::"The instruction at 0x004010b4referenced memory at 0x00000000. The memory could not be read
On Dec 25, 2:56*pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> Maxx <grungeddd.m...@gmail.com> wrote: > > Yeah i was aware of the worst possible scenario. actually i found this > > program in that K. N. King c programming book, the best case and the > > worst case was pointed out by the author. > > Well, when you're programming you always have to cater for the > worst possible case, so if you know that the worst case is that > the output buffer could potentially be twice as large as the > input buffer then you need to make it twice as large (or come > up with some clever trick to avoid the problem some other way)... > > > and that 255 repetition thing could have sent my program haywire, i > > realized it afterwards. > > The most simple way to get around that is probably to stop > counting when you have found 255 repetitions and simply write > that out and continue, pretending that you found a "new" value > after the 255 repetitions. Of course, the program that re- > translates from the run-lenth encoded file back into a normal > file must expect this behaviour. > > > Actually i by binary i thought it included all types of files, more > > like a super-set.So i was aiming to read a pair of bytes("2X") from > > the input file and store them in a array. > > What you actually seem to want to read is a single byte. When > you write in your post e.g. > > > *46 6F 6F 6F 2B 2B 9C 81 81 81 81 84 84 84 7A 7A 7A > > then the "6F" is a human readable representation of a single > byte with the bit pattern '01101111' (the first four bits can > be seen as a 6 and the second set of four bits as 15 or hexa- > decimal 'F'). But a file doesn't contain human readable repre- > sentations but real "raw" bytes. And when you do run-length > encoding you count how many bytes with the same value are in > the file and replace that with a count and the bytes value. > So you are supposed to read single bytes and count them. And if > you read "raw" bytes it's nearly always more appropriate to use > functions like fread(). A function like fscanf() when used with > "%2X" expects to find a hexadecimal ASCII representation (some- > thing literally like the two characters '6' and 'F') in the file > and converts that to a "raw" byte for use with the program. But > the file already contains "raw" bytes you want to read, so > > * * * *unsigned char c; > * * * *fread( &c, 1, 1, fp ); > > is the way to get that into 'c' (an unsigned char is a good > type of variable to hold "raw" bytes) with a value that may > have a human readable hexadecimal representation like "6F". > > And then you would have another unsigned char, let's say named > 'count', for counting how many bytes of the same value you read > (the problem with 255 stems from an unsigned char not being > guaranteed to be able to hold a larger value). So you read > single bytes until you arrive at one that's different from > the ones before (or you reach the end of the file!) and then > you write both the count and the value by e.g. > > * * * *fwrite( &count, 1, 1, gp ); > * * * *fwrite( &c, 1, 1, gp ); > > That will write two "raw" bytes in the file, first the count > and then the byte's value itself. > > I would recommend that you start this simple and, for the first > version of the program, just read single bytes and deal with > them. When that works (you should also write a program that > reads in the encoded file and converts it back to the original > one, so you can check if things work correctly) as the next > step you can consider how to read in larger chunks of bytes in > one go. This will make the program probably quite a bit faster, > but it's also more complicated - at least you got a lot more > chances to make mistakes;-) But before you start with that it's > important that you get a firm grasp of how values are stored in > a file and the difference between e.g. the ASCII representation > of a value and what's really in the file. > > * * * * * * * * * * * * * * * Regards, Jens > -- > * \ * Jens Thoms Toerring *___ * * *j...@toerring.de > * *\__________________________ * * *http://toerring.de Ok |
Re: Getting a runtime error::"The instruction at 0x004010b4referenced memory at 0x00000000. The memory could not be read
On Dec 25, 2:56*pm, j...@toerring.de (Jens Thoms Toerring) wrote:
> Maxx <grungeddd.m...@gmail.com> wrote: > > Yeah i was aware of the worst possible scenario. actually i found this > > program in that K. N. King c programming book, the best case and the > > worst case was pointed out by the author. > > Well, when you're programming you always have to cater for the > worst possible case, so if you know that the worst case is that > the output buffer could potentially be twice as large as the > input buffer then you need to make it twice as large (or come > up with some clever trick to avoid the problem some other way)... > > > and that 255 repetition thing could have sent my program haywire, i > > realized it afterwards. > > The most simple way to get around that is probably to stop > counting when you have found 255 repetitions and simply write > that out and continue, pretending that you found a "new" value > after the 255 repetitions. Of course, the program that re- > translates from the run-lenth encoded file back into a normal > file must expect this behaviour. > > > Actually i by binary i thought it included all types of files, more > > like a super-set.So i was aiming to read a pair of bytes("2X") from > > the input file and store them in a array. > > What you actually seem to want to read is a single byte. When > you write in your post e.g. > > > *46 6F 6F 6F 2B 2B 9C 81 81 81 81 84 84 84 7A 7A 7A > > then the "6F" is a human readable representation of a single > byte with the bit pattern '01101111' (the first four bits can > be seen as a 6 and the second set of four bits as 15 or hexa- > decimal 'F'). But a file doesn't contain human readable repre- > sentations but real "raw" bytes. And when you do run-length > encoding you count how many bytes with the same value are in > the file and replace that with a count and the bytes value. > So you are supposed to read single bytes and count them. And if > you read "raw" bytes it's nearly always more appropriate to use > functions like fread(). A function like fscanf() when used with > "%2X" expects to find a hexadecimal ASCII representation (some- > thing literally like the two characters '6' and 'F') in the file > and converts that to a "raw" byte for use with the program. But > the file already contains "raw" bytes you want to read, so > > * * * *unsigned char c; > * * * *fread( &c, 1, 1, fp ); > > is the way to get that into 'c' (an unsigned char is a good > type of variable to hold "raw" bytes) with a value that may > have a human readable hexadecimal representation like "6F". > > And then you would have another unsigned char, let's say named > 'count', for counting how many bytes of the same value you read > (the problem with 255 stems from an unsigned char not being > guaranteed to be able to hold a larger value). So you read > single bytes until you arrive at one that's different from > the ones before (or you reach the end of the file!) and then > you write both the count and the value by e.g. > > * * * *fwrite( &count, 1, 1, gp ); > * * * *fwrite( &c, 1, 1, gp ); > > That will write two "raw" bytes in the file, first the count > and then the byte's value itself. > > I would recommend that you start this simple and, for the first > version of the program, just read single bytes and deal with > them. When that works (you should also write a program that > reads in the encoded file and converts it back to the original > one, so you can check if things work correctly) as the next > step you can consider how to read in larger chunks of bytes in > one go. This will make the program probably quite a bit faster, > but it's also more complicated - at least you got a lot more > chances to make mistakes;-) But before you start with that it's > important that you get a firm grasp of how values are stored in > a file and the difference between e.g. the ASCII representation > of a value and what's really in the file. > > * * * * * * * * * * * * * * * Regards, Jens > -- > * \ * Jens Thoms Toerring *___ * * *j...@toerring.de > * *\__________________________ * * *http://toerring.de Ok so i need to use fwrit() to write raw bytes, got it. Actually i thought fread()/fwrite() were used to read large blocks of file. Anyways thanks for your help. |
Re: Getting a runtime error::"The instruction at 0x004010b4 referenced memory at 0x00000000. The memory could not be read
Maxx <grungeddd.maxx@gmail.com> wrote:
> Ok so i need to use fwrit() to write raw bytes, got it. Actually i > thought fread()/fwrite() were used to read large blocks of file. You can use them to read/write as many bytes as you need. They work for single bytes as well as for gigabytes. Of course, each call of such a function takes a bit of time, so it may be more efficient to read in larger chunks and thus, in the long run, one probably might be looking for a way to reduce the number of calls - but only after the algorithm that's applied to the data has been tested and proven to be working correctly. Try to get it right first and only then attempt to optimize;-) Actually, if you write your program to have two func- tions, one for dealing with input and the other with output, like for example int get_a_char( unsigned char * c ); and void output_rle_data( unsigned char count, unsigned char value ); you can use them within your program to get new fresh bytes on which you apply your encoding algorithm and then to send out a new set of a count and a value, regardless of how exactly this is done. In a first version you might read just single bytes from a file at a time with get_a_char() and directly output encoded data to another file with output_rle_data(). I.e. get_a_char() at first could be as simple as int get_a_char( unsigned char *c ) { return fread( c, 1, 1, fp ); } In the caller (i.e. the part that does the run-length encoding) you check if the return value is 1 and then you know you got a new byte to deal with, otherwise you have reached the end of the file (or a read error occured). If you later want to get more fancy you can change just this function so that it reads in data in larger chunks. You could e.g make that function store them in a local buffer and return single bytes from that buffer to the caller, reading more from the file only when the buffer becomes empty. But the "interface" for the caller stays exactly the same as before, i.e. the caller continues to receive a new byte via the pointer argument as long as the return value isn't 0. The advantage is that you then don't have to change anything about your "core algorithm" that deals with the run-length encoding and which you know works cor- rectly. So any new bugs must be in the input function which makes it lot easier to debug the program. As an additional benefit it also will be easier for others to understand the program (and also for yourself when you read it again in half a years time). The same, of course, holds for the output function. Regards, Jens -- \ Jens Thoms Toerring ___ jt@toerring.de \__________________________ http://toerring.de |
| All times are GMT. The time now is 04:58 AM. |
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.