spawn() functions in Metrowerks CodeWarrior C
Rod Smith
I'm trying to use Metrowerks CodeWarrior 4.0 to compile a Win32 program
originally written in Microsoft Visual C. The code uses the spawnlp()
and spawnv() functions to start other programs, but I can't get
Metrowerks to work with these. Specifically, although the prototypes for
these functions do reside in the process.h file that's included from the
Metrowerks directory tree, the linker gripes that it can't find the
functions when link time rolls around. I can't find mention of these
functions in the on-line documentation. So, does Metrowerks support
these functions, and if so, how do I get them linked into my program?
While I'm at it, I'm having similar sporadic problems with the strdup()
function in other programs. Metrowerks handles some of these programs
fine, but chokes on others at compile time. The strdup() function is at
least simple enough that re-implementing it isn't a big deal, but I'd
rather not have to do it.
Any tips on either of these problems are greatly appreciated.
--
Rod Smith
rods...@fast9.uceprotect.net
http://www.users.fast.net/~rodsmith
NOTE: Remove the digit and following word from my address to mail me
Jack Klein
> Hi,
>
> I'm trying to use Metrowerks CodeWarrior 4.0 to compile a Win32 program
> originally written in Microsoft Visual C. The code uses the spawnlp()
> and spawnv() functions to start other programs, but I can't get
> Metrowerks to work with these. Specifically, although the prototypes for
> these functions do reside in the process.h file that's included from the
> Metrowerks directory tree, the linker gripes that it can't find the
> functions when link time rolls around. I can't find mention of these
> functions in the on-line documentation. So, does Metrowerks support
> these functions, and if so, how do I get them linked into my program?
>
> While I'm at it, I'm having similar sporadic problems with the strdup()
> function in other programs. Metrowerks handles some of these programs
> fine, but chokes on others at compile time. The strdup() function is at
> least simple enough that re-implementing it isn't a big deal, but I'd
> rather not have to do it.
>
> Any tips on either of these problems are greatly appreciated.
<Jack>
The functions spawnlp() and spawnv() are not part of the C language,
not is the header process.h, nor is strdup() for that matter, they are
all extensions provided (or not provided) by particular compilers or
operating systems.
There is really nothing that the C language has to say that can help
you here. If your compiler claims ANSI compliance, it can't provide
any of these functions if set to compile in strictly conforming mode.
In any event what we discuss here is the language as defined by the
ANSI/ISO International Standard, and we try to stay away from specific
compiler details, especially when they concern non-standard
extensions.
The usual recommendation is to post to a newsgroup which supports your
particular compiler, but that is a real problem in your case, since my
ISP shows only 2 groups out of more than 18,000 which it carries which
have "codewarrior" in their name, and they are for Mac and Palm Pilot.
The real problem is that the original program used non-standard
extensions. Perhaps if you replaced these functions (spanw* with
system(), for example) you could avoid the problem.
Otherwise you might have a compiler option set to disable certain
extensions (like Microsoft's /zA switch). Your only other choice is
to contact the vendor's tech support.
</Jack>
MW Ron
> Hi,
>
> I'm trying to use Metrowerks CodeWarrior 4.0 to compile a Win32 program
> originally written in Microsoft Visual C. The code uses the spawnlp()
> and spawnv() functions to start other programs, but I can't get
> Metrowerks to work with these.
These are not standard C functions and you'll need to call a Windows API
call to spawn other applications.
> While I'm at it, I'm having similar sporadic problems with the strdup()
_strdup is supportded as a non standard function that is what you should use.
> Any tips on either of these problems are greatly appreciated.
You may want to post thes in newsgroups.
comp.os.ms-windows.programmer.tools.misc
or
comp.sys.mac.programmer.codewarrior (they are friendly to Windows questions)
Ron
--
http://www.zdnet.com/pcweek/stories/news/0,4153,361176,00.html
Pro 4.0 C++ 30% edge in Tak benchmark over VC++ 6.0
Battle of the Java development tools By Rex Baldazo
http://www.builder.com/Servers/RexTech/111698/?dd.cn
METROWERKS - Ron Liechty - MW...@metrowerks.com
Lawrence Kirby
jack...@att.net "Jack Klein" writes:
...
>The functions spawnlp() and spawnv() are not part of the C language,
>not is the header process.h, nor is strdup() for that matter, they are
>all extensions provided (or not provided) by particular compilers or
>operating systems.
>
>There is really nothing that the C language has to say that can help
>you here. If your compiler claims ANSI compliance, it can't provide
>any of these functions if set to compile in strictly conforming mode.
It can as long as
a) it puts any declarations for them in non-standard headers or headers
where the identifier is reserved (e.g. strdup() in <string.h> ).
b) it implements some sort of weak linking such that user definitions of
the functions in strictly conforming programs override any system
supplied code.
A conforming impolementation isn't required to accept only strictly
conforming programs.
>In any event what we discuss here is the language as defined by the
>ANSI/ISO International Standard, and we try to stay away from specific
>compiler details, especially when they concern non-standard
>extensions.
Certainly as far as comp.lang.c is concerned.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Jack Klein
<Jack>
I went into more detail than I commonly do because there doesn't
appear to be even a support group available for the Windows port of
this compiler, which I would personally take as a strong suggestion to
avoid it.
I usually have no complaint about your corrections to my posts,
Lawrence, but I don't see how strdup() can be provided by an
implementation when instructed to compile in strictly conforming mode,
regardless of whether it is placed in string.h or not, considering the
explicit wording of the introductory paragraph of 7.13.
Of course I am willing to hear discussion.
</Jack>
--
Do not email me with questions about programming.
Post them to the appropriate newsgroup.
Followups to my posts are welcome.
MW Ron
jack...@att.net (Jack Klein) wrote:
> I went into more detail than I commonly do because there doesn't
> appear to be even a support group available for the Windows port of
> this compiler, which I would personally take as a strong suggestion to
> avoid it.
There are two newsgroups where you can post question concerning
CodeWarrior for Windows
comp.sys.mac.programmer.codewarrior
and
comp.os.ms-windows.programmer.tools.misc
You can also post in comp.programming with CW, MW, CodeWarrior in the
title and I'll find it there.
So don't let the lack of a newsgroup become a reason to avoid CodeWarrior.
Jack Klein
wrote:
> In article <36958591....@netnews.worldnet.att.net>,
> jack...@att.net (Jack Klein) wrote:
>
> > I went into more detail than I commonly do because there doesn't
> > appear to be even a support group available for the Windows port of
> > this compiler, which I would personally take as a strong suggestion to
> > avoid it.
>
> There are two newsgroups where you can post question concerning
> CodeWarrior for Windows
>
> comp.sys.mac.programmer.codewarrior
> and
> comp.os.ms-windows.programmer.tools.misc
>
> You can also post in comp.programming with CW, MW, CodeWarrior in the
> title and I'll find it there.
>
> So don't let the lack of a newsgroup become a reason to avoid CodeWarrior.
>
> Ron
<Jack>
I am aware of the two groups with "codewarrior" in their name, the
other one apparently for the Palm Pilot, but when you compare that to
the dozens of groups which Microsoft and Borland sponsor for their
products, it seems apathetic on the part of the manufacturer not to
provide some space on a server to sponsor a support group or two for a
commercial product. Especially when attempting to move into a new
operating system. I would never think of posting to a Mac group it I
had a question about a Windows compiler.
My opinion only, of course. I have never used one of your compilers
and so have no opinion on its quality one way or the other.
Lawrence Kirby
jack...@att.net "Jack Klein" writes:
(Sorry, this seems to be one I overlooked earlier)
...
>I usually have no complaint about your corrections to my posts,
>Lawrence, but I don't see how strdup() can be provided by an
>implementation when instructed to compile in strictly conforming mode,
>regardless of whether it is placed in string.h or not, considering the
>explicit wording of the introductory paragraph of 7.13.
It is precisely because strdup() is reserved that the implemenetation can
define it. When an indentifier is reserved it means that a strictly
conforming program cannot declare or define it. That means that a an
implementation can declare or define it and be sure that doing so won't
interfere with the correct operation of any strictly conforming program.
Therefore doing so does not violate the primary requirement that a
that a conforming implementation must accept any strictly conforming
program (or indeed any other requirement on a conforming implementation).
It is possible for an implementation, even in strict mode, to provide
extensions that might conflict with a future version of the standard.
But as C9X proves that will happen whether it pays any attention to
"future library directions" or not.