Programming

I don't know. I do know that v 8.0 of RH has a version of perl that supports large files, so the rest of the OS must also comply.

Try man fopen64

Thanks a lot.
I also don't know whether my system supports or not.

If i assume my system does not support can you suggest me some way to change my code according to the system otherthan using a different linux filesystem?
How do i make the pointers support to open a big file?

Because you didn't expect to do this at the outset, put a few global
variables at the top of the code, then add two small functions:

Code:

#include <stdlib.h>
/* global variables */
unsigned long byte_count=0;
int debug_file_count=0;
char *debug_file_name="/path/debug";
FILE *dbg=NULL;
/* ..........................  further on --- */
void dbg_file_open(void)
{
    char tmp[256]={0x0};

    sprintf(tmp,"%s%d",debug_file_name,debug_file_count++);
    dbg=fopen(tmp,"w");
    if(dbg==NULL)
    {
         perror("Error opening debug file");
         exit(EXIT_FAILURE);
    }
    byte_count=0;
}


void write_debug_file(char *string)
{
    char tmp[256]={0x0};
    size_t len=strlen(string);
    if(dbg==NULL  || byte_count + len > 0x7fffffff)
    {
        dbg_file_open();
        
    }
    byte_count+=len;
    fprintf(dbg,"%s\n",string);
}

Thanks.
All the answers were very helpful.
Thank you all.

jim,

I would like to add few points,
prior opening to new file through dbg_file_open function, close the previously opened file, else the last batch of writes done to the previous file is not guaranteed to be flushed.

the need for char tmp[256] in write_debug_file ???

You're right about closing the file, my bad. However - 256 appears arbitrary. It is not.
Whatever file record length he/she expects, best practice dictates using a variable that is decalred to be significantly larger.

However - and don't get me going on this - picking lengths that are just one char longer than the record leads to trouble in production systems, if the program deals with data derived from any external source. And the memory savings is not worth the cost of debugging and fixing it later on, because some users did not follow procedures.


If you're worried about memory, which, within reason, is basically not merited except in embedded systems or realtime processing, check your requirements. I seldom see - "must run in less than 10MB of memory" - as a stipulated requirement. It's the same issue as using floats instead of doubles because it "saves memory" or "is faster".
The "is faster" is debatable, and is hardware dependant, plus floats are often promoted to doubles. The "saves memory" is usually correct except that what you gain is not worth what you lose - 9 digits of precision.

my question abt tmp[] is not abt the allocation of 256.
simple as that; where the variable tmp is made use of in the program,
if thats for use in later point of the program.. then it is self-answered,

besides the effort spent in debugging for a mistake where the developer had deliberately missed out sentinel byte allocation for a variable is cumbersome
and pathetic. Pt noted.