What am I doing wrong?

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*.

Here is the code.

int tokeniseInput(char readstring[])
{
char *cp;
const char delimiters[] = " ,'\n'";

proc = readstring;

smStrings *stockmarket;

cp = strdup(readstring);

stockmarket->smsdate = strtok(cp, delimiters);
printf("process1 = %s\n", stockmarket->smsdate);
stockmarket->smsopen = strtok(NULL, delimiters);
printf("process2 = %s\n", stockmarket->smsopen);
stockmarket->smshigh = strtok(NULL, delimiters);
printf("process3 = %s\n", stockmarket->smshigh);
stockmarket->smslow = strtok(NULL, delimiters);
printf("process4 = %s\n", stockmarket->smslow);
stockmarket->smsclose = strtok(NULL, delimiters);
printf("process5 = %s\n", stockmarket->smsclose);
stockmarket->smsvolume = strtok(NULL, delimiters);
printf("process6 = %s\n", stockmarket->smsvolume);

return 0;
}

--
"I disapprove of what you say, but I'll defend to the death your right
to say it." - Voltaire

Cromulent wrote:

<snip>

This is the code I have at the moment for my readline function, it is
just a slightly modified version of a function in K&R2. The only
problem is that limit needs to be set arbitarily high which is
wasteful.
>
int readLine
(FILE *fp, int limit, char readstring[], smStrings *stockmarket)
{
int x = 0, i = 0;

You might want to consider using unsigned long for limit. This will
allow the loop to read more than 65535 characters. As written your
limit is 32767 characters.

for(i = 0;
i < limit -1 && (x = fgetc(fp)) != EF && x != '\n';
++i) {
readstring[i] = x;
if(readstring[i] == '\n')

This condition can never be true, since execution will never enter the
loop if fgetc had returned a '\n' character.

{
readstring[i] = x;
++i;
}
}
readstring[i] = '\0';
printf("%s\n", readstring);
tokeniseInput(readstring, stockmarket);
return i;
}
<snip>

Tue, 08 Jul 2008 09:12:12 +0000, Richard Heathfield posted:

jacob navia said:
>
>Richard Heathfield wrote:
>>
>Perhaps Mr Navia would be so kind as
to point out where CU claims that pointers are always 32 bits?)
>>
>Specifically in Chapter 11, page 353 you assume
>sizeof pointer is equal to sizeof int
>
I don't see it. I *do* see where I assume that sizeof(int **) is equivalent
to sizeof(int *), which is itself a bug - one that was first reported (by
Chris Mears) and published (almost) EIGHT YEARS AG - but a far cry from
assuming that pointers are always 32 bits. I can't see the number 32
anywhere on that page.

I don't see it quite like you say it. You give three different methods for
resizing arrays. All three look significantly different. Is it one of
those assumptions that fouls the whole thing?

other thing, I was poking around n1256.pdf to find out what guarantees
there are on the width of an int. I found:

A ¡¥¡¥plain¡¦¡¦ int object has the natural size suggested by the
architecture of the execution environment (large enough to contain any
value in the range
INT_MIN to INT_MAX as defined in the header <limits.h>).

and

¡Xminimum value for an object of type int
INT_MIN -32767 // -(2 15
- 1)
¡Xmaximum value for an object of type int
INT_MAX +32767 // 2 15
- 1

Are there circumstances in which a C int object is 47 bits?
--
The only really happy folk are married women and single men.
H. L. Mencken

8 Jul 2008 at 23:51, Richard Heathfield wrote:
If you want me to help you out by pointing out your mistakes, you need to
convince me that it has become worthwhile to help you - that you are
capable of learning from such help, and able to receive it in a civilised
manner. And if you want to convince me of that, you're not making your
task any easier by hurling abuse.

It's abundantly clear from this one paragraph that there's absolutely no
danger of Bill losing out on any "help" from you - but if he's lucky you
might killfile him and then he'll miss out on a load of patronizing
garbage dispensed from on high.