C程序在Windows和Unix OS上跨平台差异

Question

Is there any difference in C that is written in Windows and Unix?
I teach C as well as C++ but some of my students have come back saying some of the sample programs do not run for them in Unix. Unix is alien to me. Unfortunately no experience with it whatsoever. All I know is to spell it. If there are any differences then I should be advising our department to invest on systems for Unix as currently there are no Unix systems in our lab. I do not want my students to feel that they have been denied or kept away from something.

Answer 1

That kind of problems usually appear when you don't stick to the bare C standard, and make assumptions about the environment that may not be true. These may include reliance on:

• nonstandard, platform specific includes ( <conio.h> , <windows.h> , <unistd.h> , ...);
• undefined behavior ( fflush(stdin) , as someone else reported, is not required to do anything by the standard - it's actually undefined behavior to invoke fflush on anything but output streams; in general, older compilers were more lenient about violation of some subtle rules such as strict aliasing, so be careful with "clever" pointer tricks);
• data type size (the short =16 bit, int = long =32 bit assumption doesn't hold everywhere - 64 bit Linux, for example, has 64 bit long );
• in particular, pointer size ( void * isn't always 32 bit, and can't be always casted safely to an unsigned long ); in general you should be careful with conversions and comparisons that involve pointers, and you should always use the provided types for that kind of tasks instead of "normal" int s (see in particular size_t , ptrdiff_t , uintptr_t )
• data type "inner format" (the standard does not say that float s and double s are in IEEE 754, although I've never seen platforms doing it differently);
• nonstandard functions ( __beginthread , MS safe strings functions; on the other side, POSIX/GNU extensions)
• compiler extensions ( __inline , __declspec , #pragma s, ...) and in general anything that begins with double underscore (or even with a single underscore, in old, nonstandard implementations);
• console escape codes (this usually is a problem when you try to run Unix code on Windows);
• carriage return format: in normal strings it's \\n everywhere, but when written on file it's \\n on *NIX, \\r\\n on Windows, \\r on pre-OSX Macs; the conversion is handled automagically by the file streams, so be careful to open files in binary when you actually want to write binary data , and leave them in text mode when you want to write text.

Anyhow an example of program that do not compile on *NIX would be helpful, we could give you preciser suggestions.

The details on the program am yet to get. The students were from our previous batch. Have asked for it. turbo C is what is being used currently.

As said in the comment, and (if you use it) Turbo C++, nowadays they are both pieces of history and have many incompatibilities with the current C and C++ standards (and if I remember well they both generate 16-bit executables, that won't even run on 64 bit OSes on x86_64).

There are a lot of free, working and standard-compliant alternatives (VC++ Express, MinGW, Pelles C, CygWin on Windows, and gcc/g++ is the de-facto standard on Linux, rivaled by clang), you just have to pick one.

Answer 2

The language is the same, but the libraries used to get anything platform-specific done are different. But if you are teaching C (and not systems programming) you should easily be able to write portable code. The fact that you are not doing so makes me wonder about the quality of your training materials.

Answer 3

The standard libraries that ship with MSVC and those that ship with a typical Linux or Unix compiler are different enough that you are likely to encounter compatibility issues. There may also be minor dialectic variations between MSVC and GCC.

The simplest way to test your examples in a unix-like environment would be to install Cygwin or MSYS on your existing Windows kit. These are based on GCC and common open-source libraries and will behave much more like the C compiler environment on a unix or linux system.

• Cygwin is the most 'unix like', and is based on a cygwin.dll , which is an emulation layer that emulates unix system calls on top of the native Win32 API. Generally anything that would compile on Cygwin is very likely to compile on Linux, as Cygwin is based on gcc and glibc. However, native Win32 APIs are not available to applications compiled on Cygwin.

• MSYS/MinGW32 is designed for producing native Win32 apps using GCC. However, most of the standard GNU and other OSS libraries are available, so it behaves more like a unix environment than VC does. In fact, if you are working with code that doesn't use Win32 or unix specific APIs it will probably port between MinGW32 and Linux more easily than it would between MinGW32 and MSVC.

While getting Linux installed in your lab is probably a useful thing to do (Use VMWare player or some other hypervisor if you can't get funding for new servers) you can use either of the above toolchains to get something that will probably be 'close enough' for your purposes. You can learn unix as takes your fancy, and both Cygwin and MSYS will give you a unix-like environment that could give you a bit of a gentle intro in the meantime.

Answer 4

C syntax must be the same if both Windows and Unix compilers adhere to the same C standard. I was told that MS compilers still don't support C99 in full, although Unix compilers are up to speed, so it seems C89 is a lowest common denominator.

However in Unix world you typically will use POSIX syscalls to do system stuff, like IPC etc. Windows isn't POSIX system so it has different API for it.

Answer 5

There is this thing called Ansi C . As long as you code purely Ansi C, there should be no difference. However, this is a rather academic assumption.

In real life, I have never encountered any of my codes being portable from Linux to Windows and vice versa without any modification. Actually, this modification S (definitely plural) turned out into a vast amout of pre-processor directives, such as #ifdef WINDOWS ... #endif and #ifdef UNIX ... #endif ... even more, if some parallel libs, such as OPENMPI were used.

As you may imagine, this is totally contrary to readable and debugable code, but that was what worked ;-)

Besides, you have got to consider things already mentioned: UTF-8 will sometimes knock out linux compilers...

Answer 6

在Windows或* nix下，C编程语言之间应该没有区别，因为语言是由ISO标准指定的。

Answer 7

The C language itself is the portable from Windows to Unix. But operating system details are different and sometimes those intrude into your code.

For instance Unix systems typically use only "\\n" to separate lines in a text file, while most Windows tools expect to see "\\r\\n". There are ways to deal with this sort of difference in a way that gets the C runtime to handle it for you but if you aren't careful you know about them, it's pretty easy to write OS specific C code.

I could that you run a Unix in a Virtual Machine and use that to test your code before you share it with your students.

Answer 8

I think its critical that you familiarize yourself with unix right now.

An excellent way to do this is a with a Knoppix CD.

Try to compile your programs under Linux using gc, and when they don't work, track down the problems (#include <windows>?) and make it work. Then return to windows, and it'll likely compile ok.

In this way, you will discover your programs become cleaner and better teaching material, even for lab exercises on windows machines.

Answer 9

A common problem is that fflush(stdin) doesn't work on Unix. Which is perfectly normal, since the standard doesn't define how the implementation should handle it. The solution is to use something like this (untested):

do
{
    int c = getchar();
}
while (c != '\n' && c != EOF);

Similarly, you need to avoid anything that causes undefined behavior.