| | |
command line arguements.......
![]() |
•
•
Join Date: Nov 2008
Posts: 18
Reputation:
Solved Threads: 0
C Syntax (Toggle Plain Text)
#include<stdio.h> void main(int argv,char * argc[]) { int num1,num2; num1=(int)argc[1]; num2=(int)argc[2]; printf("%d\n",num1); printf("%d\n",num2); }
is there something wrong wid this code?
cus i am getting weird outputs
>is there something wrong wid this code?
Yes.
>void main(int argv,char * argc[])
main returns an int.
>num1=(int)argc[1];
>num2=(int)argc[2];
For starters, argc is the size of argv. argv is the array of strings. Next, you're expecting a cast to convert "123" to 123, which is not how things work. What a cast does is look at the same collection of bytes in a different way. Try strtol for an actual conversion from a string type to an integer type:
Finally, you should be checking the value of argc to make sure that there really are enough elements in argv to index up to 2:
Yes.
>void main(int argv,char * argc[])
main returns an int.
>num1=(int)argc[1];
>num2=(int)argc[2];
For starters, argc is the size of argv. argv is the array of strings. Next, you're expecting a cast to convert "123" to 123, which is not how things work. What a cast does is look at the same collection of bytes in a different way. Try strtol for an actual conversion from a string type to an integer type:
c Syntax (Toggle Plain Text)
num1 = (int)strtol ( argv[1], NULL, 0 ); num2 = (int)strtol ( argv[2], NULL, 0 );
c Syntax (Toggle Plain Text)
if ( argc >= 3 ) { num1 = (int)strtol ( argv[1], NULL, 0 ); num2 = (int)strtol ( argv[2], NULL, 0 ); printf ( "%d\n%d\n", num1, num2 ); }
I'm here to prove you wrong.
>Naure
How about using this assuming the numbers passed as strings are within the integer range...
Or if the coder is sure to get only singe digit numbers he/she can just use "Number" - 48 which would be faster than any of the above mentioned functions right?
How about using this assuming the numbers passed as strings are within the integer range...
c Syntax (Toggle Plain Text)
if ( argc >= 3 ) { num1=atoi(argv[1]); num2=atoi(argv[2]); printf ( "%d\n%d\n", num1, num2 ); }
Or if the coder is sure to get only singe digit numbers he/she can just use "Number" - 48 which would be faster than any of the above mentioned functions right?
I Surf in "C"....
>How about using this assuming the numbers passed as strings are within the integer range...
If your assumption holds, that's fine. But that's a pretty big assumption when it comes to user input. atoi is notoriously bad at handling errors, so it would be wise to forget that family of functions even exists.
Of course, my example isn't much better as it uses the lazy method of converting with strtol. There are a number of things that could go wrong which make that method weak in terms of robustness. But the fix is pretty verbose in comparison:
>Or if the coder is sure to get only singe digit numbers he/she can
>just use "Number" - 48 which would be faster than any of the
>above mentioned functions right?
Yes, though one shouldn't use a magic number when an abstract alternative exists. If you only need the first digit from the arguments, you can do this:
Using '0' means your code will continue to work even with character sets where '0' doesn't have a value of 48 (EBCDIC is one such character set).
Since you're interested in the nooks and crannies, I'll also explain why I used a cast in the call to isdigit. While isdigit accepts an integer argument, that integer must be either EOF or in the range of unsigned char. This is a hard rule because the typical implementation of the is* and to* functions is a lookup table. If the value is out of the range of unsigned char, you're looking at an out of bounds array access.
argv is an "array" of pointers to char, but it's implementation defined whether the vanilla char type is signed or unsigned. It's also implementation defined what values are contained in argv, which includes the range of characters. If the value is outside of the expected range without first forcing it into the correct range, the promotion to int won't fix anything, and you invoke undefined behavior by essentially saying
This isn't an issue with input functions like getchar because they're guaranteed to give you the correct values (either EOF or an unsigned char range).
If your assumption holds, that's fine. But that's a pretty big assumption when it comes to user input. atoi is notoriously bad at handling errors, so it would be wise to forget that family of functions even exists.
Of course, my example isn't much better as it uses the lazy method of converting with strtol. There are a number of things that could go wrong which make that method weak in terms of robustness. But the fix is pretty verbose in comparison:
c Syntax (Toggle Plain Text)
#include <errno.h> #include <limits.h> #include <stdio.h> #include <stdlib.h> int int_conv ( const char *src, int *result ) { char *end; long temp; errno = 0; temp = strtol ( src, &end, 0 ); /* strtol failed to cleanly get a long */ if ( !( errno == 0 && end != src && *end == '\0' ) ) return 0; /* strtol succeeded, but the value is out of range */ if ( temp < INT_MIN || temp > INT_MAX ) return 0; *result = temp; return 1; } int main ( int argc, char *argv[] ) { int num1; int num2; if ( argc >= 3 ) { if ( int_conv ( argv[1], &num1 ) && int_conv ( argv[2], &num2 ) ) { printf ( "%d\n%d\n", num1, num2 ); } } return 0; }
>just use "Number" - 48 which would be faster than any of the
>above mentioned functions right?
Yes, though one shouldn't use a magic number when an abstract alternative exists. If you only need the first digit from the arguments, you can do this:
c Syntax (Toggle Plain Text)
if ( argc >= 3 && isdigit ( (unsigned char)argv[1] ) && isdigit ( (unsigned char)argv[2] ) ) { num1 = *argv[1] - '0'; num2 = *argv[2] - '0'; }
Since you're interested in the nooks and crannies, I'll also explain why I used a cast in the call to isdigit. While isdigit accepts an integer argument, that integer must be either EOF or in the range of unsigned char. This is a hard rule because the typical implementation of the is* and to* functions is a lookup table. If the value is out of the range of unsigned char, you're looking at an out of bounds array access.
argv is an "array" of pointers to char, but it's implementation defined whether the vanilla char type is signed or unsigned. It's also implementation defined what values are contained in argv, which includes the range of characters. If the value is outside of the expected range without first forcing it into the correct range, the promotion to int won't fix anything, and you invoke undefined behavior by essentially saying
lookup_table[negative] or lookup_table[way_too_big] .This isn't an issue with input functions like getchar because they're guaranteed to give you the correct values (either EOF or an unsigned char range).
I'm here to prove you wrong.
![]() |
Similar Threads
- Calling a member function inside a class (C++)
- debugging with C++ command line arguements (C++)
- multi-client server [problem with code - please have a look] (Java)
- command line arguments (Java)
- filecopy (C)
- need help with a project (Shell Scripting)
- buffer (C)
Other Threads in the C Forum
- Previous Thread: how to write numbers in reverse order
- Next Thread: Array to an output file
| Thread Tools | Search this Thread |
#include * adobe ansi array asterisks binarysearch centimeter changingto char character cm convert copyimagefile cprogramme creafecopyofanytypeoffileinc database dynamic execv feet fgets file floatingpointvalidation fork function getlogicaldrivestrin givemetehcodez global grade gtkwinlinux hacking histogram ide inches include incrementoperators infiniteloop input interest intmain() iso kernel keyboard kilometer license linked linkedlist linux list locate looping lowest match matrix meter microsoft number oddnumber opendocumentformat opensource openwebfoundation owf pattern pdf performance pointer posix power probleminc process program programming radix recursion recv recvblocked research reversing segmentationfault sequential single socket socketprograming socketprogramming standard strchr string suggestions systemcall test threads turboc unix urboc user variable voidmain() wab whythiscodecausesegmentationfault windowsapi






