09-14-2022, 06:52 PM
(This post was last modified: 09-14-2022, 06:56 PM by mnrvovrfc.
Edit Reason: Looked at the screenshot in above post
)
Using "scanf()" could be a pain. However cannot use "gets()" in its place because it doesn't check for the target buffer size, and using string-to-number conversions like "atol()" are clunky. Could use "fgets()" instead for string input from "stdin". Another thing is that "scanf()" or alike function doesn't prevent the user from typing a non-numeral, or a plus or minus sign or multiple decimal points out of place. That's why all the checking in "qbs_input()" within "libqb.cpp" is needed. The CRT, for "scanf()" is hardwired to stop at a certain number of characters depending on the format which is "%ld" or alike. I don't know that much about C/C++ programming but I did enough to tell you that I had to avoid using "scanf()" although I was compelled to use "fscanf()" for input files and "sscanf()" for a few other things.
I looked at the screenshot. "scanf()" only picks up as many characters as it thinks should fit into the type asked for by the "format" first parameter it's given, that's why it displayed strange values in the first and second attempts. If it's going to convert improperly like that, it's not going to matter if it could accept 10 digits or 100 digits.
I looked at the screenshot. "scanf()" only picks up as many characters as it thinks should fit into the type asked for by the "format" first parameter it's given, that's why it displayed strange values in the first and second attempts. If it's going to convert improperly like that, it's not going to matter if it could accept 10 digits or 100 digits.