0

I'm trying to open the output_voice_capture.txt but it gives me a segementation fault, not only the file exists but it has read privilege.

#include <stdio.h>
#include <stdlib.h>


int main()
{
    FILE * fPtr;

    char ch;


    /* 
     * Open file in r (read) mode. 
     */
     printf("Opening file ......\n");
     fPtr = fopen("/flash/etc/output_voice_capture.txt", "r");


    if(fPtr == NULL)
    {
        /* Unable to open file hence exit */
        printf("Unable to open file.\n");
        printf("Please check whether file exists and you have read privilege.\n");
        exit(EXIT_FAILURE);
    }


    /* File open success message */
    printf("File opened successfully. Reading file contents character by character.\n");

    do 
    {    printf("Read single character from file ......\n");
        /* Read single character from file */
        ch = fgetc(fPtr);

        /* Print character read code ASCII on console */
        printf ("%d \n", ch);

    } while(ch != EOF); /* Repeat this if last read character is not EOF */


     printf("Closing file ......\n");
    fclose(fPtr);


    return 0;
}

I am using minicom which contains all the bin that I can use , the problem is that when I use linux terminal and a simple .txt test file the code works just fine.

Benjamin Maurer
  • 3,602
  • 5
  • 28
  • 49
TB1234
  • 21
  • 3
  • so debug the process and determine where that segfault occurs. – underscore_d Aug 24 '20 at 10:27
  • 4
    And what is the last message printed by the program before segfault? BTW if your platform has char unsigned by default then the program never terminates because EOF is -1. The `ch` should be `int`. – Zaboj Campula Aug 24 '20 at 10:47
  • 4
    The usual FAQ... `char ch` -> `int ch` or it won't be able to hold `EOF`. – Lundin Aug 24 '20 at 11:19
  • 1
    What kind of debugging did you do to come to the conclusion that `fopen` is causing the segfault? Don't you reach any `printf` that comes after `fopen`? If you get any output after `"Opening file...\n"` it cannot be `fopen`. – Gerhardh Aug 24 '20 at 11:37

1 Answers1

0
  1. As Zaboj Campula already said in his comment EOF is defined as an integer of -1. On some systems a char is a value from 0..255, on others from -127..128. To avoid any problems one should use the feof() function (link) to check the end of the stream. This might be the source of your problem due to the different sizes of char and int.
  2. Your code will print "File opened successfully. Reading file contents character by character." for each character read.
  3. Leave functions only at one place: at the end. This makes your code much more readable
  4. When parts of your code depend on something, enclose it with an error check.

Try this code:

int main() {
    FILE * fPtr;
    char ch;
    int result = 0;

    printf("Opening file ......\n");

    if (!(fPtr = fopen("/flash/etc/output_voice_capture.txt", "r")) {
        printf("Unable to open file.\n");
        printf("Please check whether file exists and you have read privilege.\n");
        result = EXIT_FAILURE;
    } else {
        printf("File opened successfully. Reading file contents character by character.\n");
        while (EOF != (ch = fgetc(fPtr))) {
            printf ("%d \n", ch);
        }

        fclose(fPtr);
    }
    return result;
}
mju
  • 591
  • 1
  • 6
  • 17
  • 3
    *Leave functions only at one place: at the end. This makes your code much more readable* No it doesn't. Your code has an entire compound statement in the `else` clause that is completely extraneous in the original posted code that exits immediately on failure. Your code is more complex and therefore less readable than it needs to be all because of a blind cargo-cultish devotion to some received "wisdom". And `while (!feof(fPtr))` is wrong. Read this: [**Why is “while ( !feof (file) )” always wrong?**](https://stackoverflow.com/questions/5431941/why-is-while-feof-file-always-wrong) – Andrew Henle Aug 24 '20 at 11:21
  • Thanks for the post, I corrected the code. But I wouldn't agree on the thing about readability. I prefer to have function blocks that define a clear start and end of the case instead of many exit points scattered over the function. This forces one to indent the code properly and makes clear what belongs to what. – mju Aug 24 '20 at 11:36
  • 1
    You didn't really correct the code, it still has the exact same problem. The correct sequence is read the file, then check for eof, then use the read result. You swapped check-read-use with read-use-check, neither of which is correct. – n. m. could be an AI Aug 24 '20 at 11:51
  • Right, my fault. – mju Aug 24 '20 at 12:12
  • Multiple exit points are fine. If they seem to hinder understanding, in reality the function has other problems, perhaps just being too long to see all exits. Beyond that, syntax highlighting exists, so make `return` **BOLD** if you must. The idea that indenting instead of exiting early makes code more readable is phenomenal to me... I look back on my own very old code where I wrote it like that, due to writing as a stream of consciousness, and cringe: just a nightmarish pyramid of indentation, with no reason except to get symmetry with exceptional cases, which is not a goal that makes sense. – underscore_d Aug 24 '20 at 14:56