Re: Newbie seeking VB to ANSI C Conversion assistance

On Wed, 5 Nov 2003 16:19:41 -0500, "Jeff Goslin" <[EMAIL PROTECTED]>
wrote:

>> What happens if strlen(argv[1]) is larger than 255?  255 characters will
>be
The problem I forsee isn't with argv[1] being 255 characters.  What I
forsee is the fact that in his original message, he planned on passing
eg. Jeff Goslin  as the name, and argv[1] in that case will return
Jeff..... You'll need to do something like:

int main(int argc, char **argv, char **arge) {
int t;
char username[255];
char regcode[255];

                if (argc > 0) {
                  strcpy(username,argv[1]);
                  for (t=2; t<argc; ++t) {
                    strcat(username,argv[t]);
                               }
                          }

}

And yes, you'd want another if/then, or handle if argc is just 1.....
I just have 2 questions....

1> Why can't this program be done in Visual Basic?
2> How do you plang to pass the regcode back to the program?

>> written to userName, giving you an unterminated string.  Even if the
>prototype
>> for main were correct (it isn't) and if the code checked argc to make sure
>> that argv[1] exists before attempting to use it (it doesn't), this fact
>makes
>> this a dangerous example to follow.
>
>Yes, it has been pointed out to me that this code sample is a fairly inept
>sample set of code, but it was the sample template that was provided, so I
>thought I should stick to it as best as possible.
>
>While technically you are correct that a well written program should handle
>all idiot-user mistakes and all types of input, the practicality of the
>situation is far easier to deal with.  We make the variables substantially
>larger than they will ever need to be(who has a 250 character name, after
>all?), and everything more or less takes care of itself.  Instead of
>spending all sorts of time figuring out how users will work to break the
>code, it's going to be used so infrequently as to warrant handling
>exceptions on a case by case basis.  Risk vs Reward analysis and all that.
>I could spend many hours making DAMN sure the thing never broke, OR I could
>spend a lot less time, and just make it so huge that it'll never be pressed
>like that.  I realize that it's not the ideal way to do code, but time is
>money, and this code doesn't warrant any more time than the bare minimum to
>get it working.
>
>I can hear all you coding purists out there gasping for breath right now...
>on this job, it's just not worth it to totally idiot-proof the thing...
>Besides, I believe the argument being passed in is going to be truncated at
>250 characters or something, so we should be covered.