C software achitecture

[hatman]

If func() is always going to allocate memory,
then it's best for func to return a pointer
and not take one as as argument.

char *func(char* command);

func would return either NULL, if allocation was unsuccessful,
or a pointer to memory.

For a real C programmer (as you, i think), this function definition
mean that the malloc is done in the function ?? So you will do a free
of the returned buffer afterward ?

Thanks 4 your help..

Joël.W

 

[pete]

For a real C programmer (as you, i think), this function definition
mean that the malloc is done in the function ??
Yes.

So you will do a free of the returned buffer afterward ?

Yes.

 

[hatman]

Ok, now i will have enough informations to write "the best" function
....

Thanks a lot for your help,

Joël.W

 

[Dave Thompson]

On Sat, 25 Jun 2005 18:17:45 +0100, Roger Leigh

That's correct. popen is not the right tool for the job. If you
write a popen equivalent that works the other way around (that's what
those calls can be used to do), you can achieve this:

pipe() creates a pipe, and after you fork(), you use dup2() in the
child to replace stdout (fd 2) with the writing end of the pipe. When
the child is running, the parent can then read() everything sent to
stdout at the reading end of the pipe, and add it to a
dynamically-allocated buffer. This is the platform-specific [POSIX]
stuff you need to ask elsewhere about.

Um, except for allocating the buffer, this is exactly what the
suggested POSIX-but-not-C popen ("command", "r" /* or maybe rb */)
plus fgetc etc. does. It's true you can instead do it yourself with
(customarily) system calls, but that doesn't make popen wrong.

- David.Thompson1 at worldnet.att.net

 

[Roger Leigh]

On Sat, 25 Jun 2005 18:17:45 +0100, Roger Leigh

That's correct. popen is not the right tool for the job. If you
write a popen equivalent that works the other way around (that's what
those calls can be used to do), you can achieve this:

pipe() creates a pipe, and after you fork(), you use dup2() in the
child to replace stdout (fd 2) with the writing end of the pipe. When
the child is running, the parent can then read() everything sent to
stdout at the reading end of the pipe, and add it to a
dynamically-allocated buffer. This is the platform-specific [POSIX]
stuff you need to ask elsewhere about.

Um, except for allocating the buffer, this is exactly what the
suggested POSIX-but-not-C popen ("command", "r" /* or maybe rb */)
plus fgetc etc. does. It's true you can instead do it yourself with
(customarily) system calls, but that doesn't make popen wrong.

I stand corrected. I guess I am biased somewhat against popen()
because when I do this, I generally want non-blocking I/O, and C FILE*
streams are not suitable for that.


Regards,
Roger