problem using FILE pointer

^___a blank required here.

^^^^_____________main returns an int - say so. void is illegal

^___ a backslash is an escape char. Use / or \\.

an fp is a FILE*. It doesn't hold an EOF.

^___ ALWAYS check the returned value from fscanf.

Try inserting spaces (not tabs) to indent your source, and to separate operators, operands, etc. That should get you started.

IOW, IAR workbench comes with C and C++ compiler, so you're going to have to write your programs in either C or C++. ;)

^.... while( !feof(fp) )

^.... &ecg[j++]

I don't know about the 8051 compiler, but the ARM compiler requires the library option to be set to "FULL" for file pointers to be supported at all. Also where are you reading the files from, presumably your 8051 does not have a C drive with long file name support? You may also want to check that semihosting is available in the 8051 if you are reading the files from elsewhere.

... snip ...

A bad suggestion. feof(fp) only signals that an EOF has been detected. Before that the following fread (or getc etc.) statement can read invalid data. All file reading calls signal when they encounter EOF.

With many compilers for limited resource processors it is quite common to support the option of a void main() especially when 'returning' from main is meaningless in these cases as it was never actually called. (Again, to save stack space.)

Some compilers complain if there's no return statement for the presumed default int return value of any function. Using void keeps the compilers quiet if nothing else.

Well, technically the functions don't "signal" - else you could use a signal handler to catch I/O errors. But they do all indicate errors through their return values. [At least if the compiler is C90 or later. If you're working with an older compiler, you can't rely on getc/putc to return anything meaningful if an error occurs - particularly if you inline macro versions. Not that you should be using those brain-dead functions anyway ... ]

George

Again, misinformation. getc and putc return EOF (a negative integer) on error or EOF. They are often the most efficient way to use the input system. The thing to watch out for with them is the fact that they can evaluate the FILE* parameter more than once. They are unique among the file handling routines in doing this, but it enables eliminating allocation of input buffers, without the disadvantages of not buffering. This behaviour only occurs if you let getc etc. be macros.

Again, misinformation. getc and putc return EOF (a negative integer) on error or EOF. They are often the most efficient way to use the input system. The thing to watch out for with them is the fact that they can evaluate the FILE* parameter more than once. They are unique among the file handling routines in doing this, but it enables eliminating allocation of input buffers, without the disadvantages of not buffering. This behaviour only occurs if you let getc etc. be macros.

Again, misinformation. getc and putc return EOF (a negative integer) on error or EOF. They are often the most efficient way to use the input system. The thing to watch out for with them is the fact that they can evaluate the FILE* parameter more than once. They are unique among the file handling routines in doing this, but it enables eliminating allocation of input buffers, without the disadvantages of not buffering. This behaviour only occurs if you let getc etc. be macros.

You are taking chances if you ever have to port the code. You are not saving stack space, you are only saving the code space for a "return 0;" in main. At least with most implementations.

You are taking chances if you ever have to port the code. You are not saving stack space, you are only saving the code space for a "return 0;" in main. At least with most implementations.

Only for modern compilers. Sorry, but what I said is correct.

The C90 (ANSI) library standard defined the error behavior for fgetc and fputc and specified that getc and putc be identical in behavior to their respective f_ functions.

K&R defined getc/fgetc to return EOF only on end-of-file. If an error occurred, getc/fgetc could return garbage. K&R defined putc/fputc to return the value it wrote. You had to check errno (or call ferror) after the I/O call to find if an error actually occurred. In the middle 80's, leading compilers added return of EOF to indicate an error and it was eventually written into the 1990 ANSI standard.

I know you were around for pre-ANSI (don't know if you go back to K&R). Maybe you've blocked it all out or maybe you had a compiler that was cutting edge, but I assure you I used compilers well into the middle 90's that behaved exactly as I described.

There were other issues with the macro versions as well. Because the return value from putc was the same as its input, some optimizing compilers would completely elide the value return code and instead simply copy the input value.

George

How does it save stack space? I've used dozens of C compilers and none of them returned int values on the stack. IOW, changing the return type from "int" to "void" wouldn't change stack usage.

Usually not even that.

I've never seen a compiler that will generate code for a "return 0;" if it's unreachable (as it generally is in an embedded system).

Any compiler that's worth using will generate the exact same code for these two cases:

int main(void) { while (1) { // do a bunch of stuff. } return 0; }

void main(void) { while (1) { // do a bunch of stuff. } }

So you might as well comply with standards and do the former.

Thanks Chuck & Grant for your input. I changed one of my projects to int main(void) and as you suggest the compiler generates the same code as it did for the void main(void) case.

The way to save stack space for main is by changing the C startup code so that you "jump" directly to main, rather than "calling" it. Of course, that's digging deeper than most people want to do, and can lead to problems if you get your C startup wrong (and it's even more fun if you are using C++).

It's worth it if you are working on a really small system, or you need to do very early custom initialisation, or if your compiler/library's C startup code is so brain-dead you want to write your own (I've seen

While the "return 0" costs nothing, I wouldn't worry too much about portability. For library code, it makes sense to be portable. For your application itself, unless you are running on top of a general purpose OS then having to change "void main(void)" to "int main(void)" is not going to be noticeable in the porting effort.

Personally, I sometimes use "int main(void)" to follow the standard, and sometimes "void main(void)" since that's what I actually *mean* - it's

I also often use "int __attribute__((noreturn)) main(void)" - that's non-portable too, but tells the compiler (and the reader) that main() won't return (and the return type is then totally ignored).

Please do not triple post, we read your post the first time, this could be regarded as spam

He probably didn't. For a couple hours yesterday my news service was timing out accepting posts. I found later that a number of things I sent were posted several times due to retries.

George