I'm running Codeblocks on Windows platform. When studying about POSIX superset standard in C I came across some incompatibilities. I do understand that POSIX standard is designed to work on unix like systems whereas on windows I should search for the equivalents.
The problem I encounter is that for example (from wikipedia)
In the C and C++ programming languages, unistd.h is the name of the header file that provides access to the POSIX operating system API. It is defined by the POSIX.1 standard, the base of the Single Unix Specification, and should therefore be available in any POSIX-compliant operating system and compile
But when I include unistd.h in my IDE, I get no errors. Of course, I miss some of the defines but surprisingly for me it works. I was expecting an error when including the library. For example, on ubuntu running the same IDE with the same compiler I got error when including Windows.h header which makes sense. Why doesn't it works both ways?
Also, why do I have on windows access to functions for unix like systems (found in POSIX standard)?
Is there any conversions my compiler does? It automatically converts POSIX standard to windows compatible?
Mingw (the default Codeblocks compiler) provides some of those headers inside the include directory of the installation. It has some manner of POSIX support, but I don't think it is 100% compliant. If you want to be certain to run *nix/POSIX compliant libraries under Windows, you should probably use Cygwin instead.
Related
I usually use VS but trying cygwin for the first time. I am using windows 7 but on compiling hello world program using gcc, it says "fatal error: conio.h: no such file or directory".
I am using Windows 7 and it seems conio.h is missing from my system. Can someone please tell me how to resolve this issue.
Thanks!!
In Cygwin there doesn't exist any such header file called conio.h! Also, you don't need it either because it automatically holds screen for you without using getch() and for clrscr() you do have system("clear") in Cygwin!
conio not being part of the standard library, you cannot expect it to be available cross-platform, or even between compilers on the same platform.
Being, non-standard, the name conio has been used by both Borland and Microsoft for libraries with differing APIs - Microsoft's is much smaller. So for that reason you might avoid it for portability.
It is not a matter of conio not being on Windows, Cygwin is a POSIX API layer and tool-chain for building and running POSIX code on Windows. The libraries provided with it are independent of those provided with Visual Studio.
There are a number of solutions including:
Use an alternative console I/O library, such as ncurses.
Use a conio source code implementation for Linux such as this (which uses ncurses and implements Borland's API).
The second solution is perhaps useful if you have a lot of legacy code using conio, but is overkill if you just want to prevent a console windows from closing. For that you could just use getchar() in any case and accept that you will have to press enter rather than any key.
If you are using Cygwin just to be able to use GCC on Windows, you might be better off using MinGW/GCC instead. This uses Microsoft's C runtime rather than GNU, and the Win32 API rather than POSIX.
Is there some clear-cut distinction between standard C *.h header files that are provided by the C compiler, as oppossed to those which are provided by a standard C library? Is there some list, or some standard locations?
Motivation: int this answer I got a while ago, regarding a missing unistd.h in the latest TinyC compiler, the author argued that unistd.h (contrarily to sys/unistd.h) should not be provided by the compiler but by your C library.
I could not make much sense of that response (for one thing shouldn't that also apply to, say, stdio.h?) but I'm still wondering about it. Is that correct? Where is some authoritative reference for this?
Looking in other compilers, I see that other "self contained" POSIX C compilers that are hosted in Windows (like the GCC toolchain that comes with MinGW, in several incarnations; or Digital Mars compiler), include all header files.
And in a standard Linux distribution (say, Centos 5.10) I see that the gcc package provides a few header files (eg, stdbool.h, syslimits.h) in /usr/lib/gcc/i386-redhat-linux/4.1.1/include/, and the glibc-headers package provides the majority of the headers in /usr/include/ (including stdio.h, /usr/include/unistd.h and /usr/include/sys/unistd.h).
So, in neither case I see support for the above claim.
No, there is no clear-cut distinction.
As far as the C standard is concerned (here's a recent draft), the compiler and the library together make up the implementation, distinguished mostly by being described in sections 6 and 7 of the standard, respectively.
For some implementations, the compiler and the runtime library are provided by the same vendor/organization/person, either as a single installable package or as two separate packages. For other implementations (including gcc), the bulk of the standard library is provided by the underlying operating system, but the installation package for the compiler includes a few of its own headers.
Another example: When you install gcc from source on Solaris, the installer runs a script that grabs copies of some of the existing header files (provided by Sun's Oracle's runtime library) and edits them, installing the modified copies in a separate directory.
On GNU/Linux systems, the default C compiler is usually gcc, and the runtime library is provided by glibc -- both GNU packages, but developed separately. The MinGW implementation under Windows uses the gcc compiler with Microsoft's runtime library (which leads to some problems because they disagree on the representation of long double).
The choice of which standard headers need to be provided by the compiler is made by the authors of the compiler. Headers whose implementation is tightly tied to a particular compiler (such as <stdint.h>, <limits.h>, and <float.h>) are typically provided by the compiler; headers that provide an interface to operating system services, like <stdio.h> and <stdlib.h> are typically provided by the runtime library or perhaps by the OS.
The C standard provides no direct guidance regarding how this choice should be made.
Except for embedded (free-standing) C implementations, it makes little sense to separate C into compiler and libraries. Neither a compiler without libraries, not a C library without a compiler make much sense. Only a compiler together with a library makes up a complete implementation.
Since C89, the standard library is part of the C standard, and the list of required header files is listed in the standard. Other sets of libraries are standardized by Posix, X/Open ...
See this answer for a list: List of standard header files in C and C++
There are some headers that are by nature closer to the compiler itself, e.g. limits.h, which specifies the size of the data types. Some headers are closer to the OS, i.e. unistd.h. In both cases however, there are intersections, and if the OS' idea of, say, size_t and the compiler's implementation do not agree, nothing will work.
One could also argue that unistd.h should be provided by the OS and not by the C library - after all, the knowledge how to call a kernel function belongs into the OS.
In summary, I think this distinction into compiler, C library, operating system makes little sense.
Hello I'm looking into C Programming.
I'm wondering if there are differences between Linux and OSX in C? I know there are some between Windows and Linux/Unix (like getting a system timestamp). Are there any specific commands or techniques which won't work one of the two? Should "basic" programs run on both?
I'm aware that C isn't a cross compiling language but OSX and Linux are both Unix - aren't they?
What changes is not the language itself, but the libraries (and related API calls). There is no difference between Mac OSX and Linux under this aspect, as long as you stick with standard POSIX calls. Both Linux and Mac OSX are POSIX-compliant systems.
Of course, when talking about proprietary Apple libraries, you can't expect to find them under Linux. But this is another problem. Same for Linux internals.
Note that we are talking about source compatibility, not binary compatibility. You won't have to modify your source code at all, but you will have to compile it for each platform separately.
Linux includes quite a few extensions over the basic POSIX standard that both Linux and Darwin follow (Linux is "standard" in that it is exactly like Linux). As Stefano notes, in many cases this is fine, but if you have a program that was written for Linux without concern for portability ("runs on both Ubuntu and SuSE" is not "portability"), you should expect to see some different behaviors and missing extensions. For instance, mremap() and pipe2() are Linux-specific functions. SOCK_NONBLOCK is a Linux-specific flag to socket(), etc. The man pages will typically indicate when something is Linux-specific in the "Conforming To" section.
Ok here's the thing.
Most people learn about the C standard library simultaneously as they first get in contact with the C language and I wasn't an exception either. But as I am studying linux now, I tend to get confused with C libraries. well first, I know that you get a nice old C standard lib as you install gcc on your linux distro as a static lib. After that, you get a new stable version of glibc pretty soon as you connect to the internet.
I started to look into glibc API and here's where I got messed up. glibc seems to support vast amount of lib basically starting from POSIX C Standard lib (which implements the standard C lib(including C99 as I know of)) to it's own extensions based on the POSIX standard C lib.
Does this mean that glibc actually modified or added functions in the POSIX C Standard lib? or even add whole new header set? Cause I see some functions that are not in the standard C lib but actually included in the standard C header (such as strnlen() in
Also referring to what I mentioned about a 'glibc making whole new header set', is because I'm starting to see some header files that seems pretty unique such as linux/blahblah.h or sys/syscalls.h <= (are these the libs that only glibc support?)
Next Ques is that I actually heard linux is built based on C language. Does this mean linux compiles itself with it's own gcc compiler???????
For the first question, glibc follows both standard C and POSIX, from About glibc
The GNU C Library is primarily designed to be a portable and high performance C library. It follows all relevant standards including ISO C11 and POSIX.1-2008. It is also internationalized and has one of the most complete internationalization interfaces known.
For the second question, yes, you can compile Linux using gcc. Even gcc itself can be compiled using gcc, it's called bootstrapping.
Glibc implements the POSIX, ANSI and ISO C standards, and adds its own 'fluff', which it calls "glibc extensions". The reason that they are all "mixed together" is because they wrote the library as one package, there is no separate POSIX-only glibc.
<linux/blah> is not part of glibc. It is a set headers written specifically for the operating system, by people outside of glibc, to give the programmer access to the Linux kernel API. It is "part" of the Linux kernel and is installed with it, and is used for kernel hacking. <sys/blah> is part of glibc, and is specific to Linux. It gives access to a fairly abstracted Linux system API.
As for your second question, yes. Linux is written in C, as it is (according to Linus) the only programming language for kernel and system programming. The way this is done is through a technique called bootstrapping, where a small compiler is built (usually manually in ASM) and builds the entire kernel or the entirety of GCC.
There is one more thing to be aware of: one of the purposes of the libc is to abstract from the actual system kernel. As such, the libc is the one part of your app that is kernel specific. If you had a different kernel with different syscalls, you would need to have a specially compiled libc. AFAIK, the libc is therefore usually linked as a shared library.
On linux, we usually have the glibc installed, because linux systems usually are GNU/Linux systems with a GNU toolchain on top of the linux kernel.
And yes, the glibc does expand the standards in certain spots: The asprintf() function for instance originated as a gnu-addition. It almost made it into the C11 standard subsequently, but until it becomes part of them, it's use will require a glibc-based system, or statically linking with the glibc.
By default, the glibc headers do not define these gnu additions. You can switch them on by defining the preprocessor macro GNU_SOURCE before including the appropriate headers, or by specifying -std=gnu11 to the gcc call.
I am writing a C program with POSIX API and using Linux.
I compiled and ran it on a friend's Mac OSX PC and there was a small error, but I did not use Linux specific features.
I will use some specific features that Linux adds to the API. I will also use specific POSIX extensions for Mac Os X and FreeBSD.
I will use conditional compilation to choose the code. If the OS is none of those, I will use generic POSIX code.
I do not own Darwin/Mac OSX and FreeBSD, Linux is the only OS that I have in my PC. I cannot download and install FreeBSD, because it is more than 500 MB.
I want to know a way to test if the program will compile and behave as expected on other POSIX systems.
I wonder if there is a POSIX simulator and compiler to do tests.
The tests are simple, they do not use GUI and drivers, they are only command line.
I will need to do 3 tests: FreeBSD, Mac OSX/Darwin and Generic POSIX, but I do not have the tools.
EDIT
Is there a minimal version of FreeBSD and Darwin without GUI, but with GCC/G++ and ssh/scp? Darwin is free, is not it?
My PC is old, but I think I can install them in a virtual machine, create a virtual network and use ssh/scp to transfer and test the programs.
One simple way is to compile your program with the proper feature test macros. For example if you define _POSIX_C_SOURCE to the target version of POSIX (currently 200809L), you will request the system headers expose to your program nothing except what's needed/allowed by POSIX base. This can be done via the command line CFLAGS with -D_POSIX_C_SOURCE=200809L. If you want the XSI option (full Single Unix Standard functionality, which is a superset of POSIX base) then use -D_XOPEN_SOURCE=700 instead.
This will not help you detect problems that come from either certain systems lacking POSIX functionality (for example, OSX is broken and lacks a working sem_init last I checked, even though it's mandatory in POSIX), or from writing code that depends on non-standard behavior in the POSIX-standard interfaces (for example, using GNU regex extensions in the expressions you pass to regcomp) but it will help you catch any accidental usage of interfaces not in the standard.
If you want to compile for other system, you usually don't need to have the other system, you just need an appropriate cross compiler.