| | |
corruption of the heap
![]() |
•
•
Join Date: Jul 2008
Posts: 36
Reputation:
Solved Threads: 0
Hi,
I got this message "Windows has triggered a breakpoint in inout.exe. This may be due to a corruption of the heap, and indicates a bug in inout.exe or any of the DLLs it has loaded. The output window may have more diagnostic information" while debugging the following program in VC 2005 Express:
What's the problem with my code? Thanks in advance!
I got this message "Windows has triggered a breakpoint in inout.exe. This may be due to a corruption of the heap, and indicates a bug in inout.exe or any of the DLLs it has loaded. The output window may have more diagnostic information" while debugging the following program in VC 2005 Express:
C Syntax (Toggle Plain Text)
#include <stdio.h> #include <stdlib.h> int main(void) { char file[]="test.txt"; FILE*fp=fopen(file,"w"); for (int i=0;i<200;i++) fprintf(fp,"%d ",255); fclose(fp); fp=fopen(file,"r"); unsigned char*ptr; ptr=(unsigned char*)malloc(5*sizeof(unsigned char)); for (int i=0;i<5;i++)fscanf(fp,"%d",ptr+i); fclose(fp); free(ptr); return 0; }
Last edited by Ancient Dragon; Nov 19th, 2008 at 11:40 pm. Reason: add code tags
>>ptr=(unsigned char*)malloc(5*sizeof(unsigned char));
you are only allocating 5 bytes to hold 5 integers! and ptr needs to be an int pointer, not a char pointer. Change that line to
you are only allocating 5 bytes to hold 5 integers! and ptr needs to be an int pointer, not a char pointer. Change that line to
int* ptr= malloc(5*sizeof(unsigned int)); Last edited by Ancient Dragon; Nov 19th, 2008 at 11:44 pm.
Don't PM me with questions -- you might get a nasty PM in response. If you have a question then post it in one of the forums.
•
•
Join Date: Jul 2008
Posts: 36
Reputation:
Solved Threads: 0
Thanks.
In fact I just made up the "test.txt" file. In my real case, I have to read in data ( each is an integer and ranges from 0 to 255) from a file into an unsigned char array that are dynamically allocated.
Since an unsigned char can hold a value as large as 255, is there something else wrong? Is it correct to use the conversion specifier "d" with unsigned char in "fscanf"?
In fact I just made up the "test.txt" file. In my real case, I have to read in data ( each is an integer and ranges from 0 to 255) from a file into an unsigned char array that are dynamically allocated.
Since an unsigned char can hold a value as large as 255, is there something else wrong? Is it correct to use the conversion specifier "d" with unsigned char in "fscanf"?
Read it in an integer and then place it in your unsigned char array.
•
•
Join Date: Jul 2008
Posts: 36
Reputation:
Solved Threads: 0
Hi,Thanks!
I still have the same questions:
Since an unsigned char can hold a value as large as 255, why bother to use integer as intermediate?
Is there something else wrong? Is it correct to use the conversion specifier "d" with unsigned char in "fscanf"? If it is not, which conversion spcifier is proper for unsigned char?
I still have the same questions:
Since an unsigned char can hold a value as large as 255, why bother to use integer as intermediate?
Is there something else wrong? Is it correct to use the conversion specifier "d" with unsigned char in "fscanf"? If it is not, which conversion spcifier is proper for unsigned char?
>Is it correct to use the conversion specifier "d" with unsigned char in "fscanf"?
Nope. You have no idea how your implementation of fscanf will work. It's especially dangerous to say you'll pass a pointer to a type of one size and actually pass a pointer to a type of a smaller size. By using an intermediate int variable for the input, you at least have more control over when and how the assignments are performed:
>If it is not, which conversion spcifier is proper for unsigned char?
In C99, you can say %hhd to read an unsigned char as an integral value rather than a character. In C89 and C++, you're SOL and have to use the intermediate if you want to be safe.
[1] It's not always safe because *scanf doesn't check for arithmetic overflow. For example, if the file contains 999999999999999999999 somewhere, you're borked.
Nope. You have no idea how your implementation of fscanf will work. It's especially dangerous to say you'll pass a pointer to a type of one size and actually pass a pointer to a type of a smaller size. By using an intermediate int variable for the input, you at least have more control over when and how the assignments are performed:
c Syntax (Toggle Plain Text)
for ( int i = 0; i < 5; i++ ) { int temp; fscanf ( fp, "%d", &temp ); /* Always safe[1] */ /* Now you can verify the value before converting! */ if ( 0 <= temp && temp <= 255 ) ptr[i] = temp; else { /* Handle the error */ } }
In C99, you can say %hhd to read an unsigned char as an integral value rather than a character. In C89 and C++, you're SOL and have to use the intermediate if you want to be safe.
[1] It's not always safe because *scanf doesn't check for arithmetic overflow. For example, if the file contains 999999999999999999999 somewhere, you're borked.
I'm here to prove you wrong.
![]() |
Similar Threads
- HEAP Corruption Error (C++)
- Strings this time (C++)
- Call Stack (C++)
- realloc malloc and Heap problem. (C++)
- Merge Sort on a Array-Based List (C++)
- Problem with socket (C++)
Other Threads in the C Forum
- Previous Thread: mixed up
- Next Thread: Dynamically allocating 2d arrays
| Thread Tools | Search this Thread |
#include * adobe ansi api array asterisks binarysearch centimeter changingto char character cm copyimagefile cprogramme creafecopyofanytypeoffileinc createcopyoffile csyntax database directory dynamic feet fgets file fork frequency function getlasterror getlogicaldrivestrin givemetehcodez global grade graphics gtkgcurlcompiling gtkwinlinux hacking highest histogram include incrementoperators infiniteloop input interest kernel keyboard kilometer linked linkedlist linux linuxsegmentationfault list locate logical_drives looping loopinsideloop. lowest match matrix meter microsoft mqqueue mysql number odf opendocumentformat owf pattern pdf performance pointer posix probleminc process program programming radix recursion recv repetition research reversing scanf segmentationfault sequential shape single socket socketprograming standard string systemcall threads turboc unix user voidmain() wab whythiscodecausesegmentationfault windows.h windowsapi






