Hello,
I really don't know if this is more of a Mac of C++ question but.. I am doing a loading of a file with

short CSVload (char * filename) //called from main
{
//openning a file and checking if it exists
    FILE * datafile = NULL;
    if ((datafile=fopen (filename, "r"))==NULL)
    {
        printf ("\nError - no file found");
        return -1;
    }
//finding size of the file
    fseek (datafile,0,SEEK_END);
    int filesize = ftell (datafile);
    rewind (datafile);  
//allocating a string of a size of a file
 char * data;
    data = new char (filesize+2); //+2 just to be safe
//reading file (I am using getc but I simplified for this post) 
 fscanf (datafile,"%s", data);
//closing file
fclose (datafile);
//printing the file
 printf ("\nThe data is:\n%s",data);
//deleting data
delete [] data;
//returning success
    return 0;
}

and the program seems to be freezing every time I call this function.. I have asked somebody why this code doesn't work on OS 9.2 on G3 and the answer was that maybe I am allocating onto the system memory since OS9.2 doesn't protect it's memory like win2k or redhat 9.0 linux (my other systems). My compiler is a very old Code Warrior 7.0 Gold Edition (I usually don't use Mac's, nor this version of CW (I am only doing mac now because of my internship)).
If you can, please help,
Thank you in advance,
Ilya
:sad:

Dani AI

Generated

A short diagnosis and practical fix for anyone who finds this thread years later.

What broke: an allocation/IO combo plus an unsafe string read that leads to memory corruption. On classic Mac OS (9.x) a stray out‑of‑bounds write often hangs or crashes the whole machine because there is no hardware-enforced per-process memory protection. That explains why the same bug might behave more tolerantly on modern Windows/Linux. ’s follow-up (switching to bounded reads and parsing) matches this: using a sized buffer and never letting an unchecked "%s" or similar write past the end fixes the symptom.

Safer pattern (stay away from unbounded scanf/fscanf "%s", and make allocation size explicit):

FILE *f = fopen(filename, "rb");
if (!f) return -1;

fseek(f, 0, SEEK_END);
long len = ftell(f);
if (len < 0) { fclose(f); return -1; }
rewind(f);

std::vector<char> buf(len + 1);        // RAII: no manual delete[]
size_t got = fread(buf.data(), 1, len, f);
fclose(f);

buf[got] = '\0';                       // ensure null termination
printf("Data:\n%s\n", buf.data());

Checklist and cautions

  • Always check fopen, fseek and ftell return values before trusting sizes.
  • Match allocation and deallocation: use new[] with delete[], or better, use std::vector/std::string to avoid manual memory errors.
  • Prefer bounded reads (fgets with a size, or fread with a known buffer length) over "%s".
  • Use types that can hold file lengths (check ftell return type and handle errors).
  • If you must run on CodeWarrior/OS9, test under a debugger or a VM because system-wide hangs are likely symptoms of memory corruption rather than a mysterious OS quirk.

This explains why ’s cross-platform question came up: other OSes may hide the bug, but the root cause is the allocation/reading logic.

Recommended Answers

All 3 Replies

in my mind Linux is the best way to go when programming c/c++

The code does, indeed, work in windows or linux? Sorry, I'm not all that familiar with any mac development tools.

I actually solved that problem. And am quitee further in the program now. I am using fgets () to get the string (each string gets an feof () check) and then am parsing the string fith strtok after duplicating it with a self made (my compiler at General Atomics (internship) is not using std libs unfortunatly so I have to often make my own) strdup(); But I am way oer the loading stage now...
Ilya
P.S.: Thanks for paying attention though

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.