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” ints (see in particular size_t, ptrdiff_t, uintptr_t)
• data type “inner format” (the standard does not say that floats and doubles 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, #pragmas, …) 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, please drop Turbo C 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.