[SOLVED] int main(int argc, char **argv[]) having trouble getting value out of array argv[ ] C programming.

Laserbeak · 04-25-2017, 02:33 AM

You should use fgets() for security, here's a safer version:

Code:

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>

char *processInput (char *inValue);

int main (int argc, char *argv[]) {
    while (1) {
        printf("Please enter a string [max 1000 chars] (press return to quit): ");
        char *input = (char *)malloc(1001);
        fgets(input, 1000, stdin);
        input[strcspn(input, "\n")] = 0; 
        if (strlen(input) == 0)
            break;
        char *theOutValue = processInput (input);
        printf("%s\n", theOutValue);
        free (input);
        free (theOutValue);
 
    }
    return (0);
}




char *processInput (char *inValue) {
    
    //process by making all caps
    
    char *outValue =  (char *)malloc(sizeof(inValue));
    for (int i = 0; (outValue[i] = toupper(inValue[i])); i++);
    return outValue;
}

rtmistler · 04-25-2017, 07:06 AM

Might be helpful to offer the specific reference page which cites the problems with the gets() function, gets(3). This describes the actual problems with gets() more completely, and that while it has been used to break security, the main issue is that it will potentially exceed the input boundaries of the buffer it obtains input for. The referenced article in there is also a good read.

Quote:

Originally Posted by Laserbeak

I'm not sure why you're getting the "implicit declaration" message, as long as you #include <stdio.h>.

The reason why it gives the error about an implicit declaration is because the gets() function really is not in stdio.h in spite of the fact that the man page says it is. If you view your system's stdio.h I believe you'll find, as I do, that it is not defined in there. I assume because it is deprecated.

Quote:

Originally Posted by Laserbeak

This should help, but it's not particularly safe and I'll leave the storage part up to you

It seems as if you know the history of the gets() function, perhaps in the future instead of offering that particular piece of code accompanied with disclaimer, consider offering the fgets() version, and cite as added information that if the questioner happens to encounter the gets() function, that they should avoid it.

@BW-userx, as you explore C programming, are you viewing the manual pages for the library functions? I find that they are extremely helpful with explaining exactly how the function works, additional details, bugs, references to other functions of similar interest, and possible return values. I've been writing C code for about 30 years and to this day I still visit man pages for functions which I've referred to many times in the past.

BW-userx · 04-25-2017, 08:00 AM

Quote:

Originally Posted by Laserbeak

You should use fgets() for security, here's a safer version:

Code:

#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>
#include <string.h>

char *processInput (char *inValue);

int main (int argc, char *argv[]) {
    while (1) {
        printf("Please enter a string [max 1000 chars] (press return to quit): ");
        char *input = (char *)malloc(1001);
        fgets(input, 1000, stdin);
        input[strcspn(input, "\n")] = 0; 
        if (strlen(input) == 0)
            break;
        char *theOutValue = processInput (input);
        printf("%s\n", theOutValue);
        free (input);
        free (theOutValue);
 
    }
    return (0);
}




char *processInput (char *inValue) {
    
    //process by making all caps
    
    char *outValue =  (char *)malloc(sizeof(inValue));
    for (int i = 0; (outValue[i] = toupper(inValue[i])); i++);
    return outValue;
}

yeah I've been looking into with how to get data off the command line without have to open a file stream.

getchar() returns a int - which boggles my brain . I get a char knowingly then got a deal with an int when I want a char. So it has to be cast back into a char.

BW-userx · 04-25-2017, 08:08 AM

Quote:

Originally Posted by rtmistler

@BW-userx, as you explore C programming, are you viewing the manual pages for the library functions? I find that they are extremely helpful with explaining exactly how the function works, additional details, bugs, references to other functions of similar interest, and possible return values. I've been writing C code for about 30 years and to this day I still visit man pages for functions which I've referred to many times in the past.

nam pages for functions. no - only because I can only guess what they maybe called with what I know about programming and naming functions.

but things like atoi when casting char to int via a function when what comes to mind is this StrToInt which is more understandable. atoi is one function name I'd never though of.

though having the internet on hand is handy I just google it, or ask a quick question. Hoping for a quick answer.

I have not looked into this yet, but finding a "api" page that has the functions and what they do and return values - like the ones on found for free pascal when I using Lazarus.

I haven't gotten in to the full swing of it yet, Bash scripting is getting easier due to repetition. Programming is programming. Its the, "I know what I need to do" as stated from the list I did in here, now I just got to find the functions in C to do it, and loops -- brush up on loop control. etc.. Its a process.

Though I have to admit I have not sunken my head into this 100 percent yet. Been doing other things as well.

rtmistler · 04-25-2017, 08:27 AM

Quote:

Originally Posted by BW-userx

nam pages for functions. no - only because I can only guess what they maybe called with what I know about programming and naming functions.

but things like atoi when casting char to int via a function when what comes to mind is this StrToInt which is more understandable. atoi is one function name I'd never though of.

though having the internet on hand is handy I just google it, or ask a quick question. Hoping for a quick answer.

I have not looked into this yet, but finding a "api" page that has the functions and what they do and return values - like the ones on found for free pascal when I using Lazarus.

Though I have to admit I have not sunken my head into this 100 percent yet.

You can do a man on stdio, or string, or other library function names. What you'll see there is an overview of the library as well as a listing of the functions supported in the library.

To add to this, as I said earlier, the man pages refer to similar or related functions. Therefore as you go, it is helpful to expand your knowledge by viewing these pages. And when learning about getchar, you also see various other functions listed in that man page which you can look up.

Admittedly you would have to research a bit more to understand the idiosyncrasy about getchar() returning an int. If you see the man page, it cites that it returns an unsigned char, cast as an int. It also can return EOF to mean that you got no character.

The reason for this is that unsigned char cast to an int can be any value between 0x0000 an 0x00FF. EOF is typically negative 1, which as a signed character is 0xFF, therefore to be exact, there's no real way to represent the negative 1 if they kept the return variable size at 8-bits. As a result, to be clear, they chose to declare the return to be a cast of an unsigned char, allowing the pattern range shown above, and then when you actually see 0xFFFF, or 0xFFFFFFFF (depending on what an integer is sized at for your machine), you'll understand that this truly means an error return.

BW-userx · 04-25-2017, 08:54 AM

Quote:

Originally Posted by rtmistler

You can do a man on stdio, or string, or other library function names. What you'll see there is an overview of the library as well as a listing of the functions supported in the library.

To add to this, as I said earlier, the man pages refer to similar or related functions. Therefore as you go, it is helpful to expand your knowledge by viewing these pages. And when learning about getchar, you also see various other functions listed in that man page which you can look up.

me as others I am sure, am not accustom to using man pages. I usually rely on google -- looking for real world examples. But yes I did notice when you said it mention other functions as well. Which is a plus.

Quote:

Admittedly you would have to research a bit more to understand the idiosyncrasy about getchar() returning an int.

exactly that is just a first glance whatthehell that makes no sense thought. Logic states get char return char - like asking someone to pick up that glass for you then hand it to you. Then he picks up the glass and hands you a plate instead. logic. whatthehell I was expecting a glass and you give me a plate instead. Now I got a deal with that and do magic on it to turn it into a glass so I can use it.

but, their has to be a reason for it else it would not have been done like that.

Quote:

If you see the man page, it cites that it returns an unsigned char, cast as an int. It also can return EOF to mean that you got no character.

yes research is what I am slacking off on. I'm just looking into the knowledge of what it is I am using which functions and such. not the enter

Quote:

The reason for this is that unsigned char cast to an int can be any value between 0x0000 an 0x00FF. EOF is typically negative 1, which as a signed character is 0xFF, therefore to be exact, there's no real way to represent the negative 1 if they kept the return variable size at 8-bits. As a result, to be clear, they chose to declare the return to be a cast of an unsigned char, allowing the pattern range shown above, and then when you actually see 0xFFFF, or 0xFFFFFFFF (depending on what an integer is sized at for your machine), you'll understand that this truly means an error return.

see it is that low level behind the scenes stuff that i and perhaps others do not think about let alone know how that actually works.

memory addresses along with the one writing the function cannot by nay means know what the user of same said function will be doing with it. per se'

like that gets() function It was probability written with the thought in mind that who ever uses this will know exactly what it is going to be getting, or leaving up the error checking to the coder and not the developer of the function.

perhaps even due to some limitations whatever they may have been back when it was written in the knowledge of how to do things back when it was written. that too being a limitation involved in writing that function.

anyways, yes, I need to back off a little more and do some reading up first, as I have already took a step back in writing it out just haphazardly. ie. whenever I see the need then add to it, when it should be all pre-written flow char style in what needs to be done in steps which is, I think, going to be more complicated then using just one loop to keep the program running and one switch to use to call functions to do the work in this project I decided to give a try in writing.

rtmistler · 04-25-2017, 09:18 AM

I'm mixed with my feelings about legacy information being kept alive. However it also is correct in that it cites "do not use" and "deprecated", and further, the compiler is on board with this even in the native configuration where you don't need to add any extra compile flags to catch that particular warning.

In fact, the dicey parts of that documentation are probably some of the best formed questions one can ask in this very forum.

I feel it is very helpful with coding to develop a technique which works for you. Clearly, I'm sharing my style, but you are free to develop your own style, which is best.

The parallel I can draw to that is how have you developed your effectiveness on LQ or other similar sites? You've paid attention, thought about what works better to be able to find topics you can contribute towards, you've learned to clarify your own questions, and feedback, and you've learned how to use the interface more effectively. Plus you probably have learned about the various situations where you have newbies who are spammers, trolls, or non-native English speakers, and learned how to try to contend with those various situations.

Same thing for coding.

I think you're doing fine by the way. Remind yourself that it is not rocket science, and that many, many others do this stuff all the time, on an everyday basis. My conclusion there (OK ego) is that there is therefore no reason why "I", in your case "you", can't do the same, once you put your mind to it.

Keep up the great efforts!

Laserbeak · 04-25-2017, 09:28 AM

Quote:

Originally Posted by rtmistler

Might be helpful to offer the specific reference page which cites the problems with the gets() function, gets(3). This describes the actual problems with gets() more completely, and that while it has been used to break security, the main issue is that it will potentially exceed the input boundaries of the buffer it obtains input for. The referenced article in there is also a good read.The reason why it gives the error about an implicit declaration is because the gets() function really is not in stdio.h in spite of the fact that the man page says it is. If you view your system's stdio.h I believe you'll find, as I do, that it is not defined in there. I assume because it is deprecated.It seems as if you know the history of the gets() function, perhaps in the future instead of offering that particular piece of code accompanied with disclaimer, consider offering the fgets() version, and cite as added information that if the questioner happens to encounter the gets() function, that they should avoid it.

@BW-userx, as you explore C programming, are you viewing the manual pages for the library functions? I find that they are extremely helpful with explaining exactly how the function works, additional details, bugs, references to other functions of similar interest, and possible return values. I've been writing C code for about 30 years and to this day I still visit man pages for functions which I've referred to many times in the past.

gets() is defined in my <stdio.h> (Mac OS X)

And, yes, I probably shouldn't have put it code I posted, but it is a shortcut and he doesn't seem to be developing anything for distribution or an Internet application.

Laserbeak · 04-25-2017, 09:53 AM

Quote:

Originally Posted by NevemTeve

Function 'gets' mustnot be used. Since around 1970. I was two year old then, now I am 49.

You'd be surprised how often I see it in code used by corporations for essential tasks. At least this was a learning experience!

The problem with fgets() is that it also captures the end-of-line character(s), which may not be desired and differ from system to system.

Changing

Code:

        input[strcspn(input, "\n")] = 0;

to

Code:

        input[strcspn(input, "\r\n")] = 0;

solves that problem with MS-DOS/Windows (whose EOL is "\r\n") as far as reading the string (while still working with UNIX since strcspn() detects any of the characters in the string you pass it), but when you print it out, you don't know what characters to use unless your compiler automatically changes "\n" to the appropriate end-of-line character(s) for the system. I think many MS-DOS/Windows compilers do that, but I'm not sure, I have very little experience programming on that platform. In fact, I've had little problem with this at all since I'm mainly doing Mac OS X/iOS programming now and everything is object-oriented and a GUI and all that stuff is taken care of for you usually and it's guaranteed to be UNIX and the EOL is "\n" (I think the api also accepts "\r" at least in several uses for historical reasons since that was the end-of-line character in the Classic Mac OS).

ntubski · 04-25-2017, 10:23 AM

Quote:

Originally Posted by Laserbeak

solves that problem with MS-DOS/Windows (whose EOL is "\r\n") as far as reading the string (while still working with UNIX since strcspn() detects any of the characters in the string you pass it), but when you print it out, you don't know what characters to use unless your compiler automatically changes "\n" to the appropriate end-of-line character(s) for the system. I think many MS-DOS/Windows compilers do that, but I'm not sure, I have very little experience programming on that platform.

If you open the stream in text mode, the newline difference are automatically handled according to the operating system (although this doesn't help if you want your software to handle DOS line endings on a POSIX system).

BW-userx · 04-25-2017, 10:37 AM

Quote:

Originally Posted by Laserbeak

gets() is defined in my <stdio.h> (Mac OS X)

And, yes, I probably shouldn't have put it code I posted, but it is a shortcut and he doesn't seem to be developing anything for distribution or an Internet application.

naw. this started due to a game I have on my iPhone, Yathee. as I play against the computer. I sit and watch it. I see how the computer does what it does. it rolls the dice, then selects them, how does it know which ones to elect? I see what it selects then I try to determine why them dices.

then it rolls again, and I see it change it's "mind" then ask myself why did it do that?

if it has a pair of sixes and it needs sixes why did it remove the sixes and select something else?

what is the logic behind it?

three rolls each turn.

How does it rationalize the choices it makes against what it already has made, against what it needs to score and what are the odds of completing what it already started out with, against changing its mind and selecting something else and trying for that instead in mid turn?

the logic and rationalization behind it fascinates me.

So I think to myself, the code behind it has to be very complex for the computer to know "when to hold them and when to fold them" along with when to change its mind and try for something different instead while still playing the odds because it cannot know what is going to be rolled next. Unless he cheated. Which can be done in programming too.

Nevertheless, this logic and rationalization that is programmed into the game itself for the program to use came from man. It is the getting it from ones own brain and into a program for the cpu to use is the real trick. Is it not?

because man can change his mind in an instance if he wants to. Having the data to make that decision for man to use before he does or does not and if he does not, he then can just make it up his own self to replace a truth that should have been there before hand before making that choice in what to do or not do, have the proper data to use he can still change his mind. But this is playing the odds of what might be true against what does actually happen next instead because it is always in the unknown. faith and hope are now in play when doing this too. More hope then faith.

it is the why (motivation, emotional or not) behind it that determines the logic that is being used. the rationalization behind it, if it is irrational then that throws off the logic. Emotions rid rational thinking. This is why I see what I see in here. How peoples brains work. That is just a figure of speech sometimes. When it is not working properly.

Computers do not have emotions, but they still can be programed to use logic and rationalization and give an emotional response. But not an emotional act as a result of the response. The response being something said.

If it was to preform an emotional act then that program would then have to throw an error on purpose then crash if the emotion was strong enough. The ability to think can and will completely disappear and the person can only rely on someone else doing there thinking for them. A mental break down is had if it becomes bad enough. one can no longer think for themselves, I cannot even think straight, is a common phrase. A computer cannot have a complete mental break down, can it? yes it can. then it has to rely on a different CPU to take over.

Nonetheless, this how a computer does what it does is all determined by a human behind a keyboard, or a bunch of humans behind keyboards in what that program will or will not do on a case by case situation.

The error handing is a different situation. The program can and will throw errors or exploded - seg faults if they are not handled properly. that too is all determined by a human.

but to end this long thought(for now). it is all because of a game that by observing it I became curious how to make it do what I do, and do not even think about how I do it, I just do. so I decided to try and figure it out. How to tell a piece of metal with electricity running through it to think and make decisions like man does when the odds are at play. Which is not a good way to live ones life. Always taking chances because that can end in death. Game over you lose because one did not play the odds properly.

What all is entailed in writing a program that uses logic and rationalization behind an unknown, and when to change its mind in mid-term in hopes of obtaining something else instead that it too needs to gain an over all score that will lead to winning the game?

how does it know when it should change its mind?

Especially when it already has a good hand. A lot of conditions have to be programmed into that, or will just a algorithm suffice? how to write that algorithm, let alone an algorithm? Because I have no real experience in that, that I know of.

Too I've noticed that it cannot find a pattern that I have found that gives better odds of obtaining my goal of gaining when i can put it to use when trying to get what is called a boat in this version of Yathee.

Hopefully I did not bite off more then I can chew. Because I do have to take baby steps in this C programming. Due to not having a lot of experience in that language. Therefore a commination break down takes place.

just like life.

yep all of that from a game. it all goes into writing a computer program. with me anyways. transposing

Laserbeak · 04-25-2017, 11:43 AM

Quote:

Originally Posted by BW-userx

naw. this started due to a game I have on my iPhone

If you want to do iPhone programming, you'll need to learn Objective-C. It's actually quite more advanced than plain C since you have a much better object-oriented API available. For giggles and since I have nothing else to do, I rewrote this program in Objective-C. This level of Objective-C you should be able to install on Linux. You just don't get the Mac OS X or iPhone GUI.

Code:

//NOTE: Must be saved as main.m not main.c to tell the compiler it is Objective-C not plain C

#import <Foundation/Foundation.h>

NSString *processString (NSString *inString);

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

    while (1) {
        printf("Please enter a string (press return to quit): ");
      
        NSString *inputString =  [[[NSString alloc] initWithData:[[NSFileHandle fileHandleWithStandardInput] availableData] 
                 encoding:NSUTF8StringEncoding] 
                 stringByTrimmingCharactersInSet:[NSCharacterSet newlineCharacterSet]];
        
        if ([inputString length] == 0)
            break;
        
        NSString *outputString = processString (inputString);
        
        printf("%s\n", [outputString cStringUsingEncoding:NSUTF8StringEncoding]);
        
    }
    return (0);
}

NSString *processString (NSString *inString) {
    return [inString uppercaseString];
}

This has no safety problems and will accept a string as long as your application can allocate the space for.

To actually program an iPhone, you'd need a Mac (or maybe a Hackintosh would work, but it might not with Apple Developer status?) and become an Apple Developer (to actually run it on the iPhone, the Mac has a simulator installed, and to actually post it on the App Store and sell it or give it away.)

rtmistler · 04-25-2017, 11:53 AM

@BW-userx I feel that you are spot on with a key core concept, which is to understand the logic behind what to do within your program, as opposed to worrying about how to write it as well as the choice of language.

I fully understand the concept of experimenting with code. You are asking the correct questions, for instance when you identify a questionable warning or error in compilation, it is a good idea to determine what the cause of it is. And per your original question, you were attempting to properly understand how passing arguments and pointers work within the language.

BW-userx · 04-25-2017, 12:14 PM

Quote:

Originally Posted by Laserbeak

If you want to do iPhone programming, you'll need to learn Objective-C. It's actually quite more advanced than plain C since you have a much better object-oriented API available. For giggles and since I have nothing else to do, I rewrote this program in Objective-C. This level of Objective-C you should be able to install on Linux. You just don't get the Mac OS X or iPhone GUI.

no no no , it is just that the game happened to be on my iPhone. it is its logic and reasoning within that game. How did they get it to do that?

where I think just plan C or whatever can be used. Maybe in a Bash Script even. can show me how that happened. But I would still be shooting in the dark regardless in how to get it to think like a human regardless of what language I use. Due to a two part operation.

what to do?
how to do it?

first identifying what to do, then figuring out how to get the computer to do it. the Language one uses still gets taken down to zero's and one's regardless of which one is used.

therefore, that part is then left to what did "they" write that language to be able to do? In order to best pick the language to use.

this is basic command line
input
data processing with numbers
storing it
then spitting it back on to the screen.
No GUI needed.
where a number of languages can do this.

Laserbeak · 04-25-2017, 12:21 PM

Quote:

Originally Posted by BW-userx

no no no , it is just that the game happened to be on my iPhone. it is its logic and reasoning within that game. How did they get it to do that?

where I think just plan C or whatever can be used. Maybe in a Bash Script even. can show me how that happened. But I would still be shooting in the dark regardless in how to get it to think like a human regardless of what language I use. Due to a two part operation.

what to do?
how to do it?

first identifying what to do, then figuring out how to get the computer to do it. the Language one uses still gets taken down to zero's and one's regardless of which one is used.

therefore, that part is then left to what did "they" write that language to be able to do? In order to best pick the language to use.

I'm not familiar with this game, maybe I'll try to download it to my iPhone, is it free?

Anyway, maybe someday you'll want to start programming your iPhone. It's pretty fun and if you get a good idea for an app you can make lots of money!