Hot answers tagged

18

When you open a file a cursor is set somewhere in it (look at man fopen for more about that) and you can change this cursor position using fseek. When you read a "block" (in your case you read sizeof(RGBTRIPLE) bytes) from your file using fread the cursor will be move forward automatically by sizeof(RGBTRIPLE) bytes since your cursor needs to be on each ...


10

You have mixed them a little in your head but we are here. :) Firstly, the line RGBTRIPLE triple; doesn't get a pixel, it just declares a variable, of type RGBTRIPLE with the name triple. It would be the same as int count; nothing less, nothing more. All the information, is passed to triple, through fread(). fread() takes 4 arguments: buffer - ...


9

//repead until end of card while (fread(&buffer, MBLOCK, 1, sdCardFile) == 1) { //read 512 bytes into a buffer fread(&buffer, MBLOCK, 1, sdCardFile); So, why do you feel that it is necessary to read a second block before processing the first one? This has the effect of throwing away every other block from the input file. The first read in ...


6

What is wrong with feof? per feof's man page, it returns non-zero if the EOF was already reached not whether the next thing to reach as you read is the EOF. this means that it returns non-zero even if there is no further data to read (in which case, if you read, you will reach the EOF). as feof returns non-zero, the loop executes one more time and ...


5

Abstract: Disk I/O is complex, fread() provides a simpler interface to that complexity. This answer will take a look at what fread() does, and a further look at the things going on even deeper. fread(): Declaration: size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream); Description: The function fread() reads nmemb elements of data, each ...


5

how does freed know to read one byte after another? It's essentially the definition of fread(): size_t fread ( void * ptr, size_t size, size_t count, FILE * stream ); Reads an array of count elements, each one with a size of size bytes, from the stream and stores them in the block of memory specified by ptr. In your example fread(&triple, sizeof(...


2

The problem is that you are not printing using the same format in gdb and with the xxd command. xxd outputs hexadecimal and gdb outputs in decimal. To print in the same format with both programs a solution can be this. In the command line type: xxd -g 1 -l 4 card.raw Notice that -g 1 separetes the output of xxd in hexadecimals of one byte width, and the ...


2

I (think) nmemb stands for: "number of members". Quite arguably, though ;) The point is you're reading data from stream and writing it into ptr (EDIT: actually you don't write data into ptr; you write it into the location in memory that is pointed to by ptr) (a so called "buffer"). But you'll probably get in trouble if the structure that ptr points to is ...


2

This is what man page says The function fread() reads nmemb elements of data, each size bytes long, from the stream pointed to by stream, storing them at the loca‐ tion given by ptr. The function fwrite() writes nmemb elements of data, each size bytes long, to the stream pointed to by stream, obtaining them from ...


2

I ran your program with a couple of debug lines added and it actually worked fine, reading in all the bytes of card.raw. Here's my version: int main(int argc, char* argv[]) { // Array to hold a 512 byte chunk of data. char chunk[512] = {0}; // FILE* dst = NULL; //commented out as it's not used // open input file FILE* src = fopen("...


2

Are you sure that you haven't switched the working version for the non-working one? fread() requires 4 parameters. Because of your placement of parentheses, the second one only has one parameter, fread(buffer) However, let's assume that this is merely a copying error and move on. You said that the first one failed, but you don't describe the nature of the ...


2

per fread's man page: size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream); The function fread() reads nmemb elements of data, each size bytes long, from the stream pointed to by stream, storing them at the location given by ptr. per realloc's man page: The realloc() function returns a pointer to the newly allocated memory, ...


2

FILE* img = fopen(title, "w"); // SEGMENTATION FAULT OCCURRING REALLY HERE This is because char title [3] does not have enough space to store the title, change it to char title [8] for example


2

We already know that buffer is an array of ints, but underneath the hood, buffer is actually a pointer to the block of memory where these ints are stored. For example, if the allocated block of memory for the 512 unsigned ints starts from 0x123, buffer will be equal to 0x123. The pointer to a block of memory that's meant to store an array of values is ...


2

You just opened your file for writing (and reading). This erased your card.raw's content. The 0 you find in block[0] is the initial value of your allocated memory, which by coincidence is 0. The 255 you find in c is actually a -1 returned by fgetc (and means EOF - End Of File). When converting the int-type -1 to an unsigned char, only the least significant ...


1

"Everyone's looking for a zebra. I see the injured horse." All of the file reads and writes are using the outptr output file pointer. The only reference to the input file pointer inptr is the fclose statement at the end. Wouldn't it work better if the code read data from the input file instead of the output file? If this answers your question, please click ...


1

Don't use int buf[128]; but uint8_t buf[512];, or BYTE buf[512];, or unsigned char buf[512];. With int, the first four bytes would be stored together in buf[0], and your test would have to be different. Oh, and remove the counting loop. You know you're at the end of the file if fread no longer returns 1. The counting loop makes things worse: You consume ...


1

I tested with your code and it's definitely correct, as @cliff has said in the commment. Do make sure the file you are opening actually has more than 512 bytes. Perhaps your rawfile has been corrupted?


1

There is "\n" (new line) char in the end of the first raw. So there are 33 chars, while you read-write only 32.


1

Remove the for loop with the extra freads. You do that in the condition already, so you'd read two blocks, discarding the first. &buffer[0] is actually same as buffer.


1

When the program has opened the card.raw file and is reading into the buffer, once the program has completed one loop iteration, how does it know to read the next block of bytes and not just the same ones again? R.: fread() will ALWAYS read the next block. It'll only read the same block again if you force the file position indicator back with fseek(...


1

The code does two fread() calls at the top of the while loop. The data from the first fread isn't being processed, it's just being overwritten when the loop comes back around. This means that half the data is being discarded, including, conicidentally, half of the signature blocks. The inptr file pointer doesn't reset because you're using a different buffer,...


1

You're on the right track. You don't need to malloc()... it can be done with an array just like you declared... now you fread() 512 bytes into that array and check the first four bytes with temp[0], temp[1], temp[2] etc and compare those against what should be a JPG signature. And so on. And if you haven't already, watch Zamyla's walkthrough and it will ...


1

Simply put, the pointer will automatically be moved to point at the first unread byte past whatever was read in that particular statement, whether it was 1 byte or 512 bytes, or anything else. If you had two freads that each read 10 bytes, then the pointer moves 20 bytes and will point at the first byte following the 20 that were read. If this answers your ...


1

The problem was fileName array, it needs to be 8, not 7. sprintf was overwriting important memory because of that.


1

From man fread (emphasis added): On success, fread() and fwrite() return the number of items read or written. This number equals the number of bytes transferred only when size is 1. If an error occurs, or the end of the file is reached, the return value is a short item count (or zero). fread signature is size_t ...


1

The most obvious difference is the return value: fread returns the number of elements read (in this case, the number of sizeof(int)'s). If all goes well, the first formulation will return 10, while the sum of the individual fread return values (each having a return value of 1) in the second formulation should likewise equal 10. Also, if the stream (infile) ...


1

Your triple didn't change, it moved. You have two significant problems. Your headers are wrong and your padding is wrong. You need to get the headers right before moving on to the images. I recommend that you get everything working for n=1 before moving on to n=2. When n=1, the input and output files should be identical. xxd and peek will be your best ...


1

Figured it out. I was continuing to write even though the file ended. I deleted one of my fwrite statements and the problem was fixed!


1

You're comparing apples to oranges. The problem is this: int tmp; int is a 4 byte variable (it could be 2 in certain architectures, but that's rare today.) You're comparing a single byte to 4 bytes. In short, your compares are failing because of this. In this case, you need to use a single byte unsigned data type, like unsigned char, there are others. Making ...


Only top voted, non community-wiki answers of a minimum length are eligible