Member Avatar for red_evolve

Hi. Can anyone help me to distinguish the reason behind this case? Thanks a lot.
I initialized the following variable: unsigned char temp=0;
In the following statement block, I managed to get the results that I wanted to be displayed on the first go (traversing the while loop on the first run).
However, on the 2nd run, the temp being printed equals to the last temp printed in the first run.

while
{
     // other print statements
     // statement to get rlen
     for(i=0; i<rlen; i++)
     {
          fread( (char*) &temp, sizeof(temp), 1 ,input);
          printf("%x ", temp);  
     }
}

I've thought of it might be because of pointer problems? I am not sure. I am not any good at this, just a beginner. Please help. Thanks.

Edited by Dani because: Formatting fixed
  • 3 Contributors
  • 5 Replies
  • 260 Views
  • 4 Weeks Discussion Span
  • Latest Post Latest Post by infamous

Dani AI

Generated

A concise diagnosis and concrete fixes.

The pattern described by — "first pass OK, later bytes repeat the last value" — strongly suggests the read call is returning short/EOF and the code never checks that return. fread leaves the destination unchanged on a short read, and fgetc returns EOF (the integer -1) which, when printed as hex without checking, looks like a big unsigned value. was right to suggest per-byte reads; was right to insist on checking for EOF/error. Below are safe, minimal patterns and debugging checks.

Read-one-byte with fread and check the return:

unsigned char b = 0;
size_t got;
for (size_t i = 0; i < rlen; ++i) {
    got = fread(&b, 1, 1, input);
    if (got != 1) {
        if (feof(input)) break;        /* normal EOF */
        perror("fread");               /* real error */
        break;
    }
    printf("%02x ", (unsigned)b);
}

Use fgetc correctly (note the int return and EOF test):

int c;
for (size_t i = 0; i < rlen; ++i) {
    c = fgetc(input);
    if (c == EOF) {
        if (feof(input)) break;
        perror("fgetc");
        break;
    }
    printf("%02x ", c & 0xFF);
}

Practical extra checks and tips (common gaps seen in packet parsers):

  • Open capture files in binary mode (fopen(..., "rb")) to avoid CR/LF translation on Windows.
  • Print and verify rlen and the file position (ftell) before reading a packet — an incorrect length causes short reads.
  • When parsing pcap/windump output, prefer libpcap APIs (pcap_open_offline / pcap_next_ex) or verify raw bytes with a hex tool (hexdump/xxd or tcpdump -xx) rather than hand-parsing the file header.
  • Always cast small integer types when printing with %x (use (unsigned)byte) to avoid sign-extension surprises.

Applying these checks removes stale-byte artifacts and prevents EOF/error values from being misinterpreted as valid data.

Recommended Answers

All 5 Replies

Member Avatar for r0ckbaer 
for (int i = 0; i < rlen; i++)
{
   printf("%x\n", fgetc(input));
}

do it that way

Member Avatar for red_evolve

Thanks a lot for your reply.
I've tried and hey, the output differs, however it's still not what I expected it to be.

The first loop:

a1 b3 8 9a      // which is correct

The second loop:

9a 9a 9a 9a        // before r0ckbaer's advice
ffffff       // after applying to r0ckbaer's advice
ffffff
ffffff
ffffff
Member Avatar for r0ckbaer

Well, normally fgetc gets one char per loop (in the above example) and increments the file pointer with 1, so:
a1 b3 8 9a
would be a result after 4 loops.
Be more specific on how you want the output to look like and if possible paste a snapshot of the hexdump of lets say the first 50 bytes of the file u want to analyze.

Member Avatar for red_evolve

Well, it's a project for computer networks actually.
I am to capture packets using a program called windump, and then decode each field of information in their respective ethernet frame, ip frame, tcp/udp frame.
It seems that the results is not stable, in some packets, I could get the correct output, while not in some other packets.
Is it always like that? (Now, it seems like it has to be in the 'networking' topic & not c already!)
This is because, I strongly feel that there is no problem with the codes. I've got a comment from a coursemate that output will be more accurate using bigger packet files. :!: Please advise. Thanks.

Member Avatar for infamous 
for (int i = 0; i < rlen; i++)
 {
    printf("%x\n", fgetc(input));
 }

do it that way

this is wrong. you cannot just call functions without checking the error return of them. fgetc() can fail, and must be checked. and from the ff output u can tell that it is trying to tell u something!! that is EOF or error being returned! lets see the rest of the code.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.