I have a code that works just fine when compiled with the build tools v110. Recently I have upgraded the toolchain to v141 (vs 2k17) and some functions that made use of sscanf is not working anymore.
The sscanf calls that stopped working make use of this particular format string: "%s %[^\0]". It expects a stream string containing 1 string followed by a whitespace and another string which have to be put in a buffer for later treat. The first string is copied to the first buffer correctly but the second is not (sscanf returns 1 instead of 2).
Someone having this problem or have any idea of why it is happening?
A code sample to test the problem:
#include <stdio.h>
#include <tchar.h>
int main()
{
char str1[100], str2[100];
memset(str1, 0, sizeof(str1)); memset(str2, 0, sizeof(str2));
int i = sscanf("+nf foo", "%s %[^\0]", str1, str2);
return 0;
}
The sequence \0 encodes a zero byte (ASCII character NUL), which in C/C++ is a string terminator.
So your formatting string is effectively "%s %[^" with another one-char long string "]" possibly following it (possibly, because the compiler may notice the string termination and discard the unused tail).
Edit
As a string terminator, the NUL character actually can't appear in the input string (although it could appear e.g. in a file stream! I'm not sure, however, how that would be handled by fscanf()), so you need not look for it with the format specifier. If you just need to read both parts of an input string into two char arrays, just use "%s%s":
sscanf("+nf foo", "%s%s", str1, str2);
As stated by the user n.m. in the topic comments the string I was using ("%[^\0]") don't work because the char "\0" will be translated to a ASCII NUL ending the format string before the proper end of the specifier %[].
The correct string to use in this case (when you need to use the specifier %[] to read all the bytes instead of ASCII NUL) is "%[\1-\377]"
Related
char str[] = "C:\Windows\system32"
auto raw_string = convert_to_raw(str);
std::cout << raw_string;
Desired output:
C:\Windows\system32
Is it possible? I am not a big fan of cluttering my path strings with extra backslash. Nor do I like an explicit R"()" notation.
Any other work-around of reading a backslash in a string literally?
That's not possible, \ has special meaning inside a non-raw string literal, and raw string literals exist precisely to give you a chance to avoid having to escape stuff. Give up, what you need is R"(...)".
Indeed, when you write something like
char const * str{"a\nb"};
you can verify yourself that strlen(str) is 3, not 4, which means that once you compile that line, in the binary/object file there's only one single character, the newline character, corresponding to \n; there's no \ nor n anywere in it, so there's no way you can retrieve them.
As a personal taste, I find raw string literals great! You can even put real Enter in there. Often just for the price of 3 characters - R, (, and ) - in addtion to those you would write anyway. Well, you would have to write more characters to escape anything needs escaping.
Look at
std::string s{R"(Hello
world!
This
is
Me!)"};
That's 28 keystrokes from R to last " included, and you can see in a glimpse it's 6 lines.
The equivalent non-raw string
std::string s{"Hello\nworld!\nThis\nis\nMe!"};
is 30 keystrokes from R to last " included, and you have to parse it carefully to count the lines.
A pretty short string, and you already see the advantage.
To answer the question, as asked, no it is not possible.
As an example of the impossibility, assume we have a path specified as "C:\a\b";
Now, str is actually represented in memory (in your program when running) using a statically allocated array of five characters with values {'C', ':', '\007', '\010', '\000'} where '\xyz' represents an OCTAL representation (so '\010' is a char equal to numerically to 8 in decimal).
The problem is that there is more than one way to produce that array of five characters using a string literal.
char str[] = "C:\a\b";
char str1[] = "C:\007\010";
char str2[] = "C:\a\010";
char str3[] = "C:\007\b";
char str4[] = "C:\x07\x08"; // \xmn uses hex coding
In the above, str1, str2, str3, and str4 are all initialised using equivalent arrays of five char.
That means convert_to_raw("C:\a\b") could quite legitimately assume it is passed ANY of the strings above AND
std::cout << convert_to_raw("C:\a\b") << '\n';
could quite legitimately produce output of
C:\007\010
(or any one of a number of other strings).
The practical problem with this, if you are working with windows paths, is that c:\a\b, C:\007\010, C:\a\010, C:\007\b, and C:\x07\x08 are all valid filenames under windows - that (unless they are hard links or junctions) name DIFFERENT files.
In the end, if you want to have string literals in your code representing filenames or paths, then use \\ or a raw string literal when you need a single backslash. Alternatively, write your paths as string literals in your code using all forward slashes (e.g. "C:/a/b") since windows API functions accept those too.
i have a big problem and i dont know how to fix it...
I want to decode a very long Base64 encoded string (980.000 Chars) but every time when i to debug it i get this error :
Error C2026: string too big, trailing characters truntraced
I tried this but i can only compare 2 strings throught this method
char* toHash1 = "LONG BASE 64 Code";
char* toHash2 = "LONG BASE 64 Code";
if (true) {
sprintf_s(output, outputSize, "%s", base64_decode(toHash1 =+ toHash2).c_str());
}
Anyone know how i can get it to work?
As documented here, you can only have about 2048 characters in a string literal when using MSVC. You can get up to 65535 characters by concatenation, but since this is still too short, you cannot use string literals here.
One solution would be reading the string from a file into some allocated char buffer. I do not know of any such limits for gcc and clang, so trying to use them instead of MSVC could solve this too.
You can first convert your string to hex and then can include it like this,
char data[] = {0xde,0xad,0xbe,0xef}; //example
And than can use it like a string, append null terminator if needed to.
could you say me what is the mistake in my following code?
char* line="";
printf("Write the line.\n");
scanf("%s",line);
printf(line,"\n");
I'm trying to get a line as an input from the console.But everytime while using "scanf" the program crashes. I don't want to use any std, I totally want to avoid using cin or cout. I'm just trying to learn how to tak a full line as an input using scanf().
Thank you.
You need to allocate the space for the input string as sscanf() cannot do that itself:
char line[1024];
printf("Write the line.\n");
scanf("%s",line);
printf(line,"\n");
However this is dangerous as it's possible to overflow the buffer and is therefore a security concern. Use std::string instead:
std::string line;
std::cout << "Write the line." << std::endl;
std::cin >> line;
std::cout << line << std::endl;
or:
std::getline (std::cin, line);
Space not allocated for line You need to do something like
char *line = malloc();
or
Char line[SOME_VALUE];
Currently line is a poor pointer pointing at a string literal. And overwriting a string literal can result in undefined behaviour.
scanf() doesn't match lines.
%s matches a single word.
#include <stdio.h>
int main() {
char word[101];
scanf("%100s", word);
printf("word <%s>\n", word);
return 0;
}
input:
this is a test
output:
word <this>
to match the line use %100[^\n"] which means 100 char's that aren't newline.
#include <stdio.h>
int main() {
char word[101];
scanf("%100[^\n]", word);
printf("word <%s>\n", word);
return 0;
}
You are trying to change a string literal, which in C results in Undefined behavior, and in C++ is trying to write into a const memory.
To overcome it, you might want to allocate a char[] and assign it to line - or if it is C++ - use std::string and avoid a lot of pain.
You should allocate enough memory for line:
char line[100];
for example.
The %s conversion specifier in a scanf call expects its corresponding argument to point to a writable buffer of type char [N] where N is large enough to hold the input.
You've initialized line to point to the string literal "". There are two problems with this. First is that attempting to modify the contents of a string literal results in undefined behavior. The language definition doesn't specify how string literals are stored; it only specifies their lifetime and visibility, and some platforms stick them in a read-only memory segment while others put them in a writable data segment. Therefore, attempting to modify the contents of a string literal on one platform may crash outright due to an access violation, while the same thing on another platform may work fine. The language definition doesn't mandate what should happen when you try to modify a string literal; in fact, it explicitly leaves that behavior undefined, so that the compiler is free to handle the situation any way it wants to. In general, it's best to always assume that string literals are unwritable.
The other problem is that the array containing the string literal is only sized to hold 1 character, the 0 terminator. Remember that C-style strings are stored as simple arrays of char, and arrays don't automatically grow when you add more characters.
You will need to either declared line as an array of char or allocate the memory dynamically:
char line[MAX_INPUT_LEN];
or
char *line = malloc(INITIAL_INPUT_LEN);
The virtue of allocating the memory dynamically is that you can resize the buffer as necessary.
For safety's sake, you should specify the maximum number of characters to read; if your buffer is sized to hold 21 characters, then write your scanf call as
scanf("%20s", line);
If there are more characters in the input stream than what line can hold, scanf will write those extra characters to the memory following line, potentially clobbering something important. Buffer overflows are a common malware exploit and should be avoided.
Also, %s won't get you the full line; it'll read up to the next whitespace character, even with the field width specifier. You'll either need to use a different conversion specifier like %[^\n] or use fgets() instead.
The pointer line which is supposed to point to the start of the character array that will hold the string read is actually pointing to a string literal (empty string) whose contents are not modifiable. This leads to an undefined behaviour manifested as a crash in your case.
To fix this change the definition to:
char line[MAX]; // set suitable value for MAX
and read atmost MAX-1 number of characters into line.
Change:
char* line="";
to
char line[max_length_of_line_you_expect];
scanf is trying to write more characters than the reserved by line. Try reserving more characters than the line you expect, as been pointed out by the answers above.
I tried to do it like this
#include <iostream>
#include <fstream>
using namespace std;
int main()
{
char b[2];
ifstream f("prad.txt");
f>>b ;
cout <<b;
return 0;
}
It should read 2 characters but it reads whole line. This worked on another language but doesn't work in C++ for some reason.
You can use read() to specify the number of characters to read:
char b[3] = "";
ifstream f("prad.txt");
f.read(b, sizeof(b) - 1); // Read one less that sizeof(b) to ensure null
cout << b; // terminated for use with cout.
This worked on another language but doesn't work in C++ for some
reason.
Some things change from language to language. In particular, in this case you've run afoul of the fact that in C++ pointers and arrays are scarcely different. That array gets passed to operator>> as a pointer to char, which is interpreted as a string pointer, so it does what it does to char buffers (to wit read until the width limit or end of line, whichever comes first). Your program ought to be crashing when that happens, since you're overflowing your buffer.
istream& get (char* s, streamsize n );
Extracts characters from the stream and stores them as a c-string into
the array beginning at s. Characters are extracted until either (n -
1) characters have been extracted or the delimiting character '\n' is
found. The extraction also stops if the end of file is reached in the
input sequence or if an error occurs during the input operation. If
the delimiting character is found, it is not extracted from the input
sequence and remains as the next character to be extracted. Use
getline if you want this character to be extracted (and discarded).
The ending null character that signals the end of a c-string is
automatically appended at the end of the content stored in s.
The solution is probably obvious, but I do not see it. I have this simple C++ code:
// Build the search pattern
// sPath is passed in as a parameter into this function
trim_right_if(sPath, is_any_of(L"\\"));
wstring sSearchPattern = sPath + L"\\*.*";
My problem is that the + operator has no effect (checked in debugger). The string sSearchPattern is initialized to the value of sPath only.
Notes: sPath is a wstring.
Example of what I want to achieve:
sSearchPattern -> C:\SomePath\*.*
More Info:
When I look at sPath in the debugger, I see two NULL characters after the last character. When I look at sSearchPattern, the "\*.*" is appended, but after the two NULL characters. Any explanation for that?
This should work, and indeed works for me on VS2010, SP1:
#include <iostream>
#include <string>
int main()
{
const std::wstring sPath = L"C:\\SomePath";
const std::wstring sSearchPattern = sPath + L"\\*.*";
std::wcout << sSearchPattern << L'\n';
return 0;
}
This prints
C:\SomePath\*.*
for me.
As I found out the two NULL characters stored at the end of the string were the problem. Apparently std::wstring does not care about NULLs like good old C string does. If it thinks a string is 10 characters long, it does not care if some of those 10 characters are NULL characters. If you then append to that string, the additional characters get appended after the 10ths char. If the last characters of the string happen to be NULLs, you get:
C:\\SomePath\0\0\\*.*
Such a string cannot really be used anywhere.
How did I get the NULL characters at the end of the original string? I used wstring.resize() in some other function which pads the string with NULLs. I did this in order to pass &string[0] to a Windows API function expecting a LPWSTR.
Now that I know this does not work I use a true LPWSTR instead. That is a bit more clumsy, but it works. Coming from MFC, I thought I could use std::wstring like CString with its GetBuffer and Release methods.
Something in your real code is adding extra null characters to the end of the string. Your bug lies in that code.
String concatenation works perfectly well. std::wstring is not null terminated and so concatenation just adds on to the end of the buffer. This makes std::wstring somewhat different from a C string because it can hold null characters. I suspect this nuance is the source of all the confusion.