Borland command line compiler issues.

Hi there;
My questions are about the free Borland command line compiler & tools (v5.5.1).
No it's not the usual "How do I install it all and compile a program" questions, it's all installed and running, but it does seem a bit twitchy and I was wondering how other people find it and what advice you could all offer. Perhaps some hidden and undocumented gem of information that will make my life a lot less stressful again. ;)
I recently upgraded my OS from Win95 to Win2000, and so decided to upgrade my old 16-bit Borland Turbo C 3.1 suite to a 32-bit compiler.
It should probably be stated at this point that I only program as a hobby, in C.
Why is it then that some of my old source code compiles into an executable program with no worries at all, and yet others absolutely refuse to?
All kinds of strange things are happening. In some programs the code: textcolor(LIGHTCYAN); is enough to change the colour of the output. In other programs though I've had to use the longwinded SetConsoleTextAttribute (GetStdHandle(STD_OUTPUT_HANDLE), FOREGROUND_INTENSITY | FOREGROUND_GREEN | FOREGROUND_BLUE); to achieve the same result, and for no apparent reason. If left in the original shorete form, the text of the output is plain old lightgray.
The most common problem is an error message which pops up after running a newly compiled executable which states that "The instruction at <address> referenced memory at <address>: the memory could not be read" and that the program must be terminated.
It is all so very frustrating... Please help:confused:
I'd be very interested to hear anyone elses thoughts or comments on how to tame this particular compiler.

Thanks for the reply Salem.
I've had a lot of trouble lately trying to get access to this site.
Pointers are indeed looking like the most likely suspect at this stage however I don't see why.
I declare a file pointer: FILE *fptr;
I open the file:fptr = fopen("MyData.dat", "r");
The program itself simply checks a few hundred lines of data, each consisting of 14 temperatures, and it prints out a report of out of spec values.
However it does need to parse the data file twice and so I use rewind (fptr); in the middle of the process.
I finish by closing the file: fclose (fptr);

I recently read that "fclose()" should return a value: ret = fclose(fptr);
Is this some update to ANSI C since I learned it on Turbo C v3.1? It doesn't solve the problem though. Does "rewind ()" still work?

But it all worked fine with BCC 3.1! That is the really really annoying part.
BTW what is a 'stricter environment'?

Hey I think I've got it.
My call to fgets would read each line of data from my text file and temporarily store it in a variable declared as:
char *LineFromFile;
By simply changing this declaration to...
char LineFromFile[21];
...and without changing anything else, my program now works fine.
No more error messages:)
And lightning quick compared to the 16-Bit compiled version. Best of all my monitor doesn't try to blow itself up when the DOS console pops into existence.

I guess this is an example then of using an uninitiated pointer?
How should I really be declaring my pointers when I use them in this way?

Quote:

---

My call to fgets would read each line of data from my text file and temporarily store it in a variable declared as:
char *LineFromFile;
By simply changing this declaration to...
char LineFromFile[21];
...and without changing anything else, my program now works fine.

---

It's amazing that it ever worked at all in the first place. If that's the only thing you've changed, then you were using your pointer without ever allocating space for it.

I doubt you actually initialized it to point at anything, otherwise it wouldn't compile now.

A rule of thumb with pointers: Always initialize before using. Always make sure they're actually pointing at something you're allowed to use. (IE: Allocate space before using.) Really, the "always initialize before using" applies to any varaible type...

Quzah.

Quote:

---

Yeah, but are you doing
fgets( LineFromFile, 21, fptr )
Because if you're lying about the size of the buffer to fgets, it's still wrong.

---

Absolutely! I made the declaration match the number of bytes already used in the fgets statement... ( Although I did ponder the merits of declaring an array of 22 elements - 21 + a terminating NULL character. However, 21 bytes is more than enough for the purpose. )

Anyway thanks for the pointer advice, I shall now have to spend some time reviewing a lot of my old Win95/16-Bit program code if I want to compile it into Win2K/32-bit executables.

You'd think that the people who teach you this stuff at tech would warn you of such potential flaws in your code and discourage you from using it in assignment after assignment... I think most of these institutions exist merely to make money off impoverished students!