Merrill & Michele wrote:[color=blue]
> I am determining how best to call an already compiled c program from
> another. The following is a program that compiles and shows the information
> passed:
> //Text1.cpp[/color]
Most C implementations compile source files whose
names end in ".c" (although the C language Standard does
not require this). Names ending in ".cpp" are often used
for source files containing C++, a quite different language
with some superficial similarities to C. By calling your
file "Text1.cpp" you may inadvertently have told your
compiler to expect C++ source, and this is likely to create
confusion if you're trying to write C. Double-check your
setup to make sure it's doing what you intend.
[color=blue]
> #include <stdio.h>
>
> int main(int argc, char* argv[])
> {
> int i;
>
> for (i=0;i<=argc;i++)
> printf("%d\t%s\n",i,argv[i]);[/color]
The final execution of this loop produces undefined
behavior, because `argv[argc]' is guaranteed to be NULL.
When you pass NULL to the "%s" specifier, there's no
telling what might happen. Suggested fix: Re-examine
the ending condition for the loop, and consider how it
might be changed to avoid this problem.
[color=blue]
> return (0);[/color]
You know that the parentheses, though harmless, are
unnecessary, right? Good.
[color=blue]
> }
>
> The following was my first attempt to call this program with somethingthat
> mimicks K&R §5.10. It compiles, but my linker didn't like it.[/color]
When you ask for help with an error message whose
content or import you don't understand, please supply
the exact and complete text of the message. "My linker
didn't like it" isn't very informative, and requires the
reader to guess what happened. Twenty Questions was never
my favorite game.
My guess is that your linker liked it just fine, and
that you've mis-reported what went wrong.
Oh, and by the way: *my* linker doesn't like turnips.
[color=blue]
> Do I put it
> in a separate project and hard code the path? Is there a better way togo
> about this than a system call? Do I just forget about it and go get my
> nails done? MPJ[/color]
"Project?" It seems your problem may not be with the
C language at all, but with the incantations that get your
implementation to do its thing. If so, you need help from
a newsgroup or other forum where people familiar with your
development environment (whatever it is) hang out. All we
can do here is help you with the C questions; getting the
C to execute correctly on System X or System Y or System Z
is not our forté.
Getting your nails done seems a good idea: it'll make it
easier to tear your hair out.[color=blue]
>
>
> //text2.cpp
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(int orange, char* apple[])
> {
> system("Text1 fruit flying Dutchmen");[/color]
One possible -- or even likely -- source of difficulty
is that although system() itself is a Standard library
function, its argument string's meaning is implementation-
specific. Depending on your platform, you might need a
system() argument like
"./Text1 fruit flying Dutchmen"
"..\\Project1\\Text1 fruit flying Dutchmen"
"MCR TEXT1 FRUIT FLYING DUTCHMEN"
... or perhaps an incantation even more bizarre. Again,
this is a question for your System X/Y/Z friends, not for
the C language folks.
[color=blue]
> return (0);
> }[/color]
My (weakly founded) suspicion is that many of your
difficulties arise from trying to learn both C and the
ins and outs of an "integrated development environment"
at the same time. When something goes awry, you don't
know whether there's a problem with your C or with the
way the IDE has been configured. I'd *strongly* suggest
that you put the IDE aside until your grasp of C improves;
this will eliminate a rich source of screw-ups and thus
simplify the diagnostic process. Prepare your C source
with an ordinary editor, and run the compiler from the
command line -- I'd suggest you should even avoid the
widely-available "make" utility until you're at least to
the point of writing programs with multiple source files.
Good luck!
--
Eric.Sosman@sun.com 
