procbuf.h no longer supported?

procbuf.h no longer supported?

[Justin Miller]

I'm having trouble locating procbuf.h. Is procbuf no longer supported in
gcc 3.2.2?? If so, what should one use instead? The old popen?

Regarding popen, why exactly does the first argument have to be a
char**? Why couldn't it have been a char* instead?

Thanks!

Justin

Re: procbuf.h no longer supported?

[John Love-Jensen]

Hi Justin,

No procbuf.h on my machine.

I do have...
/usr/include/mach/i386/processor_info.h
/usr/include/mach/machine/processor_info.h
/usr/include/mach/ppc/processor_info.h
/usr/include/mach/processor.defs
/usr/include/mach/processor.h
/usr/include/mach/processor_info.h
/usr/include/mach/processor_set.defs
/usr/include/mach/processor_set.h
/usr/include/machine/proc.h
/usr/include/sys/proc.h

But all those are platform specific.  There is no procbuf.h in the C and C++
standards.

Are you sure that procbuf.h isn't part of your platform header files (the OS
or machine architecture)?

--Eljay

Re: procbuf.h no longer supported?

[John Love-Jensen]

Hi Justin,

Will you be porting to GCC on Windows, or to MSVC++?

You may want to make an abstraction layer, with an implementation that is
platform-centric.

Take a look at the <dirent.h> header file (which doesn't exist in MSVC++
6.0sp3, but does in GCC 3.2 for Windows/Cygwin), which is useful for walking
a directory, or traversing a directory hierarchy (or both).

<dirent.h> is available on Darwin 6.6, SunOS 5.8, Windows/Cygwin.

Not available on "old" Mac OS (CFM / PEF) API.

I cannot remember if <dirent.h> is available on Amiga OS.

--Eljay

Re: procbuf.h no longer supported?

[Justin Miller]

On Wed, 2003-07-02 at 10:43, John Love-Jensen wrote:

> They are NOT ANSI compliant.  If your code is intended to be ANSI compliant
> or ANSI portable, I would not use popen/pclose.

ANSI compliant would probably be a good thing. What solution is ansi
compliant?

> Depends on what you are trying to do, what your target platforms are, if you
> intend to distribute your code and/or binary executables, and which version
> of GCC you are using.

Basically, we want to scan the files in a given directory without using
some native unix/linux commands so as not to tie it too directly to the
platform because eventually (not necessarily in the near future) this
could be ported to Windows. I'm using gcc v3.2.2.

Justin