I was experimenting today with a v3.25.0 variant and encountered this bug,
on my Windows 10 system, when I used the SQLite CLI shell's edit()
function. Because I had put a newline in the text with the invoked editor,
and it was written and read back as a text file, the following code got
unhappy:
fseek(f, 0, SEEK_END);
sz = ftell(f);
...
x = fread(p, 1, sz, f);
...
if( x!=sz ){
sqlite3_result_error(context, "could not read back the whole file", -1);
goto edit_func_end;
}
The problem is that, on the Windows platform, newlines are stored on disk
as CR LF character pairs but, for text mode file I/O, are translated to a
single LF character in the C buffered file I/O library. In the above
check, this causes x to be less than sz by the number of newlines so
translated. There is an additional related problem whereby the 0
terminator on the read-in string (in text mode) is put in the wrong place.
Here is fossil diff output showing (what I believe to be) an effective fix,
which I have tested:
===========
if( bBin ){
x = fread(p, 1, sz, f);
}else{
x = fread(p, 1, sz, f);
- p[sz] = 0;
+ p[x] = 0;
}
- fclose(f);
- f = 0;
- if( x!=sz ){
+ if( ftell(f)!=sz ){
sqlite3_result_error(context, "could not read back the whole file",
-1);
goto edit_func_end;
}
===========
(I omit line number marking because my unrelated changes make them
inapplicable to source in the SQLite sources.)
Cheers,
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
