fseek not seeking

[John Z]

All please check on your machines to confirm the behavior.
 

Well  - confirmed on my i7.

However I also did some additional testing - all results attached.

In summary changing _ftell64 to ftell and the problem goes away.
"_ftell64 function [not standard C] [8.00]"

Easy to confirm with frankie's demo program.

Also points to why in my program using so many f.... functions yet I never experienced the issue,
well that plus I could not use fgets anyway 

John Z

[frankie]

Kevin I made a fast compare on code disassembly, and I found no differences between the two. So the issue isn't in the code generation (attache the 2 disassembly).
Then I changed the fopen to binary mode, and it seems to work well:

Code: [Select]

FILE *fp = fopen("test.txt", "rb");
Could you try to change the function Final_Transforms () as follow:

Code: [Select]

void Final_Transforms (void)
{
  char    Source[BCXSTRSIZE];
  char    Dll_Orig[BCXSTRSIZE];
  strcpy(Dll_Orig,vchr(30,67,95,69,88,80,79,82,84,32,105,110,116,32,95,95,115,116,100,99,97,108,108,32,68,108,108,77,97,105,110));
  char    Dll_Repl[BCXSTRSIZE];
  ....
// If compiling for PellesC open file in binary mode.
#ifdef __POCC__
  if((FP1=fopen(FileOut, "rb"))==0)
#else
  if((FP1=fopen(FileOut, "r"))==0)
#endif
   {
  fprintf(stderr, "Error: Cannot Access File or File Not Found. %s\n", FileOut); exit(1);
   }
  if((FP2=fopen("$Bcx$Temp$File$", "w"))==0)
   {
  fprintf(stderr, "Error: Cannot Access File or File Not Found. %s\n", "$Bcx$Temp$File$"); exit(1);
   }
  while(!EoF(FP1)){
      Source[0]=0;
      fgets(Source,  2048, FP1);
        if(feof(FP1) || (Source[strlen(Source)-1]==10))
          {
           Source[strcspn(Source,"\r\n")] = 0;
          }
         else
          {
            printf("%s%d while reading file: %s\n","Error! - LINE INPUT truncation detected at PROGRAM line: ",__LINE__-7, NamePathFromFP(FP1));
            printf("%s\n","The actual truncated line of text:");
            printf("%s",Source);
            exit(1);
          }
      if(strcmp(ltrim(Source),"")==0  && strcmp(ltrim(LookAhead(FP1)),"")==0){
          continue;
        }
      if(strcmp(ltrim(Source),"")==0  && strcmp(ltrim(LookAhead(FP1)),"#endif")==0){
          continue;
        }
      strcpy(Source,replace(Source,chr(15),":"));
      strcpy(Source,replace(Source,QQF,QQR));
      strcpy(Source,replace(Source,Dll_Orig,Dll_Repl));
  ...
}

You can also try changing _ftell64() to ftell() as suggested by John (you already use ftell() when compiling for LCC-Win32).

You can check on the sample I posted before, you can change the file opening to binary and check results.

At this point the issue is in the PellesC I/O library. Probably the cr/lf translation sometime fails, maybe when the cr and the lf are on a sector boundary (adding something in the file shift them and remove the problem).

[frankie]

All please check on your machines to confirm the behavior.
 

Well  - confirmed on my i7.

However I also did some additional testing - all results attached.

In summary changing _ftell64 to ftell and the problem goes away.
"_ftell64 function [not standard C] [8.00]"

Easy to confirm with frankie's demo program.

Also points to why in my program using so many f.... functions yet I never experienced the issue,
well that plus I could not use fgets anyway 

John Z

Thanks John.
This confirms the I/O system failure.

[John Z]

Then I changed the fopen to binary mode, and it seems to work well:

Confirmed working on my system.

Also BTW in my program I always opened in binary except when checking access.  So another reason why I would not experience the issue had I even used _ftell64.

John Z

[MrBcx]

Kevin I made a fast compare on code disassembly, and I found no differences between the two. So the issue isn't in the code generation (attache the 2 disassembly).
Then I changed the fopen to binary mode, and it seems to work well:

Code: [Select]

FILE *fp = fopen("test.txt", "rb");
Could you try to change the function Final_Transforms () as follow:

Code: [Select]

void Final_Transforms (void)
{
  char    Source[BCXSTRSIZE];
  char    Dll_Orig[BCXSTRSIZE];
  strcpy(Dll_Orig,vchr(30,67,95,69,88,80,79,82,84,32,105,110,116,32,95,95,115,116,100,99,97,108,108,32,68,108,108,77,97,105,110));
  char    Dll_Repl[BCXSTRSIZE];
  ....
// If compiling for PellesC open file in binary mode.
#ifdef __POCC__
  if((FP1=fopen(FileOut, "rb"))==0)
#else
  if((FP1=fopen(FileOut, "r"))==0)
#endif
   {
  fprintf(stderr, "Error: Cannot Access File or File Not Found. %s\n", FileOut); exit(1);
   }
  if((FP2=fopen("$Bcx$Temp$File$", "w"))==0)
   {
  fprintf(stderr, "Error: Cannot Access File or File Not Found. %s\n", "$Bcx$Temp$File$"); exit(1);
   }
  while(!EoF(FP1)){
      Source[0]=0;
      fgets(Source,  2048, FP1);
        if(feof(FP1) || (Source[strlen(Source)-1]==10))
          {
           Source[strcspn(Source,"\r\n")] = 0;
          }
         else
          {
            printf("%s%d while reading file: %s\n","Error! - LINE INPUT truncation detected at PROGRAM line: ",__LINE__-7, NamePathFromFP(FP1));
            printf("%s\n","The actual truncated line of text:");
            printf("%s",Source);
            exit(1);
          }
      if(strcmp(ltrim(Source),"")==0  && strcmp(ltrim(LookAhead(FP1)),"")==0){
          continue;
        }
      if(strcmp(ltrim(Source),"")==0  && strcmp(ltrim(LookAhead(FP1)),"#endif")==0){
          continue;
        }
      strcpy(Source,replace(Source,chr(15),":"));
      strcpy(Source,replace(Source,QQF,QQR));
      strcpy(Source,replace(Source,Dll_Orig,Dll_Repl));
  ...
}

You can also try changing _ftell64() to ftell() as suggested by John (you already use ftell() when compiling for LCC-Win32).

You can check on the sample I posted before, you can change the file opening to binary and check results.

At this point the issue is in the PellesC I/O library. Probably the cr/lf translation sometime fails, maybe when the cr and the lf are on a sector boundary (adding something in the file shift them and remove the problem).

Frankie -- I tried the various forms of ftell and fseek days ago with no success.  However,  taking your
suggestion about conditionally using binary read mode when compiling with Pelles did the trick!

I removed the earlier "fixups", added the compiler conditional, and rebuilt using Pelles successfully.  Not only did it
compile without warnings/errors but LookAhead() functioned as it should.  I can live with this workaround in BCX,
although it would be great if the root cause can still be found and fixed by Mr. Wizard himself  :-)

Thank you very much for taking an interest in this - I very much appreciate your expertise.


    ! #ifndef __POCC__
         OPEN FileOut$ FOR INPUT AS FP1
    ! #else
         OPEN FileOut$ FOR BINARY READ AS FP1
    ! #endif

    OPEN "$Bcx$Temp$File$" FOR OUTPUT AS FP2
    '**********************************************************************************
    DO WHILE NOT EOF(FP1)
        LINE INPUT FP1, Source$
        '******************************************************************************
        '               Do Some quick beautification of the output
        '******************************************************************************
        IF LTRIM$(Source$) = "" AND LTRIM$(LOOKAHEAD$(FP1)) = "" THEN ITERATE
        IF LTRIM$(Source$) = "" AND LTRIM$(LOOKAHEAD$(FP1)) = "#endif" THEN ITERATE
        '******************************************************************************

[frankie]

Frankie -- I tried the various forms of ftell and fseek days ago with no success.  However,  taking your
suggestion about conditionally using binary read mode when compiling with Pelles did the trick!

I removed the earlier "fixups", added the compiler conditional, and rebuilt using Pelles successfully.  Not only did it
compile without warnings/errors but LookAhead() functioned as it should.  I can live with this workaround in BCX,
although it would be great if the root cause can still be found and fixed by Mr. Wizard himself  :-)

Thank you very much for taking an interest in this - I very much appreciate your expertise.


    ! #ifndef __POCC__
         OPEN FileOut$ FOR INPUT AS FP1
    ! #else
         OPEN FileOut$ FOR BINARY READ AS FP1
    ! #endif

    OPEN "$Bcx$Temp$File$" FOR OUTPUT AS FP2
    '**********************************************************************************
    DO WHILE NOT EOF(FP1)
        LINE INPUT FP1, Source$
        '******************************************************************************
        '               Do Some quick beautification of the output
        '******************************************************************************
        IF LTRIM$(Source$) = "" AND LTRIM$(LOOKAHEAD$(FP1)) = "" THEN ITERATE
        IF LTRIM$(Source$) = "" AND LTRIM$(LOOKAHEAD$(FP1)) = "#endif" THEN ITERATE
        '******************************************************************************

░░░░░░░░░░░░░░░░░░░░░░█████████
░░███████░░░░░░░░░░███▒▒▒▒▒▒▒▒███
░░█▒▒▒▒▒▒█░░░░░░░███▒▒▒▒▒▒▒▒▒▒▒▒▒███
░░░█▒▒▒▒▒▒█░░░░██▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒██
░░░░█▒▒▒▒▒█░░░██▒▒▒▒▒██▒▒▒▒▒▒██▒▒▒▒▒███
░░░░░█▒▒▒█░░░█▒▒▒▒▒▒████▒▒▒▒████▒▒▒▒▒▒██
░░░█████████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒██
░░░█▒▒▒▒▒▒▒▒▒▒▒▒█▒▒▒▒▒▒▒▒▒█▒▒▒▒▒▒▒▒▒▒▒██
░██▒▒▒▒▒▒▒▒▒▒▒▒▒█▒▒▒██▒▒▒▒▒▒▒▒▒▒██▒▒▒▒██
██▒▒▒███████████▒▒▒▒▒██▒▒▒▒▒▒▒▒██▒▒▒▒▒██
█▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒█▒▒▒▒▒▒████████▒▒▒▒▒▒▒██
██▒▒▒▒▒▒▒▒▒▒▒▒▒▒█▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒██
░█▒▒▒███████████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒██
░██▒▒▒▒▒▒▒▒▒▒████▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒█
░░████████████░░░█████████████████

[MrBcx]

We have a separate thread on the BCX forum tracking the progress of this thread.
Expanding on a BCX user's suggestion this morning, I posted the following on our forum:

I asked ChatGpt to identify any potential pitfalls that could result
from changing "r" to "rb" for reading normal lines of text, including
utf-8. The primary warning is that Windows does not automatically
transform "\r\n" to "\n" line endings in "rb" mode.

That won't be a problem because BCX has never relied on Windows for that
translation, instead BCX uses the crt function "strcspn" to detect those
line endings and BCX itself handles termination, so very little to change.

In fact what I have changed and I'm testing now, is simply changing the
"r" file mode to "rb" when using:  OPEN "filename" FOR INPUT AS #1


That means instead of needing to change our habits to use:

    OPEN "filename" FOR BINARY READ AS #1

we continue to use

    OPEN "filename" FOR INPUT AS #1

as we always have.


This also means that "FOR INPUT" and "FOR BINARY READ" are treated identically by BCX.

I like this solution a lot.

[John Z]

You can also try changing _ftell64() to ftell() as suggested by John (you already use ftell() when compiling for LCC-Win32).

Frankie -- I tried the various forms of ftell and fseek days ago with no success. 

Yes I realize _ftell64 was a false result now. The output result does show the issue when changing to just ftell, BUT it was just the result of shortening the C code text by three bytes.  Since the C code was also the input to the test program a minor change to the code lead to the false result. 
Add the three bytes back as

Code: [Select]

pos[i] = ftell(fp);/// and the issue reappears.

Another grand slam home run for frankie on the change to rb as a workaround!

John Z

[MrBcx]

Finding people willing to participate in confirming a bug report is both fortunate and helpful.

Finding people with the willingness and experience to mitigate / defeat the bug is priceless.

You guys are fantastic!