Trouble with __fltused

[jj2007]

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?

Code: [Select]

#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);
 }

[frankie]

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...

[jj2007]

Hello jj
how you solved for ftol missing?

Well, I didn't solve it. Apparently, the only workaround is to include crt.lib:

Code: [Select]

#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.

[frankie]

The function WriteFile() doesn't make the translation of '\n' to '\r\n'.
What I don't understand is why VS make it anyway 

[jj2007]

The function WriteFile() doesn't make the translation of '\n' to '\r\n'.
What I don't understand is why VS make it anyway 

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.

[frankie]

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...