• Locked Locked
  • Replies 1 reply
  • Subscribers 52 subscribers
  • Views 821 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Unexpected fread() behavior

CalvinC
Intellectual 990 points

I'm using fopen(, "rb") and fread() as part of a test bench (simulator) for a small block a code. Because I am single stepping through the code and usually aborting execution to reload a code change, the fclose() never gets called. Can repeated calls to fopen() with the same file name cause a problem (using up all the file handles, or not resetting file pointers)?

What I'm observing is that every 10-12 calls to fread(), a block of data gets skipped as if the previous fread() extracted twice the data requested. However, size= fread() so does not flag a discrepancy with the requested number of elements. Since I'm trying to read in MPEG-2 TS packets, I'm observing that the continuity count skips while scrutiny of the source file shows all the data is in fact present.

Another thought, even though this is a simulator (not emulator) do you need to call  cache_inv() to sync up the data just read?

-Calvin

CCS 5.5.0.00077

CGT 6.1.20

Target: C6472 (Simulator)

  • Intellectual 990 points

    False alarm -- found my issue.

    fread() is just fine, but I had a () in the wrong location when masking off some bits. The problem only showed up when certain bits were set in the data which I then attributed to fread().

    Still curious about any side effects with not calling fclose() each run. In this case I'm not writing data so not concerned about flushing data to the file. However, does fopen() recognize that the file is already opened and does not consume another handle?

    Calvin