I am actually not sure if this qualifies as a bug: Pelles C does not translate \n etc in wsprintf to CrLf etc.
Both MS VC and GCC do translate them.
#include <stdio.h>
#include <Windows.h>
#pragma warn(disable:2118 2215 2216)
#pragma nodefaultlib
#pragma comment(linker, "/entry:main")
#pragma comment(lib, "crt.lib")
#define fprint(...) { \
int bWritten; \
char buffer[1024]; \
wsprintf(buffer, __VA_ARGS__); \
WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), buffer, lstrlen(buffer), &bWritten, NULL); \
}
int xy(double i, double j) { return i*j; }
int main(int argc, char* argv[]) {
fprint("x*y=%d \n\n\n", 12345);
fprint("x*y=%d \n\n\n", xy(100.0, 12.3));
fprint("... %s", "did you see a newline?");
}
Not a bug. wsprintf comes from user32.lib.
Quote from: TimoVJL on June 14, 2015, 01:56:08 PM
Not a bug. wsprintf comes from user32.lib.
Which doesn't change the observation that GCC and MSVC behave differently.
With PellesCx*y=12345
x*y=1230
... did you see a newline?With gccx*y=12345
x*y=1230
... did you see a newline?
Interesting. I still had version 7 installed (XP, you know...), but now I tried version 8 and voilà, the newlines show up ;D
EDIT: Oops, what happened? Now they show in both versions. I investigated, and the reason for not seeing newlines was that there were no ... guess what ... carriage returns in the output. And I had directed the output to a Windows edit control. When running the code from a DOS prompt, it does indeed show newlines. But when you redirect e.g. with mytest.exe >1.txt, and open the 1.txt in a hex editor, it becomes evident that \n translates to 0A (Ascii 10) only. Enough for the console, but not for the edit control, which needs the CrLf pair, i.e. \r\n:
fprint("x*y=%d \r\n\r\n", 12345);
fprint("x*y=%d \r\n\r\n", xy(100.0, 12.3));
fprint("... %s", "did you see a newline?");
And since GCC and MSVC do exactly the same, it's definitely not a Pelles C bug. Apologies 8)