Hhm... I just noticed even though I jumped to Win32 for development purposes well over a year ago, I''m still using all the same old standard library calls like fopen(), fgetc() and fscanf() for my file I/O needs. They were always useful in my DOS days... That''s ok, right? Riiiight? I noticed the CopyMemory() macro is just a wrapper for memcpy() (which I also still use) so my assumption was that if any "new" file routines existed they were just macroes that led to existing ones. Am I missing out on a remarkable new I/O library? I don''t like to depend on disk access too much at time critical points, so if speed is the major gain I should be ok for now. (I spent a bit too much time using an ancient Borland compiler under DOS...)

One other thing, it''s probably the other way around, that is, fopen() and chums would use the Win32 file I/O functions, not the other way around.

codeka.com - Just click it.

well, i prefer to not use the stdio simple IO.

i recently discovered this problem..

      FILE *input = fopen("IOR.ref","r");    if(!input)      {           perror("Corba IOR missing..please start repository");           exit(0);      }    fseek(input,0,SEEK_END);    char *lpszIOR = new char[ftell(input)];    rewind(input);    fscanf(input,"%s",lpszIOR);        system(lpszIOR);    fclose(input);  

.. this is a snippet from my school assignment..
the lpszIOR is complete when i examine with the visual c++ debugger..

but the program crashes on the fclose()..I have no idea why a open file would crash on a fclose().



{ Stating the obvious never helped any situation !! }

Well, for one thing, if IOR.ref contains only one line, then the line where you allocate memory for the string is one character too short, you don''t have enough space for the terminating NULL.

Chnage the line to this:

      char *lpszIOR = new char[ftell(input) + 1];  

and see if that helps.

codeka.com - Just click it.