Thread Subject:

fread bug? Skipping randomly

I'm trying to debug a data import script that has stopped working properly. What I've gotten down to is a situation like this:

>> ftell(fid)
ans = 100

>> D=fread(fid,96,'char');
>> ftell(fid)
ans = 198

The file pointer is too far along relative to how much stuff I have read. The vector D is the right length.

If I make a for loop like this:

for x=1:96
  D(x) = fread(fid,1,'char');
  ftell(fid)
end

I can clearly see a jump in the ftell outputs. It increments by one all except twice when it skips by two. Strangely, in my specific case, the values that end up in D are not the same in the last read.

How can this not be a bug? This is a script that used to work. Not sure when I ran it last, but I'm at 2010b now.

On 5/6/2011 3:07 PM, Chuck37 wrote:
...

> How can this not be a bug? This is a script that used to work. Not sure
> when I ran it last, but I'm at 2010b now.

Look at the data file at the offending location w/ a hex editor and
report...

--

"Chuck37" wrote in message <iq1kd8$sb8$1@newscl01ah.mathworks.com>...
> I'm trying to debug a data import script that has stopped working properly. What I've gotten down to is a situation like this:
>
> >> ftell(fid)
> ans = 100
>
> >> D=fread(fid,96,'char');
> >> ftell(fid)
> ans = 198
>
> The file pointer is too far along relative to how much stuff I have read. The vector D is the right length.
>
> If I make a for loop like this:
>
> for x=1:96
> D(x) = fread(fid,1,'char');
> ftell(fid)
> end
>
> I can clearly see a jump in the ftell outputs. It increments by one all except twice when it skips by two. Strangely, in my specific case, the values that end up in D are not the same in the last read.
>
> How can this not be a bug? This is a script that used to work. Not sure when I ran it last, but I'm at 2010b now.
- - - - - - - - -
  I am far from being knowledgeable about 'fread' matters but as I recall when you set the precision argument to 'char' it is possible to read in some characters as two byte quantities. The documentation says: "Depends on the encoding scheme associated with the file. Set encoding with fopen."

Roger Stafford

Yes, it looks like "char" can cause trouble and read more than a byte. I don't really understand it. It has worked before and actually works on another machine I have that is running 2011a. Anyway, the trick that makes it work is to change "char" to "uint8=>char". This seems to force it.

On 5/6/2011 5:00 PM, Chuck37 wrote:
> Yes, it looks like "char" can cause trouble and read more than a byte. I
> don't really understand it. It has worked before and actually works on
> another machine I have that is running 2011a. Anyway, the trick that
> makes it work is to change "char" to "uint8=>char". This seems to force it.

Double-byte character sets can (and do) that...that's why was asking
what the character at the offending place was/is...

--

On 5/6/2011 5:00 PM, Chuck37 wrote:
> Yes, it looks like "char" can cause trouble and read more than a byte. I
> don't really understand it. It has worked before and actually works on
> another machine I have that is running 2011a. Anyway, the trick that
> makes it work is to change "char" to "uint8=>char". This seems to force it.

See other note--does 2011a act differently on the _same_ file? I
suppose TMW could have changed how they handle character sets; I haven't
tried on this really old system to see what happens...

--

dpb <none@non.net> wrote in message <iq20re$5et$1@speranza.aioe.org>...
> On 5/6/2011 5:00 PM, Chuck37 wrote:
> > Yes, it looks like "char" can cause trouble and read more than a byte. I
> > don't really understand it. It has worked before and actually works on
> > another machine I have that is running 2011a. Anyway, the trick that
> > makes it work is to change "char" to "uint8=>char". This seems to force it.
>
> See other note--does 2011a act differently on the _same_ file? I
> suppose TMW could have changed how they handle character sets; I haven't
> tried on this really old system to see what happens...
>
> --

Yeah, it's different on the exact same file, but they are also different physical machines so that could be part of the issue.