• State Accepted Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 119 subscribers
  • Views 5746 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RVDS: file access with Real View Debugger 4.0?

ssibseya

I am using the 'Arm Workbench IDE 4.0'. And I can compile the file access functions

like Following. But when run the image using the 'RealView Debugger v4.0', I can't

find out the xxx.txt file withing the system and ARM tool's directory.

FILE        *pFile=NULL;

pFile = fopen(50, (char*)"c:\\temp\\xxx.txt", "wt");    // 50 is file identifier

rv=ferror(pFile);

rv=fprintf(pFile, "test\n");

if(pFile){

        fclose(pFile);

        pFile = NULL;}

I could have used the 'printf' with debugger tool's stdio so I think that there may be method for file management.

Can I use the file management functions?

And if so how?

Parents
  • 0 Arm Employee Badge

    fopen is defined by the C standard and you should #include <stdio.h> in files that call it.  I expect the example above to give an error when you compile it with #include <stdio.h> because fopen takes two arguments not three; remove the '50,'.  Also "wt" is not a legal mode -- but an implementation might allow it as an extension; just use "w".

    As written and without #include <stdio.h>, I would expect it to compile with a warning (about fopen being implicitly declared) and give undefined behaviour at runtime.  fopen might crash or return NULL.  You could use the debugger to stop and see what fopen is returning.

    Also:

    you should not call ferror nor fprintf if pFile is NULL; calling them with NULL is also undefined behaviour

    the (char *) cast is not needed; it's not causing any harm here, but it's a good idea to avoid casting as it prevents the compiler from helping you find type errors

Reply
  • 0 Arm Employee Badge

    fopen is defined by the C standard and you should #include <stdio.h> in files that call it.  I expect the example above to give an error when you compile it with #include <stdio.h> because fopen takes two arguments not three; remove the '50,'.  Also "wt" is not a legal mode -- but an implementation might allow it as an extension; just use "w".

    As written and without #include <stdio.h>, I would expect it to compile with a warning (about fopen being implicitly declared) and give undefined behaviour at runtime.  fopen might crash or return NULL.  You could use the debugger to stop and see what fopen is returning.

    Also:

    you should not call ferror nor fprintf if pFile is NULL; calling them with NULL is also undefined behaviour

    the (char *) cast is not needed; it's not causing any harm here, but it's a good idea to avoid casting as it prevents the compiler from helping you find type errors

Children