I think I know what the problem is. I'm passing an array to strdup() which is not what it wants and is producing a bus error. But, even knowing the cause of the problem I'm having difficulties thinking of a suitable solution.
I'm basically reading a CSV file and then tokenising it to get the relevant values in a useable form. So I need to read the file one line at a time in order to tokenise each one and put the values in the correct place but I can't think of a way off the top of my head to read a single line at a time using a function which would put it in a malloced char*.
On 2008-07-06 02:22:41 +0100, Cromulent <cromul...@justextrememetal.com> said:
> proc = readstring;
Bah, ignore this bit. I deleted it from my code after I copied it to my post and forgot to delete it. -- "I disapprove of what you say, but I'll defend to the death your right to say it." - Voltaire
Cromulent <cromul...@justextrememetal.com> writes: > I think I know what the problem is. I'm passing an array to strdup()
No you are not despite appearances.
> which is not what it wants and is producing a bus error. But, even > knowing the cause of the problem I'm having difficulties thinking of a > suitable solution.
> I'm basically reading a CSV file and then tokenising it to get the > relevant values in a useable form. So I need to read the file one line > at a time in order to tokenise each one and put the values in the > correct place but I can't think of a way off the top of my head to > read a single line at a time using a function which would put it in a > malloced char*.
You don't need to read one line at a time. In fact that can make the parsing of a CSV file harder (or at least, it can fail to make it simple).
> Here is the code.
> int tokeniseInput(char readstring[])
readstring is a pointer despite the []. C can't pass arrays and rather than forbid this syntax it was taken to mean the same as char *readstring in the context.
Odd. You know you have two 's in there? ' is not even special in CSV files as far as I know.
> proc = readstring;
OK, ignoring this as per you other message.
> smStrings *stockmarket;
Not pointing anywhere. Using it with -> will cause undefined behaviour.
> cp = strdup(readstring);
You will get a memory leak if you don't record the cp pointer somewhere (it won't always be returned by the first call to strtok). Without it you can't free the memory, ever.
> stockmarket->smsdate = strtok(cp, delimiters);
Bang! stockmarket->smsdate is undefined unless stockmarket has been made to point to the right sort of thing.
> readstring is a pointer despite the []. C can't pass arrays and > rather than forbid this syntax it was taken to mean the same as char > *readstring in the context.
> Odd. You know you have two 's in there? ' is not even special in CSV > files as far as I know.
Ah I meant it to be '\n' not ' and \n if that makes sense. They were meant to be enclosing the newline character as I was not sure if it was needed or not. I guess not.
>> smStrings *stockmarket;
> Not pointing anywhere. Using it with -> will cause undefined behaviour.
How do you mean? It points to a typedefed struct which is declared in the header file.
>> cp = strdup(readstring);
> You will get a memory leak if you don't record the cp pointer > somewhere (it won't always be returned by the first call to strtok). > Without it you can't free the memory, ever.
> This will only work if your input is very simple. The slightest > unexpected thing like an empty field or a comma in a field and it all > goes haywire.
It is just stock market data downloaded from Google Finance. No real chance of any funny input. But I see your point.
-- "I disapprove of what you say, but I'll defend to the death your right to say it." - Voltaire
> readstring is a pointer despite the []. C can't pass arrays and > rather than forbid this syntax it was taken to mean the same as char > *readstring in the context.
No, that wasn't the reason, as a matter of fact. In the early days of C, pointers were described using [] rather than *. It wasn't long before the * was introduced, at which point [] was used exclusively for arrays, *except* in this situation - i.e. a function receiving a pointer as a parameter. Just why it was retained, I don't know - possibly a nod in the direction of backwards compatibility.
<cromul...@justextrememetal.com> wrote: >I think I know what the problem is. I'm passing an array to strdup() >which is not what it wants and is producing a bus error. But, even >knowing the cause of the problem I'm having difficulties thinking of a >suitable solution.
The real error is not in the code you posted. You need to provide a complete compilable program that demonstrates the undesired behavior.
>I'm basically reading a CSV file and then tokenising it to get the >relevant values in a useable form. So I need to read the file one line >at a time in order to tokenise each one and put the values in the >correct place but I can't think of a way off the top of my head to read >a single line at a time using a function which would put it in a >malloced char*.
>> Not pointing anywhere. Using it with -> will cause undefined behaviour.
> How do you mean? It points to a typedefed struct which is declared in > the header file.
stockmarket is a pointer. But it isn't pointing AT anything. You need to allocate some memory for the object.
>> This will only work if your input is very simple. The slightest >> unexpected thing like an empty field or a comma in a field and it all >> goes haywire.
> It is just stock market data downloaded from Google Finance. No real > chance of any funny input. But I see your point.
:-) I like your optimism in the accuracy of google!
You may want to consider what happens when they add/delete/change a column however.
On 2008-07-06 05:41:52 +0100, Barry Schwarz <schwa...@dqel.com> said:
>> I'm basically reading a CSV file and then tokenising it to get the >> relevant values in a useable form. So I need to read the file one line >> at a time in order to tokenise each one and put the values in the >> correct place but I can't think of a way off the top of my head to read >> a single line at a time using a function which would put it in a >> malloced char*.
> Look up fgets in your reference.
That is what I use already. -- "I disapprove of what you say, but I'll defend to the death your right to say it." - Voltaire
