Comparing ANSI C, ISO C, and POSIX

[RedX]

What is the difference between ANSI C, ISO C, and POSIX?

I know that they refer to some type of standards, with ANSI being American and ISO being international, and that POSIX refers specifically to Unix-like OS's, which I assume means things like Linux and Mac (but what about UNIX: does UNIX-like mean UNIX?).

But what are they standards for? Are they standards for the name of functions, like saying print to screen should be called printf(), and the header file should be called stdio.h? Or are they standards for how functions should be implemented? malloc() for example is in stdlib.h, but wouldn't the function definition be different from OS to OS because each OS treats memory differently? So why isn't malloc() for Linux declared in something like unistd.h instead of stdlib.h? Similarly, why isn't malloc() for Windows in windows.h (I can't find a mac.h: is this because mac.h uses unistd.h?).

I've played around with some POSIX libraries: unistd.h, sys/types.h, sys/stat.h , and couldn't figure out what most of the functions did except tell me my user id, tell me the size of a page of memory, and make a directory, all things I could have done at the command prompt. Do the ISO and ANSI standards allow something like stdio.h to be implemented by calling functions from say unistd.h?

Also, the first person to write all these C libraries had to do so in Assembly right? And once written, you can use all these C functions instead of Assembly to rewrite all the C libraries, including the one you wrote earlier using Assembly? So if I were to look at GCC's source code for stdio.h (or I guess I should say stdio.a), would it be written in Assembly or C, and if written in C, would it include an older version of stdio.h as a preprocessor directive?

Also, would it be a mistake to write code using POSIX libraries, since Windows is the most popular OS so it is more lucrative to write using the windows library (windows.a)?

 

[schip666!]

The wiki page: http://en.wikipedia.org/wiki/C_(programming_language)
has a good description of various C language standards. It looks to be that for all practical purposed ANSI and ISO are the same beast. They specify the language syntax and behavior, but to my knowledge, do not specify any library functions.

POSIX, and others, specify the libraries. They provide a standardized access to common operating system functions, as you found, user information, memory allocation, file access, etc. Without those functions you would have to program to a specific OS interface which might be different on different systems. So they help with portability.

I don't do GUI work, if I can help it, so I'm not sure if POSIX itself standardized those libraries. There are some other standards, X-windows, etc. Which ones you use will depend on what systems you need to program for, and MSWidows is probably the most popular, now. Java made an attempt to standardize GUI's across systems, but now they have at least three flavors of window programing interfaces too.

The first computers were programmed with switches. With a little boot-strapping we got assembly code, and with a little more, a rudimentary C (or other) compiler. Then it was all gravy...heh. I haven't looked at the guts, but I'd bet that GCC is all C, and probably YACC and LEX -- which is all C underneath too. Somewhere in it's genealogy was probably a boot-strapped compiler written in assembly language, but we can now just use the old version to compile the new version.

Also, I haven't looked at any in a long time so I could be wrong, but right down at the bottom of each syslib is probably a little bit of assembly glue to do kernel context switching and such.

 

[airborne18]

I must be the old fart programmer.. Honestly the syntax differences were minor and dealt with function prototyping and formal declarations. ( C was very very forgiving in the old days, and then they actually came up with standards. ). There are a few others like inline assembler was not ANSI.

Today it is not an issue and has not been since the early 1990's.

So it really comes down to which libraries you can use. If you want to write ANSI C, you will be writing text based programs using stdio.h. That is the difference. The concept of file streams was a big issue of the day, which is an ANSI file io implement.

Honestly, it is impossible to write an ANSI program that someone would actually want to use.

So why is it a big issue? In Xenix, Unix, and the Linux world writing ANSI code is important, or was. The idea of binary distributions of Unix is relatively new. Way back us old farts had to build the operating system by compiling. So yes, you basically had the source code and a bootstrap and you loaded a kernel and filing system then copied and compilied.

Going through the source code for the std libraries is interesting, there are a lot of macros. That used to be a hobby for those of us writing dos programs with 640K; writing assembly optimized libraries for c.

Once C++ came around in the late 80's, ANSI really was not an issue. C++ forced most of the ANSI syntax features into the language and you did not have a choice.

THe best c compiler I ever used. Zortech C/C++. I still have it. A guy by the name of Walter Bright was the brain behind it, and he is a legend. ( symantec bought it and ruined it )

 

[hamster143]

It looks to be that for all practical purposed ANSI and ISO are the same beast. They specify the language syntax and behavior, but to my knowledge, do not specify any library functions.

POSIX, and others, specify the libraries. They provide a standardized access to common operating system functions, as you found, user information, memory allocation, file access, etc.

Most library functions (e.g. printf, malloc, etc.) are part of ANSI/ISO C. POSIX specifies a number of extensions, such as functions to operate threads/semaphores.

 

[D H]

It looks to be that for all practical purposed ANSI and ISO are the same beast. They specify the language syntax and behavior, but to my knowledge, do not specify any library functions.

The standard defines the C standard library. The C standard library comprises a defined set of header files that define a defined set of items. These include true library functions such as printf(), sin(), cos(), signal(), etc., but also includes macros such as assert() and type definitions such as uint32_t.

BTW, memory allocation and deallocation, malloc() and free(), are a part of the C standard library.

POSIX, and others, specify the libraries. They provide a standardized access to common operating system functions, as you found, user information, memory allocation, file access, etc. Without those functions you would have to program to a specific OS interface which might be different on different systems. So they help with portability.

You don't *have* to program to a specific OS interface. You could use fopen(), fclose(), and fprintf(), all of which are a part of the C standard. Limiting oneself to only the standard guarantees portability to any system with a compliant compiler. However, as airborne18 already pointed out,

Honestly, it is impossible to write an ANSI program that someone would actually want to use.

A portable ANSI program doesn't have a GUI, doesn't use threads, can't talk to other computers, can't lock or unlock resources. In short, not very useful.

 

[airborne18]

A portable ANSI program doesn't have a GUI, doesn't use threads, can't talk to other computers, can't lock or unlock resources. In short, not very useful.

The ANSI solution to most of this,except the GUI, is that everything is a file stream. ( memories of IBM OS2 and SNA.. ). And I guess you just write a thousand little programs to achieve threading and just keep spawning. ( I had a client insist on this once..I refused ).

 

[schip666!]

Well, I'll be dangnabbed...I should have looked at some ANSI spec before shooting from the hip. This seems to be a good summary, although the disclaimer says it's not the whole truth: http://www.acm.uiuc.edu/webmonkeys/book/c_guide/

Interesting that the spec includes the formatted I/O calls but not the lower level open/read/write/close that would most likely be used to implement them. Since I do mostly embedded work in C these days, all those "standard" functions are pretty much useless -- no file system with only 256 bytes of RAM -- I just tried to add fopen() to existing code using two different cross compilers and got nowhere. So it looks like many compilers may be ANSI compliant in syntax but not support (all) the speced libraries -- even as stubs. Just for grins I should look into the implementation of malloc() in the Microchip PIC libraries...

It's all a great Learning Experience(TM) out here.