views:

636

answers:

9

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 does not run for them in Unix. Unix is alien for 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 aloof from something.

+1  A: 

There should be no difference between the C programming language under windows or *nix,cause the language is specified by the ISO standard.

Jichao
+2  A: 

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.

qrdl
+9  A: 

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.

anon
A: 

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.

Bastien Léonard
+1  A: 

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.

John Knoeller
+1  A: 

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.

Will
+13  A: 
Matteo Italia
+1 for CygWin and gcc/g++ on Windows. They will allow you to write standard c which will compile on just about any *nix and Mac osX. IMO that is the way to go.
Nick
The problem with them is that CygWin needs its runtime, and after all it's a UNIX compatibility layer, so I wouldn't recommend it for native projects. MinGW, on the other side, outputs native, "normal" Windows EXEs. However, at least when I tried it, it seemed to optimize worse than VC++ and than gcc/g++ on Linux, and it can't use the "normal" Platform SDK from Microsoft, and I don't like this too much. So, I use VC++ on Windows and g++/gcc on Linux; it's also useful to compile your application with two different compilers, you catch immediately the problems I described above.
Matteo Italia
Actually, cygwin allows you to produce executables without needing a cygwin library, so that comment isn't really terribly valid. (From memory, it's the -mingw, -msys or -mno-cygwin or some other option along those lines). You are correct, however, that gcc doesn't neccessarily produce as optimal results as other compilers - gcc, however, heavily ported to many architectures and platforms, which is a substantial advantage.
Arafangion
I didn't research about that, but I think that that option simply statically link the needed part of the cygwin compatibility layer into the executable. This, in my opinion, isn't the best option to do "real" native development on windows, but it should be used when you need a full POSIX compatibility layer.
Matteo Italia
+4  A: 

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.

ConcernedOfTunbridgeWells
+2  A: 

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

S.Tayefeh