shell edit() trips on Windows newline kink

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

shell edit() trips on Windows newline kink

Larry Brasfield
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
  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);
     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",
     goto edit_func_end;
(I omit line number marking because my unrelated changes make them
inapplicable to source in the SQLite sources.)


Larry Brasfield
sqlite-users mailing list
[hidden email]