MSVCRT.LIB causes problems with stdin and stderr

[severach]

Code: [Select]

#include <stdio.h>

// File New Project Win32 Console Program
// List msvcrt.lib first on libs line and stdin and stderr won't work correctly
// Don't list msvcrt.lib and this program works though is much larger

int main(int argc,char *argv[]) {
  char name[1024];
  printf("Enter your name\n");
  fgets(name,sizeof(name)-1,stdin); // this won't accept any keys
  //gets(name); // security leak // this at least accepts keys
  printf("Hello ");
  fprintf(stderr,"%s\n",name); // this will not print anything
  return 0;
}

It works when compiled with MINGW which always compiles with MSVCRT.LIB.

[Vortex]

It's probably because the linker cannot access the streams stdin and stderr in  msvcrt.lib. If you replace some functions, you will get it to be linked against msvcrt.lib :

Code: [Select]

#include <stdio.h>

int main(int argc,char *argv[])
{
char name[1024];
printf("Enter your name :\n");
scanf("%s",name);
printf("Hello %s\n",name);
return 0;
}


The resulting executable has a final size of 2 KB

You can ignore the warning message below when you build the project :

Code: [Select]

POLINK: warning: Multiple '.rdata' sections found with different flags (0x40000040 and 0xc0000040).

[severach]

It's probably because the linker cannot access the streams stdin and stderr in  msvcrt.lib. If you replace some functions, you will get it to be linked against msvcrt.lib :

But scanf() and gets() are unsafe so are only appropriate for test code. stderr isn't replacable by anything. I'd prefer an init call or to copy over stdin, stdout, and stderr from somewhere else. The current option is to debug with Pelles-C and release with MinGW.

[Vortex]

scanf() and gets() are frequently used functions. I don't see anything unsafe there...

[frankie]

The problem is that the "FILE" structure used in PellesC is completely different from that used by M$,
To use the msvcrt.lib you have to use also the M$ header files.
I compiled your example including the M$ stdio.h renamed to MS-stdio.h and omitting default libraries (option from project options-> compiler), and it works (pocrt.lib is no more inserted in the linker flow).
See the attached example.

[kalikiana]

So are there any disadvantages from using msvcrt.dll?

[frankie]

It's just a matter of taste! :mrgreen:
 If you like to use M$ functions and libraries you have to use the correct definitions.

[kalikiana]

It's just a matter of taste! :mrgreen:
 If you like to use M$ functions and libraries you have to use the correct definitions.

I would not say I was a fan of the MS library. Actually the only background is to reduce the exe size. And unlike Pelles' the MS library is installed in most Win32 environments.

[frankie]

The difference between the a program linked against a static library and the same program with the DLL (Pelles or M$ doesn't matter)  should be roughly 20kB.
In my opinion is not a big deal, also the download doesn't suffer very much (on a very slow connection it will require 10 more seconds?).
In the case you need a very small executable you can use different libraries, like the libctiny (or the like) that you can find also on the Vortex web page, or you can use an exe compressor, or write the program in assembler or C without any library at all (set the "omit default libraries" in compiler tab and set the entry point in the linker tab to go directly in you code). In the last case keep in account that many standard functions doesn't work because there is no initialization.
So you can choose whichever solution you like more, a matter of taste or of requirements indeed.  :mrgreen:

[kalikiana]

Ideally I would like to reduce the library code as much as possible while standard functions are still accessible. And because of portability I am looking for a method not to change the source files.
I already tried the tiny lib but it only worked for really small test files. It somehow didn't work with 'real' code. Might give it another try if I have some time.
I thought using the MS runtime may be worth a try. Sadly including a proprietary header file is not what I like.