Assembling a string

[JAKE]

I'm pretty new to ansi c and I'm stuck I'm trying to assemble a string
in a called function. I need to send it three different data types and
return the assembled string. I've been getting errors such as...

28 C:\Dev-Cpp\assemble.c conflicting types for 'assemble'
3 C:\Dev-Cpp\assemble.c previous declaration of 'assemble' was here
30 C:\Dev-Cpp\assemble.c syntax error before "a"

here's what I have so far....

#include <stdio.h>

void assemble(float, int, char, char[]);

int main()
{
float a;
int b;
char c, all[6];

printf("ENTER A FLOATING POINT NUMBER:\n");
scanf("%f", &a);

printf("/nENTER A INTERGER:\n");
scanf("%d", &b);

printf("/nENTER A CHARACTER:\n:") ;
scanf("%c", &c);

assemble(a, b, c, all);

puts(all);

return 0;
}

void assemble (float *a, int *b, char *c, char *all)
{

sprintf(all,"%f , %d, %c" a, b, c);

return;
}

Am I supposed to convert the data types before I pass them to the
function?
Appreciate any help.

[Ben Pfaff]

Chris Torek <no****@torek.n et> writes:

I tend to use what has sometimes been described as "outside-in"
programming, where I attack all the problems I understand from both
the bottom and top ends, and leave the problems I do not quite
understand to be handled by the solutions to the ones that I do.

Really? In my experience, my software turns out better if I
first attack the problems that I don't already understand.
Sometimes I will build some kind of prototype of just those
parts, to allow me to experiment with different possibilities.
Afterward, I can write the routine parts of the program.
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein

[Chris Torek]

>Chris Torek <no****@torek.n et> writes:

I tend to use what has sometimes been described as "outside-in"
programming, where I attack all the problems I understand from both
the bottom and top ends, and leave the problems I do not quite
understand to be handled by the solutions to the ones that I do.

In article <87************ @benpfaff.org>,
Ben Pfaff <bl*@cs.stanfor d.edu> wrote:Really? In my experience, my software turns out better if I
first attack the problems that I don't already understand.
Sometimes I will build some kind of prototype of just those
parts, to allow me to experiment with different possibilities.
I like the experimentation approach; but I often find it hard
to write useful experiments without also writing all the support
code (file I/O, parsing, whatever). So the support code is then
done, and:
Afterward, I can write the routine parts of the program.

.... all that remains is to replace the failed experiments with
the working ones, and maybe tweak the "routine parts".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.