Hello all,

Let's say I have a vector like so:

vector < char *>rlist;

and

char* word;

Let's say char* word was pointing to a 9 character word, like
"statement".

If I were to do

rlist.push_back(word)

I would get a seg fault. I believe this is because push_back expects a char*, which is only 1 byte long.

Anyway I can "increase" the size of char* so that the push_back function can work properly with a char* that is greater than 1 byte?

Thanks.

Recommended Answers

All 11 Replies

I was able to run the following code on my machine. Word* has the same size as char *. I don't know if maybe I'm missing something or if the conditions are different (I'm using gcc 3.4.2 in Vista64).

#include<iostream>
#include <vector>
using std::cout;
using std::endl;
using std::vector;
int main()
{
	vector <char *> charvec;
	char * undef;
	char * word = "statement";

	cout <<"Char*"<<" "<<sizeof(char *)<<endl;
	cout <<"word"<<" "<<sizeof(word)<<endl;
	charvec.push_back(undef);
	cout <<"undef push succeeded"<<endl;
	charvec.push_back(word);
	cout<<"word push succeeded"<<endl;
	return 0;
}

If you get seg fault while pushing char* to vector<char*> the problem lies somewhere else.
Show us the rest of your code.

sizeof( any pointer ) is always the same -- sizeof returns the number of bytes it takes to store the address of the pointer, not the length of the string the pointer references. So lines 12 and 13 of your code will always return the same value (probably 4).

line 14: you are attempting to store an unitialized pointer into the vector. undef points to just some random memory location, and that may cause a seg fault, especially if you later attempt to do anything with that pointer.

sizeof( any pointer ) is always the same -- sizeof returns the number of bytes it takes to store the address of the pointer, not the length of the string the pointer references. So lines 12 and 13 of your code will always return the same value (probably 4).

line 14: you are attempting to store an unitialized pointer into the vector. undef points to just some random memory location, and that may cause a seg fault, especially if you later attempt to do anything with that pointer.

It was meant as an illustrative example more than anything... line 14 was my attempt to reproduce his error which did manifest but I understand your point about it failing in the future.

Thanks for the help so far. Here is the my code which causes the crash:

#include <stdio.h>
#include <string.h>
#include <iostream>
#include <vector>
using namespace std;
int j;
char line[256];
int main()
{
	FILE* in = stdin;
	vector < char *>rlist;
	char *word;
    for (j = 0; j < 2; j++) {
	fgets(line, 256, in);
	word = strtok(line,"  \n");
	rlist.push_back(word);
	char* temp = new char ();
	if (word==NULL){
	temp=NULL;
	}
	else{
	strcpy(temp, word);
	}
	while (word != NULL) {
	word = strtok(NULL, "  \n");
	if (word!=NULL){
	strcpy(temp, word);
	rlist.push_back(temp);
	}
	}
	}
	return 0;
}

And I've tested with 2 input files. One contains:
123456789 123456789 (which will seg fault)
while the other contains:
12345678 12345678 (which won't seg fault)

Now that I think about it, strcpy is probably causing it, but I'm not sure why..

1) line 15: you need to check of strtok() returns NULL.

2) line 19: memory leak. You allocated a character on line 17 then toss it away at line 19.

3) line 22: temp has only been allocated to hold one character, yet you are attempting to copy an entire string into it. This is probably what is causing your program to seg fault.

strtok should be fine even if it assigned null, I added the (if word==null) check in case.

Forgot to add free(temp) there, oops!

Finally, by allocating more for temp, did you mean something like,
char* temp = new char[16]?

sizeof( any pointer ) is always the same

That happens to be true for the garden variety PC of today, but it is not true as a generic statement.

Thamls Ancient Dragon, my program ran great (with this subroutine part fixed) :)

>> sizeof( any pointer ) is always the same

>> That happens to be true for the garden variety PC of today, but it is not true as a generic statement.

Also, on the same system fat pointers are bigger than normal pointers... http://en.wikipedia.org/wiki/Function_pointer#Method_pointers

Never heard of a "fat" pointer before now.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.