Two problems with std::cin.getline()

I am having two issues with the std::cin.getline() function.

Here is the relevant portion of my code:

Code:

---

std::cout << "Enter administrator password to unlock the database file" << std::endl;
               
while (!datafileVerified)
{
    std::cin.getline(adminPassword, MAX_PASSWORD_LENGTH+1);
    passLength = std::cin.gcount() - 1;
    datafileVerified = verifyDatafile(adminPassword);
    if (!datafileVerified) { std::cout << "Incorrect admin password, try again" << std::endl; }
}

---

MAX_PASSWORD_LENGTH is 16 so cin.getline() should accept 17 characters (16 + NULL).

First question:
When I input 16 characters or fewer cin.gcount() - 1 returns the correct number of characters (I don't want the NULL counted, hence the -1). So if I put in 16 characters gcount() - 1 gives returns 16. If; however, I input 17+ characters then gcount() -1 always returns 15. I put in more and it gives me less. What gives?

Second question:
When I put in an incorrect password, the call to verifyDatafile will fail and return 0. The variable datafileVerified is initialized to 0. If I input 16 or fewer characters this block of code works as expected, if the password is incorrect it continues to prompt the user for the password again. If; however, I input 17+ characters it skips the cin.getline() every time it goes through the loop and simply loops infinitely! What gives?

Thanks.

Why don't you just use the getline() function and use std::string instead anyway?

If you give getline 17 as a parameter, it will not read more than 16 characters in. And, as you correctly noticed, 16-1 equals 15.

Also, if you type in extra characters, the characters not read in will still be there in the next iteration of the while loop. (You shouldn't see an infinite loop -- 16 to 31 characters should give you two iterations, 32 to 47 three, etc.)

I am not trying to say something discouraging, but given how you seem to have a lot of confusion about char buffers why not just use std::strings? Its more robust for this type of application anyway. Unless 16 is a magic number for some sort of encryption you have implemented (perhaps you have colaberated with Kevin and his encryption technique that would require 5000+ years for a large amount of data to be decrypted).

Quote:

---

Originally Posted by tabstop

If you give getline 17 as a parameter, it will not read more than 16 characters in. And, as you correctly noticed, 16-1 equals 15.

Also, if you type in extra characters, the characters not read in will still be there in the next iteration of the while loop. (You shouldn't see an infinite loop -- 16 to 31 characters should give you two iterations, 32 to 47 three, etc.)

---

Ok, I had an inkling that might be the issue. Is there anyway to flush stdin to get rid of any extra input?

Quote:

---

Originally Posted by master5001

I am not trying to say something discouraging, but given how you seem to have a lot of confusion about char buffers why not just use std::strings? Its more robust for this type of application anyway. Unless 16 is a magic number for some sort of encryption you have implemented (perhaps you have colaberated with Kevin and his encryption technique that would require 5000+ years for a large amount of data to be decrypted).

---

I've already dedicated too much time to this program to replace all my char buffers with std::string. I know how char buffers work. I was mainly hoping there was a way to discard extraneous input from stdin after a call to cin.getline().

cin.ignore()

Quote:

---

Originally Posted by tabstop

cin.ignore()

---

cin.ignore() asks for a number of characters to ignore. Is it safe to pass a huge number like INT_MAX to it?

Wouldn't know why not. Be sure to use it only when you know there's extra input, though.

Such things can always be tried, you know. Particularly when you ask a question that is somewhere between obvious and implementation specific.

Quote:

---

Originally Posted by tabstop

Wouldn't know why not. Be sure to use it only when you know there's extra input, though.

---

Er...I can never *know* there's going to be extra input. I mean...there has to be a way to accept input safely in C++. There has to be a way to allow for input into a buffer with a fixed upper bound that doesn't break when someone tries to overflow it. I mean...right? It has to exist! I thought cin.getline() was the answer. What should I use instead?

Quote:

---

Originally Posted by master5001

Such things can always be tried, you know. Particularly when you ask a question that is somewhere between obvious and implementation specific.

---

The point of asking for help in a forum is to gain the benefit of peoples' experiences. I'm not going to input 2 million some odd characters to see if it breaks if someone else already knows the answer.

You need to know whether the \n was found and discarded, so you want to use the input operation that doesn't actually discard the \n character. That input operation is "get". (Of course, this means that you have to discard the \n yourself, but hey.)

INT_MAX is not that large and in cases like these, if it works once, it works always.

At any rate, yes, there is a way, call

ignore(<big_number>, '\n');

The default sequence delimiter is EOF, but you can use other things, as shown.

Fair enough, max. I would think of it this way: is it a case of all your input is desireable except for the pesky new line at the end of each line? Is it always "pesky" and never "useful?" Sometimes there are instances where you may want to skip a character. Like a colon or a dash or whatever. So generally speaking, skipping all of them is fine unless your implmentation requires a character to only be skipped in a set interval.

This has always served me well.

Code:

---

ignore((unsigned)-1, '\n');

---

Though in your case, perhaps

Code:

---

ignore(MAX_PASSWORD_LENGTH, '\n');

---

Would make the most sense.

Quote:

---

Originally Posted by tabstop

You need to know whether the \n was found and discarded, so you want to use the input operation that doesn't actually discard the \n character. That input operation is "get". (Of course, this means that you have to discard the \n yourself, but hey.)

---

Ok, when I replace getline with get I no longer need to decrement gcount by 1 to get the actual number of characters read however I still have the same issue with the infinite loop when the user provides too much input. How am I supposed to test for the '\n'?

master5001, the problem with that approach is that allows ONLY 16 characters, not up to and including 16 characters.

Quote:

---

Originally Posted by maxhavoc

Ok, when I replace getline with get I no longer need to decrement gcount by 1 to get the actual number of characters read however I still have the same issue with the infinite loop when the user provides too much input. How am I supposed to test for the '\n'?

---

If the string ends with a \n, there's no new input so don't do anything.
If the string doesn't end with an \n, there's something still in the buffer.
Note you have to do this before stripping off the \n to compare with your password. (I would say, if there's more input in the stream, the input is automatically wrong, ignore and continue; otherwise check as above.)

Quote:

---

Originally Posted by tabstop

If the string ends with a \n, there's no new input so don't do anything.
If the string doesn't end with an \n, there's something still in the buffer.
Note you have to do this before stripping off the \n to compare with your password. (I would say, if there's more input in the stream, the input is automatically wrong, ignore and continue; otherwise check as above.)

---

So what you're saying is do something like:

Code:

---

cin.get(inputString, 16);
if (inputString[cin.gcount()] == '\n')
  good;
else
  bad;

---

>> master5001, the problem with that approach is that allows ONLY 16 characters, not up to and including 16 characters.

Code:

---

ignore(MAX_PASSWORD_LENGTH+1, '\n');

---

The point is, even if you don't care if there are a total of 1,342,312,678,793,163 '\n' characters put into the text box, you can only possibly see so many at one given time. Thus there is no need to use MAX_INT or (unsigned)-1 or any other exceedingly large numeric value. MAX_CHAR is already more than the buffer can hold. Thus cin won't even need to look past MAX_PASSWORD_LENGTH + 1.

Quote:

---

Originally Posted by maxhavoc

So what you're saying is do something like:

Code:

---

cin.get(inputString, 16);
if (inputString[cin.gcount()] == '\n')
  good;
else
  bad;

---

---

Well, sort of; by "good" I mean call the verifier function thing and by "bad" I mean call ignore. And that 16 needs to be 18 (one for the new line, and one for the \0).

Quote:

---

Originally Posted by master5001

>> master5001, the problem with that approach is that allows ONLY 16 characters, not up to and including 16 characters.

Code:

---

ignore(MAX_PASSWORD_LENGTH+1, '\n');

---

The point is, even if you don't care if there are a total of 1,342,312,678,793,163 '\n' characters put into the text box, you can only possibly see so many at one given time. Thus there is no need to use MAX_INT or (unsigned)-1 or any other exceedingly large numeric value. MAX_CHAR is already more than the buffer can hold. Thus cin won't even need to look past MAX_PASSWORD_LENGTH + 1.

---

What buffer?

tabstop, that is incredibly obnoxious. Is that really the lengths that you need to go to so that you can accept input safely from the console? Every single time input is required? No wonder there are so many buffer overflows in C/C++ code, if it's that hard just to do something like accept input safely. There really needs to be a smart function that handles that for the programmer.

adminPassword...

It is not that big of a deal, maxhavoc. If you are using cin.get() like tabstop has up there you are simply using MAX_PASSWORD_LENGTH instead of your magic number. And how else would you have someone know when to stop reading?

Quote:

---

Originally Posted by maxhavoc

tabstop, that is incredibly obnoxious. Is that really the lengths that you need to go to so that you can accept input safely from the console? Every single time input is required? No wonder there are so many buffer overflows in C/C++ code, if it's that hard just to do something like accept input safely. There really needs to be a smart function that handles that for the programmer.

---

The non-obnoxious way is

Code:

---

std::string bob;
getline(std::cin, bob);

---

As I also mentioned before, you can also use the std::getline() function in conjunction with std::string. Which would entirely circumvent the parts which you seem to have the hardest time grasping: the idea of a fixed size buffer.

Quote:

---

Originally Posted by master5001

adminPassword...

---

Well, but the whole point of ignore is that the only place I know the input isn't going is adminPassword.

Quote:

---

Originally Posted by tabstop

The non-obnoxious way is

Code:

---

std::string bob;
getline(std::cin, bob);

---

---

Thank you :) Its nice to have someone second that opinion.

Quote:

---

Originally Posted by tabstop

Well, but the whole point of ignore is that the only place I know the input isn't going is adminPassword.

---

Oh ok, gotcha. I see now.

Quote:

---

Originally Posted by master5001

Thank you :) Its nice to have someone second that opinion.

---

What would that do with the excess input in std::cin? Just silently discard it?

Yep.

You are free to look at this.

Quote:

---

Originally Posted by maxhavoc

What would that do with the excess input in std::cin? Just silently discard it?

---

Well, there wouldn't be any excess input. A string can be whatever number of characters it needs to be; why stop at 16?

And of course, if you need to interface with char *-expecting functions, there is the .c_str() member function of a string.

I don't normally tell people to do this, but the only reason I make an exception today is because this is the 36th post on this thread. And at this point you are just now starting to take the very first suggestion you were given all the way back in post #2 on this thread; feel free to kick yourself.

Quote:

---

Originally Posted by maxhavoc

master5001, the problem with that approach is that allows ONLY 16 characters, not up to and including 16 characters.

---

:rolleyes: This may be another option for you. I'm not gonna bother explaining too much, since this is really simple code.

If you have specific needs then roll your own. The standard IO functions are building blocks, not your personal toolbox of goodies.

Code:

---

#include <iostream>
#include <ostream>
#include <cstring>

using std::cout;
using std::cin;
using std::endl;

int main ()
{
    const std::streamsize MAX = 17;
    char buffer[MAX];

    const std::streamsize oldw = cin.width();
    cin.width( MAX );
    cout << "Enter 16-character phrase: ";
    cin >> buffer;
    if ( cin.peek() != '\n' || std::strlen( buffer ) < MAX - 1 ) {
        cin.ignore( (unsigned)-1 ); //ignore any extraneous stuff
        cout << "Invalid phrase, try again\n";
    }
    else {
        cin.ignore(); //ignore newline
        cout << "You entered \"" << buffer << "\"" << endl;
    }
    cin.width( oldw );
    //copy buffer, do whatever
}

---

Quote:

---

Originally Posted by tabstop

Well, there wouldn't be any excess input. A string can be whatever number of characters it needs to be; why stop at 16?

And of course, if you need to interface with char *-expecting functions, there is the .c_str() member function of a string.

---

Is there a way to limit the number of characters getline accepts? I know that std::string simply grows as large as it needs, but this could lead to denial of service attack through resource exhaustion if there is no way to limit. Also, is there a way to get the count of elements actually read?

Quote:

---

Originally Posted by maxhavoc

Is there a way to limit the number of characters getline accepts? I know that std::string simply grows as large as it needs, but this could lead to denial of service attack through resource exhaustion if there is no way to limit. Also, is there a way to get the count of elements actually read?

---

gcount still exists.

Quote:

---

Originally Posted by tabstop

gcount still exists.

---

String does not have a gcount function. When I try to use std::cin.gcount it returns -1.

Quote:

---

Originally Posted by maxhavoc

String does not have a gcount function. When I try to use std::cin.gcount it returns -1.

---

In that case, use the .size() member function of the string.

Quote:

---

Originally Posted by tabstop

In that case, use the .size() member function of the string.

---

Ok, that will work so long as I can restrict the number of characters read in from std::cin during the getline() call. Do you know how I can do that?

Quote:

---

Originally Posted by maxhavoc

Ok, that will work so long as I can restrict the number of characters read in from std::cin during the getline() call. Do you know how I can do that?

---

All I know is that you can't. (TBH, I don't see worrying about a DOS as useful here, since if they can throw 4G characters at your C++ program, they can throw 4G characters at your C program just as well with the same result; you're going to run into the maximum length of stdin well before that anyway, I should think.)

Okay, thanks for the help everyone. I think the lesson I'm taking home from this is don't program in C++ anymore if I ever want to have secure console input.

Did I miss something important? Why was my snippet insufficient to your needs?

I'm not sure what exactly you missed, 'cause I missed it too.

I don't see how C++ is more vulnerable to a "type a bunch of characters" attach than, say, C. A std::string is guaranteed (I believe, I'll double check with the standard later maybe) to be able to hold whatever the size of the stdin buffer is. And processing 16 + 1000000 (the C-fixed buffer way) is no better or worse than processing 1000000 in one shot. And of course you can't overwrite any memory the C++ way, as far as I can tell.

Citizen, there is really nothing wrong with your solution except my admittedly rather arbitrary desire not to need so many lines of code every time I want input from the console. My application needs to accept input in about a dozen different places.

Tabstop, the problem with std::string is that I cannot restrict the amount of input I receive. I need a fixed upper bound. You are right in that memory is not overwritten; however, I am left to deal with arbitrary length input which is not what I want.

Quote:

---

Originally Posted by maxhavoc

Citizen, there is really nothing wrong with your solution except my admittedly rather arbitrary desire not to need so many lines of code every time I want input from the console. My application needs to accept input in about a dozen different places.

---

That's what, uh, functions are for.

Quote:

---

Originally Posted by maxhavoc

Tabstop, the problem with std::string is that I cannot restrict the amount of input I receive. I need a fixed upper bound. You are right in that memory is not overwritten; however, I am left to deal with arbitrary length input which is not what I want.

---

If you are going to discard extra input either way, then one solution is to take the substring of the string read with the precise upper bound that you need.

You can restrict the maximum string input length using the setw() modifier. For the >> operator, that is. The inability to limit the input size for std::getline() is a serious shortcoming.

Quote:

---

Originally Posted by maxhavoc

cin.ignore() asks for a number of characters to ignore. Is it safe to pass a huge number like INT_MAX to it?

---

I believe that if you pass no parameters to std::istream::ignore(), it uses the default parameters of 1, and EOF respectively, and somehow this has the effect of ignoring all remaining data.

No, the argument 1 means exactly what it says.

It's safe to pass a huge number to ignore().

Which is why I offered up (unsigned)-1. That is sufficiently large. If its worth anything to max, most consoles have a physical input limitation to begin with. So the chances of someone trying to DoS attack your "Hello world" app could be thwarted by bash or cmd or whatever your command shell is not physically taking in more than .25k or w/e of user input.