I have a problem using Eclipse and CDT, the problem started with a beginners code using printf() to ask for input and scanf() to store the input, but the console will not display the printf() arguments until after it has been given the scanf() arguments.
I found many threads linked to this problem and understand it is a bug in eclipe and that the buffers are not being flushed properly even when using \n .
The solution seems to be either use fflush(stdout) after each printf() or to add setbuf(stdout, NULL, _IONBF, 0) at the beginning of the main() function.
I added the setvbuf(stdout, NULL, _IONBF, 0) i also tried fflush(stdout) but eclipse is saying stdout can not be resolved.
Can anyone please tell say why and how to fix this.
Thank you.
Mick Caulton
This Is My code :
#include <stdio.h>
int main(){
//setvbuf(stdout, NULL, _IONBF, 0);
char letter;
int num1,num2;
printf("Enter any one keyboard character:\n");
// fflush(stdout);
scanf("%c",&letter);
printf("Enter 2 integers separated by a space: \n");
//fflush(stdout);
scanf("%d %d",&num1,&num2);
printf("Numbers input: %d and %d\n",num1,num2);
printf("Letter input: %c",letter);
printf(" stored at %p \n",&letter);
return 0;
}
If you're developing on Windows, keep in mind that the End-Of-Line indicator is \r\n (you're using just \n), and the Eclipse console window famously only does whole lines.
Related
Using Autokey 95.8, Python 3 version in Linux Mint 19.3 and I have a series of keyboard macros which generate Unicode characters. This example works:
# alt+shift+a = á
import sys
char = "\u00E1"
keyboard.send_keys(char)
sys.exit()
But the attempt to print an mdash [—] generates the following error:
SyntaxError:(unicode error) 'unicodeescape' codec' can't decode bytes in position 0-5: truncated \UXXXXXXXX escape
# alt+shift+- = —
import sys
char = "\u2014"
keyboard.send_keys(char)
sys.exit()
Any idea how to overcome this problem in Autokey is greatly appreciated.
The code you posted above would not generated the error you ae getting - "truncated \UXXXXXXXX" needs an uppercase \U - and 8 hex-digits - if you try putting in the Python source char = "\U2014", you will get that error message (and probably it you got it when experimenting with the file in this way).
The sequence char = "\u2014" will create an mdash unicode character on the Python side - but that does not mean it is possible to send this as a Keyboard sybo via autokey to Windows. That is the point your program is likely failing (and since there is no programing error, you won't get a Python error message - it is just that it won't work - although Autokey might be nice and print out some apropriate error message in this case).
You'd have to look around on how to type an arbitrary unicode character on your S.O. config (on Linux mint it should be on the docs for "wayland" I guess), and send the character composign sequence to Autokey instead. If there is no such a sequence, then finding a way to copy the desired character to the window environment clipboard, and then send Autokey the "paste" sequence (usually ctrl + v - but depending on the app it could change. Terminal emulators use ctrl + shift + v, for example)
When you need to emit non-English US characters in AutoKey, you have two choices. The simplest is to put them into the clipboard with clipboard.fill_clipboard(your characters) and paste them into the window using keyboard.send_keys("<ctrl>+v"). This almost always works.
If you need to define a phrase with multibyte characters in it, select the Paste using Clipboard (Ctrl+V) option. (I'm trying to get that to be the default option in a future release.)
The other choice, that I'm still not quite sure of, is directly sending the Unicode escape sequence to the window, letting it convert that into the actual Unicode character. Something like keyboard.send_keys("\U2014"). Assigning that to a variable first, as in the question, creates the actual Unicode character which that API call can't handle correctly.
The problem being that the underlying code for keyboard.send_keys() wants to send keycodes that actually exist on your keyboard or that it can add to an unused key in your layout. Most of the time that doesn't work for anything multibyte.
I'm just trying to pick up D having come from C++. I'm sure it's something very basic, but I can't find any documentation to help me. I'm trying to print the character à, which is U+00E0. I am trying to assign this character to a variable and then use write() to output it to the console.
I'm told by this website that U+00E0 is encoded as 0xC3 0xA0 in UTF-8, 0x00E0 in UTF-16 and 0x000000E0 in UTF-32.
Note that for everything I've tried, I've tried replacing string with char[] and wstring with wchar[]. I've also tried with and without the w or d suffixes after wide strings.
These methods return the compiler error, "Invalid trailing code unit":
string str = "à";
wstring str = "à"w;
dstring str = "à"d;
These methods print a totally different character (Ò U+00D2):
string str = "\xE0";
string str = hexString!"E0";
And all these methods print what looks like ˧á (note á ≠ à!), which is UTF-16 0x2E7 0x00E1:
string str = "\xC3\xA0";
wstring str = "\u00E0"w;
dstring str = "\U000000E0"d;
Any ideas?
I confirmed it works on my Windows box, so gonna type this up as an answer now.
In the source code, if you copy/paste the characters directly, make sure your editor is saving it in utf8 encoding. The D compiler insists on it, so if it gives a compile error about a utf thing, that's probably why. I have never used c:b but an old answer on the web said edit->encodings... it is a setting somewhere in the editor regardless.
Or, you can replace the characters in your source code with \uxxxx in the strings. Do NOT use the hexstring thing, that is for binary bytes, but your example of "\u00E0" is good, and will work for any type of string (not just wstring like in your example).
Then, on the output side, it depends on your target because the program just outputs bytes, and it is up to the recipient program to interpret it correctly. Since you said you are on Windows, the key is to set the console code page to utf-8 so it knows what you are trying to do. Indeed, the same C function can be called from D too. Leading to this program:
import core.sys.windows.windows;
import std.stdio;
void main() {
SetConsoleOutputCP(65001);
writeln("Hi \u00E0");
}
printing it successfully. On older Windows versions, you might need to change your font to see the character too (as opposed to the generic box it shows because some fonts don't have all the characters), but on my Windows 10 box, it just worked with the default font.
BTW, technically the console code page a shared setting (after running the program and it exits, you can still hit properties on your console window and see the change reflected there) and you should perhaps set it back when your program exits. You could get that at startup with the get function ( https://learn.microsoft.com/en-us/windows/console/getconsoleoutputcp ), store it in a local var, and set it back on exit. You could auto ccp = GetConsoleOutputCP(); SetConsoleOutputCP(65005;) scope(exit) SetConsoleOutputCP(ccp); right at startup - the scope exit will run when the function exits, so doing it in main would be kinda convenient. Just add some error checking if you want.
The Microsoft docs don't say anything about setting it back, so it probably doesn't actually matter, but still I wanna mention it just in case. But also the knowledge that it is shared and persists can help in debugging - if it works after you comment it, it isn't because the code isn't necessary, it is just because it was set previously and not unset yet!
Note that running it from an IDE might not be exactly the same, because IDEs often pipe the output instead of running it right out to the Windows console. If that happens, lemme know and we can type up some stuff about that for future readers too. But you can also open your own copy of the console (run the program outside the IDE) and it should show correctly for you.
D source code needs to be encoded as UTF-8.
My guess is that you're putting a UTF-16 character into the UTF-8 source file.
E.g.
import std.stdio;
void main() {
writeln(cast(char)0xC3, cast(char)0xA0);
}
Will output as UTF-8 the character you seek.
Which you can then hard code like so:
import std.stdio;
void main() {
string str = "à";
writeln(str);
}
Im using Dev - C++, and developing some software for myself in my language, every string that i type can't have chars like 'é' or 'ã' and 'ç' don't show 'ç'. But in my native language they are all necessary characters to build words. What i need to do in this IDE or in the code to bring this chars to the screen? Any help, thanks.
When i do the Execute -> Compile & Run . of:
int main(int argc, char *argv[]) {
char *text = "é á ç â\n";
fprintf(stdout,text);
return 0;}
i get:
note: i intend to continue to do code in this IDE. i use others but this questions is for users of this IDE.
My code:
m_ListCtrlCandidates.InsertItem(i, _itoa_s(candidate[i].ID, (char*)(LPCTSTR)str, 10));
m_ListCtrlCandidates.SetItemText(i, 1, _itoa(candidate[i].FingerNumber, (char*)(LPCTSTR)str, 10));
m_ListCtrlCandidates.SetItemText(i, 2, _itoa(candidate[i].SampleNumber, (char*)(LPCTSTR)str, 10));
m_ListCtrlCandidates.SetItemText(i, 3, _itoa(candidate[i].ConfidenceLevel, (char*)(LPCTSTR)str, 10));
Error:
Error 2 error C4996: '_itoa': This function or variable may be unsafe. Consider using _itoa_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. d:\documents\visual studio 2013\projects\gatekeeper\gatekeeper\gatekeeperdlg.cpp 416 1 Gatekeeper
I'm using an SDK that has the following code in their sample. It adds potential matches to a list in the dialog. Initially I had my project set to unicode and updated the code to work. This was giving me trouble so I looked at the sample code and it's character set was blank. So I changed mine and now I get this error.
If I switch it to _itoa_s I get the error that the function doesn't take 3 arguments. So I guess I'm missing the size argument, but I'm not sure what size it is suppose to be. Also, it compiles fine in their sample code when left as _itoa.
I'd really like to keep it in Unicode. Using _wtoi instead of atoi helped in other places. Is there something similar for this case?
I'm using an SDK that has the following code in their sample.
That's unfortunate!
_itoa(candidate[i].FingerNumber, (char*)(LPCTSTR)str, 10)
I'm guessing that you're using MFC, str is a CString, and you're calling CListCtrl::SetItemText.
The (LPCTSTR) operator on CString gets the pointer to the underlying buffer holding the string data. That's a const TCHAR*, so if you're compiling in ANSI mode, this is a const char* pointer to bytes; in Unicode mode it's a const wchar_t* point to 16-bit code units.
Casting this to a non-const char* and asking _itoa to write to that is a pretty bad idea. This overwrites whatever was originally in the CString, and if the number is big enough that the resulting string is longer than what was originally in the CString you could be writing over the end of the array, causing memory corruption havoc.
Casting it to a char* in Unicode mode is even weirder as you're using a wchar_t array as storage for char* bytes. And SetItemText() in Unicode mode would be expecting to get wchar_t characters instead surely?
Using _wtoi instead of atoi helped in other places. Is there something similar
_itow exists as the wchar_t analogue of _itoa. (At least in VS. Neither function is standard C[++] as such.)
You can switch on #ifdef _UNICODE and call either _itoa or _itow to match whichever type TCHAR is. But unless you really need to support an ancient ANSI-only build for some legacy reason there's not much reason to bother with TCHAR switching these days. You can usually just stick to Unicode mode and use wchar_t-based strings for text.
error C4996: '_itoa': This function or variable may be unsafe.
Microsoft deprecated a number of C functions that write variable amounts of content to pre-allocated buffers, because the buffers can easily be too short, resulting in the aforementioned memory corruption horror. This has been a cause of countless security problems in applications in the past, so it's best avoided.
Unfortunately warning 4996 actually deprecates some standard functions that aren't really dangerous too, which is quite tiresome, especially as the _s versions suggested as a replacement are typically not supported by other compilers.
In this case though MS are kind of right, _itoa isn't really safe. To use it safely you'd have to allocate a buffer large enough for the longest possible integer of the type you're passing, and it's really easy to get that wrong.
If I switch it to _itoa_s I get the error that the function doesn't take 3 arguments. So I guess I'm missing the size argument, but I'm not sure what size it is suppose to be
It's however many elements are available at the end of the pointer to write to. So at present that would depend on the length of the CString whose buffer you're stealing. But it's not a good idea to do that. You could allocate your own buffer:
wchar_t str[8];
_itow_s(candidate[i].FingerNumber, str, 8, 10);
This is safe, though it still fails (with errno EINVAL) if FingerNumber has more than 7 digits as there would be no space to store them all (including the \0 terminator).
Functions like itoa that write variable content to buffers are pretty ugly in general. If you can use modern C++ with the STL, there are simpler, safer string-handling methods available, for example:
#include <string>
std::wstring fingers = std::to_wstring(candidate[i].FingerNumber);
m_ListCtrlCandidates.SetItemText(i, 1, fingers.c_str());
(although how well this will mix with old-school MFC and CString is another question.)
When reading a file, I understand the last character provided is an EOF. Now, what happens, when I have an EOF character in that file?
How do I distinguish between the "real" end of a file, and the EOF character?
I decided to move my comments to an answer.
You can't have an "EOF character" in your file because there is no such thing. The underlying filesystem knows how many bytes are in a file; it doesn't rely on the contents of the file to know where the end is.
The C functions you're using return EOF (-1) but that wasn't read from the file. It's just the way the function tells you that you're reached the end. And because -1 isn't a valid character in any character set, there's no confusion.
You need some context for this question. On Windows, there's the outdated DOS concept of a real "EOF character" -- Ctrl-Z. It is actually not possible to tell a "real" one from a "fake" one; a file with an embedded Ctrl-Z will contain some trailing hidden data from the perspective of a program which is actually looking for Ctrl-Z as an end of file character. Don't try to write this kind of code anymore -- it's not necessary.
In the portable C API and on UNIX, a 32-bit -1 is used to indicate end of file, which can't be a valid 8 or 16-bit character, so it's easy to tell the difference.
Assuming you're talking about C, EOF is -1, which is not a character (hence there is no confusion).