Thread: check path validity in C99?

I need to check to see if a path exists before saving a file to it.
My function has a "filespec" variable which contains the path and file name. Is there a way to check if the path exists?

Here is the function:

Code:

int saveprnfile(void)
{ // saves formatted output to a text file to be printed
    FILE *fptr;
    char *filename = "filename";
    char filespec[79];
    input(filename,79); // get path and file name
    strcpy(filespec, lin); // copy path and file name to 'filespec'
    lin[0] = '\0';
    fptr = fopen(filespec, "a");
    fprintf(fptr,"\t\t\t%s\n\n",filespec);
    fprintf(fptr,"Header Design Suite\n");
    fprintf(fptr,"Open Source Software\n\n\n");
    fprintf(fptr,"\n\n======= Header Design Suite Input =======\n\n");
    fprintf(fptr," Bore __________________ %2.3f\n", info.bore);
    fprintf(fptr," Stroke ________________ %1.3f\n", info.stroke);
    fprintf(fptr," Comp __________________ %2.1f to 1\n", info.compratio);
    fprintf(fptr," RPM ___________________ %4.1f\n", info.maxrpm);
    fprintf(fptr," Exhaust valve opens ___ %3.1f before BDC\n\n", info.exhaustopens);
    fprintf(fptr,"==========================================\n\n");
    fprintf(fptr,"======= Header Design Suite Output =======\n");
    fprintf(fptr,"\n\nHeader: Four single primary tubes into common collector\n\n");
    fprintf(fptr,"-------------------------------------------------------\n\n");
    fprintf(fptr," Primary tube inside diameter: _ %1.3f\n\n", info.primarydia);
    fprintf(fptr," Primary tube length: __________ %2.1f\n\n", info.primarylength);     
    fprintf(fptr," Collector diameter: ___________ %1.3f\n\n", info.collectordia);
    fprintf(fptr," Collector length ______________ %2.3f\n\n\n", info.collectorlength);
    fclose(fptr);
    return(0);
}

Use stat.

Is stat C99 compliant? As I understand it stat is a system call and therefore not C99 compliant. Am I wrong/

Originally Posted by stahta01

Read about fopen and use it to check.

fopen - C++ Reference

Tim S.

Tim,
If the path exists but the file doesn't I get the same value as if the path doesn't exist. Since I am appending a non-existant file (hopefully) how would I go about separating the existance of the path from the file name?
I have used 'fopen(filespec, "r")' to check the existance of a file before writing it but is it possible to check the existance of a path while using 'fopen(filespec, "a")' ?

I guess what I am trying to understand is since the file should not exist but the path should exist how do I differentiate the two?

May I suggest mkdir()? If the directory exists, it will fail and you can check errno, otherwise the directory will be created.

Unfortunately, because C99 only defines EDOM, ERANGE, and EILSEQ errno macros, with all others defined outside the ISO C standard, in pure C99 you can only determine whether you can or cannot open a file. (Determined by fopen() returning a non-NULL file handle.)

When fopen() returns NULL, you can obtain the relevant error message using strerror(errno) (which is C99), or print an error message to standard error using perror() (also defined in C99).

Basically, in C99, all you can do is

Code:

/** savefile() - Save a struct info to a file
 * @path - File name or path
 * @info - struct info to save to file
 * This creates or truncates the file to zero bytes,
 * then writes the struct info to it.
 * Returns 0 if successful, nonzero if an error occurs.
*/
int savefile(const char *const path, const struct info *const info)
{
    FILE *out;

    if (path == NULL) {
        fprintf(stderr, "savefile(): No path specified.\n");
        return -1;
    }
    if (*path == '\0') {
        fprintf(stderr, "savefile(): Empty path specified.\n");
        return -2;
    }
    if (info == NULL) {
        fprintf(stderr, "savefile(): No data to save to '%s'.\n", path);
        return -3;
    }

    out = fopen(path, "wb");
    if (out == NULL) {
        fprintf(stderr, "savefile(): '%s': %s.\n", path, strerror(errno));
        return -4;
    }

    if (fwrite(info, sizeof *info, (size_t)1, out) != (size_t)1) {
        fprintf(stderr, "savefile(): Error writing to file '%s'.\n", path);
        return -5;
    }

    if (fflush(out)) {
        fprintf(stderr, "savefile(): A delayed error writing to file '%s'.\n", path);
        return -6;
    }

    if (fclose(out)) {
        fprintf(stderr, "savefile(): Error closing file '%s'.\n", path);
        return -7;
    }

    /* Success. */
    return 0;
}

If you want to append to the file instead of replacing the comments, use out = fopen(path, "ab"); instead. C99 defines modes r w a rb wb ab r+ w+ a+ r+b w+b a+b (and aliases rb+ wb+ ab+ for the last three).

In my opinion, especially considering that Microsoft will not implement full C99 support in its compilers, relying on the C99 standard features is rather stupid. The compilers that support C99, also have POSIX.1-2001 or POSIX.1-2008 C libraries. The existence of standardized errno values, getline(), stat(), readdir(), glob(), regcomp() and regex(), and iconv() character set conversion facilities alone make it much more useful than ISO C. Heck, I can use the above to write a simple grep example in a couple of dozen lines of C99+POSIX.1-2008 code -- without any arbitrary line length limits, either.

I really don't understand why one would rely on C99 but not on POSIX.1. Makes no sense to me.

Well, I thank you all for your time and thoughts on this issue. It seems that this is just another of C99 limitations that I will have to find a work-around for. At the very least I might be able to keep it from crashing the program.

Nominal Animal,
I am restricting myself to C99 for portability issues. Granted that C99 universal portability is a dream, it is still a good tool with wide application.
I will study your sample code and thank you for offering it.

Salem,
Thanks for your input. I will place comments in the user manual document to explain the potential hazard and how to prevent it.

Grumpy,
I was happy to see you adding to this. You and Salem are two of the folks here that I respect above some others. (I don't understand the nym 'Grumpy' because you are always factual if not kind)

Is there a way to mark the thread as solved?

Originally Posted by PaulS

I am restricting myself to C99 for portability issues.

My point was that you'll get wider portability relying on POSIX-1.2001 or POSIX.1-2008 C library features, than relying on C99.

Too bad there is no POSIX C board on this forum; it would clear up a lot of the confusion. (I personally would not be here at all if the C++ and C forums were not separated.)

As it is, a lot of Windows-specific C is discussed in the C forum, and a lot of non-Linux-specific POSIX C code is shuffled to the Linux forum, leading to either confused readers or some pedantic discussions on which set of standards/requirements a thread should abide by. No wonder most of those new to C are confused.

Originally Posted by Nominal Animal

My point was that you'll get wider portability relying on POSIX-1.2001 or POSIX.1-2008 C library features, than relying on C99.

Too bad there is no POSIX C board on this forum; it would clear up a lot of the confusion. (I personally would not be here at all if the C++ and C forums were not separated.)

As it is, a lot of Windows-specific C is discussed in the C forum, and a lot of non-Linux-specific POSIX C code is shuffled to the Linux forum, leading to either confused readers or some pedantic discussions on which set of standards/requirements a thread should abide by. No wonder most of those new to C are confused.

While I can see your point, at 64 years old, one new language is more than enough to keep me busy right now
I know nothing about POSIX. Is there a stable standard for it as there is in C? Is it an addition to C like so many "standard" C platforms in the past? - I will look it up so there is no need to answer the questions for me.