Playing with nodefaultlib, so far without success - either Pelles C complains that __fltused is not defined, or, when I define it, polink says it's redefined. Any ideas?
#include <stdio.h>
#pragma nodefaultlib
#pragma comment(linker, "/entry:main")
// POLINK: error: Unresolved external symbol '__fltused'
// if activated: redefinition of symbol...
int _fltused;
int xy(double i, double j) { return i*j; }
int main(int argc, char* argv[]) {
return xy(100.0, 12.3);
}
Hello jj
how you solved for ftol missing?
If you added a lib for that it will load other libraries and __fltused will be already defined.
[EDIT] I made some tests and the problem is the conversion from float to int that uses __ftol, you cannot get rid of it in 32bits, on the other hand for 64bits there is absolutely no problem because the conversion is made using xmm registers...
Quote from: frankie on June 07, 2015, 02:57:36 PM
Hello jj
how you solved for ftol missing?
Well, I didn't solve it. Apparently, the only workaround is to include crt.lib:
#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?");
}The good news:
- the executable is 2048 bytes only, so the /nodefaultlib shows effect;
- it compiles also with Visual Studio, if you use
msvcrt.lib
The bad news: In contrast to VS, Pelles C forgets to translate the escape sequences.
The function WriteFile() doesn't make the translation of '\n' to '\r\n'.
What I don't understand is why VS make it anyway ;D
Quote from: frankie on June 07, 2015, 05:43:22 PM
The function WriteFile() doesn't make the translation of '\n' to '\r\n'.
What I don't understand is why VS make it anyway ;D
wsprintf, not WriteFile, is supposed to expand the escape sequences. VS does it, GCC does it, too, and these are the only ones I could test because TCC chokes with a stupid error.
Quote from: jj2007 on June 07, 2015, 07:33:18 PM
wsprintf, not WriteFile, is supposed to expand the escape sequences. VS does it, GCC does it, too, and these are the only ones I could test because TCC chokes with a stupid error.
Ooops I haven't noticed it before WriteFile... :o