Segmentation fault (core dumped)

Hi,

I am trying to work with pictures on C++, and I would like to obtain the size in bytes of a given picture.
However, the following message shows:
"Segmentation fault (core dumped)".
All the suggestions online are very vague so I am a bit lost and not sure how to move forward.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <stdio.h>
#include <string.h>
#include <sys/socket.h>
#include <arpa/inet.h>   
#include <unistd.h>  
#include <iostream>
#include <fstream>
#include <errno.h>

using namespace std;

int main(){
FILE *picture;
int size, read_size, stat, packet_index;

picture = fopen("home/Desktop/pics/picture.jpeg", "rb");
if(picture == NULL) {
        printf("Error Opening File");
    } 

size = ftell(picture);

printf("Total Picture size: %i\n",size);



return 0;
}
you are mixing c and c++ like mad. Are you trying to write C or c++ here??
I am using c++. Unfortunately as a beginner, the syntax looks almost the same to me so is sometimes hard to tell the difference.
C++ came from C and much of the syntax is indeed identical. And you 'can' use C in c++ but its not usually considered good to mix them in one code file but rather have some C files and some c++ files that are distinct if you need to mix, and if you don't need to mix, keep to one language.

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <fstream>
//#include <filesystem>
#include <iostream>

int main()
{
 // cout std::file_size("x.cpp";)  //I think this does it if your compiler supports it.  mine is missing filesystem
 //or simply
 std::ifstream ifs("x.cpp", std::ios::ate);  //ate puts the file pointer at the end so the tell gives you the size.  
 unsigned int filesize = ifs.tellg();
 std::cout << filesize << std::endl;
 
}


1
2
3
4
 Directory of C:\c
01/30/2020  03:09 PM               309 x.cpp
C:\c>a
309


and your code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#include <stdio.h>  //C c++ this is called <cstdio>
#include <string.h>  //C.  Prefer <string> for string type in c++ not char array
#include <sys/socket.h> 
#include <arpa/inet.h>   
#include <unistd.h>   //os specific
#include <iostream> 
#include <fstream>
#include <errno.h>

using namespace std;  //bad habit.  But I do it too on short programs.  see 1000 threads on it in the forum. 

int main(){
FILE *picture;  //FILE* is C,  use ofstream (ofstream and ifstream)
int size, read_size, stat, packet_index;

picture = fopen("home/Desktop/pics/picture.jpeg", "rb"); //fopen is C, use stream.open or constructor(filename)
if(picture == NULL) {
        printf("Error Opening File"); //printf is C, use cout 
    } 

size = ftell(picture);  //ftell is C, use tellg() as I did

printf("Total Picture size: %i\n",size);



return 0;
}
Last edited on
unfortunately filesystem is not supported either on my hand. Moreover, if possible, I would like to preserve most of my code. Isn't there another way to fix this?
I thought my code could be read with a c++ compiler.
yes, c++ compilers support C and c/c++ mixed.
Yes, you can fix it. I think you need to add a seek eof to your code so the file pointer is at the end of the file so the tell will give the correct response. But my C is getting rusty... you should be able to find this in 2 seconds online (google file size in C) if that is not the correct fix. It may also work if you open the file wb+, which I think is the same as 'ate' in c++ and sticks the pointer at the end for appending.

I hacked out something that seems to work:

1
2
3
4
5
6
7
int main ()
{
   //FILE* fp = fopen("x5.cpp", "rb");
   FILE* fp = fopen("x5.cpp", "a");
   //fseek(fp,0,SEEK_END);
   cout << ftell(fp) << endl;   	
}


wb+ ate my file, lol. Don't do that one.
FILE* fp = fopen("x5.cpp", "a"); is what that should have been. If you do that, you can skip the fseek line entirely -- this is the right way to do it, but the above is left in for reference in case you need to seek later.

I highly advise you to learn the c++ code though. If you have tons of code already, fixing it may be too much work, but next time...
Last edited on
Topic archived. No new replies allowed.