Problem Outputting Command Line Arguments from argv

[Matt]

Hello. I'm having a very strange problem that I would like ot check
with you guys.

Basically whenever I insert the following line into my programme to
output the arguments being passed to the programme:

printf("\nComma nd line arguement %d: %s.", i , argv[i] );

The porgramme outputs 3 of the command line arguements, then gives a
segmentation fault on the next line, followed by other strange
behaviour.

Does outputting the command line arguments change them or some other
aspect of the programme somehow? The programme runs fine when I
comment the line out, which just makes no sense to me!

Kind Regards,

Matt

[Matt]

Forgot to mention, the code above should compile so feel free to give
it a try.

[Keith Thompson]

Matt <ma*****@hotmai l.comwrites:
[...]

I have tried replacing "case 'c':" with "case '-c':" and so forth in
the case statements starting on line 92, but the source code would not
compile.

I'm a little surprised it didn't compile, but using '-c' is nonsense.
Multi-character character constants have implementation-defined
values, and should be avoided. '-c' and "-c" are entirely different
things.

I think a large part of the problem is that you're trying to program
by wild guessing. You need to understand what you're doing *before*
you write or modify your code. Making random changes will most likely
cause your code to fail to compile. If by chance it still compiles,
it probably won't work. If by chance it appears to work, that's
probably just bad luck; it's *very* easy in C to write incorrect code
that happens to "work" because you got lucky with undefined behavior.

Correctly working C code is a very small target, tightly surrounded by
code that's incorrect in various subtle ways. The only way to hit the
target is to know where it is and aim at it directly.

Study your text book (K&R2 is good), decide what you want to do,
figure out how to do it, and do it.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Old Wolf]

On Jul 24, 2:15 am, Matt <matt...@hotmai l.comwrote:

char *getopt_val;
[...]
if (getopt_val == -1)

This is an error. If you did not get a compiler
warning or error here, then you need to learn
how to invoke your compiler properly.

I can't suggest what the 'correct' code would
be, because you haven't posted any of the
code for 'getopt_long'. Perhaps you would get
better answers by posting your program on a
newsgroup where 'getopt_long' is topical
(possibly a GCC group or a Unix programming group).

switch (*getopt_val)

You should check that getopt_val is not NULL
before doing this.

Also, don't put too much stock in any debugger
report that one particular piece of code is the
problem, they often get it wrong, especially if
you haven't compiled your code to disable optimizations.

printf ("option %s", long_options[option_index].name);

if (optarg)

You haven't declared 'optarg' anywhere, as far as I can see.

[Barry Schwarz]

On Mon, 23 Jul 2007 14:15:38 -0000, Matt <ma*****@hotmai l.comwrote:

>I have just tried running the code given from the GNU Example page,
and as I should have expected, the code was fine.

Now when I put my own implementation of this code (which is of course
very similar) by itself, I got a segmentation fault whenever I put in
an argument such as "-c" or "-stack" that the programme is meant to
recognise and act upon. The problem does not occur if I use "c" or
"stack":

// A programme to test my implementation of the getopt_long function
in an independant environment from the main programme

#include <stdio.h>
#include <stdlib.h>
#include <getopt.h>

static int stack_mode = 0;

int main( int argc , char *argv[] )

{

extern int stack_mode;

Other than hiding the previous object with this name, what do you
think this accomplishes?

>
char *getopt_val;
int i;

opterr = 0;

printf("argc = %d\n",argc);

for ( i = 0 ; i < argc ; i++ )

{

printf("argv[%d] = %s\n",i,argv[i]);

}

for ( i = 0 ; i < argc ; i++ ) // argc is the number of command line
arguments passed to the programme.

{

while (1)

{

static struct option long_options[] =

{

// These options set a flag.
{"stack" , no_argument , &stack_mode , 1}, // Enable stack
(convolution ) mode

// These options don't set a flag. We distinguish them
by their indices.
{"configfile " , required_argume nt , 0 , 'c'},
{0 , 0 , 0 , 0}

};

// getopt_long stores the option index here.
int option_index = 0;

getopt_val = getopt_long (argc, argv, "c:", long_options,
&option_index) ;

// Detect the end of the options.
if (getopt_val == -1)

getopt_val was defined above as a char*. -1 is an int. You cannot
compare an int to a pointer this way. What is the real return type of
getopt_long? This statement is a constraint violation that requires a
diagnostic.

>
{

break;

}

switch (*getopt_val)

{

case 0:
/* If this option set a flag, do nothing else now. */
if ( long_options[option_index].flag != 0)

{

Judicious use of white space makes your code readable. Double spacing
nearly every statement doesn't qualify.

break;

}

printf ("option %s", long_options[option_index].name);

if (optarg)

What is optarg?

>
{

printf (" with arg %s", optarg);

}

printf ("\n");
break;

case 'c':
printf ("option -c with value `%s'\n", optarg);
break;

case '?':
/* getopt_long already printed an error message. */
break;

default:
abort ();

}

}

/* Print any remaining command line arguments (not options). */
if (optind < argc)

{

printf ("non-option ARGV-elements: ");

while (optind < argc)

What is optind?

>
{

printf ("%s ", argv[optind++]);

}

putchar ('\n');

}

}

}

I have tried replacing "case 'c':" with "case '-c':" and so forth in
the case statements starting on line 92, but the source code would not
compile.

It still doesn't.
Remove del for email

[Matt]

I have tried replacing "case 'c':" with "case '-c':" and so forth in

the case statements starting on line 92, but the source code would not
compile.

I'm a little surprised it didn't compile, but using '-c' is nonsense.
Multi-character character constants have implementation-defined
values, and should be avoided. '-c' and "-c" are entirely different
things.

Good point. Ta for the advice as well.

[Keith Thompson]

Matt <ma*****@hotmai l.comwrites:

I have tried replacing "case 'c':" with "case '-c':" and so forth in
the case statements starting on line 92, but the source code would not
compile.

I'm a little surprised it didn't compile, but using '-c' is nonsense.
Multi-character character constants have implementation-defined
values, and should be avoided. '-c' and "-c" are entirely different
things.

Good point. Ta for the advice as well.

I wrote the paragraph starting with "I'm a little surprised it didn't
compile ...".

Once again, please stop snipping attribution lines. You can see a
line at the top of the article "Matt <ma*****@hotmai l.comwrites:".
There was a similar line above what I wrote in your followup, but you
deleted it. Delete whatever quoted material isn't relevant to your
followup, but if you quote anything by an author, *leave the
attribution line in place*.

Not only is it simply polite to give credit (or blame) for anything
that you quote, it makes the conversation easier to follow.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Matt]

On Jul 24, 7:31 pm, Keith Thompson <[e-mail] rote:

Matt <matt...@hotmai l.comwrites:

I have tried replacing "case 'c':" with "case '-c':" and so forth in
the case statements starting on line 92, but the source code would not
compile.

I'm a little surprised it didn't compile, but using '-c' is nonsense.
Multi-character character constants have implementation-defined
values, and should be avoided. '-c' and "-c" are entirely different
things.

Good point. Ta for the advice as well.

I wrote the paragraph starting with "I'm a little surprised it didn't
compile ...".

Once again, please stop snipping attribution lines. You can see a
line at the top of the article "Matt <matt...@hotmai l.comwrites:".
There was a similar line above what I wrote in your followup, but you
deleted it. Delete whatever quoted material isn't relevant to your
followup, but if you quote anything by an author, *leave the
attribution line in place*.

Not only is it simply polite to give credit (or blame) for anything
that you quote, it makes the conversation easier to follow.

--
Keith Thompson (The_Other_Keit h) [e-mail] <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

No problem

[Keith Thompson]

Matt <ma*****@hotmai l.comwrites:

On Jul 24, 7:31 pm, Keith Thompson <[e-mail] rote:

[...]

> Delete whatever quoted material isn't relevant to your
followup, but if you quote anything by an author, *leave the
attribution line in place*.

[snip]

>
No problem

Thanks, but please re-read the above. Don't quote signatures unless
you're actually commenting on them. Don't quote an entire article
unless you're commenting on everything that was said (or it's short).
Include just enough context so your followup makes sense to someone
who didn't see the parent article, no more, no less.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"