UNIX and C Standards

• Since the invention of the UNIX in 1960s many versions of the

UNIX were developed.
• Latest UNIX was developed by AT&T and BSD.
• In 1980, AT&T Sun Micro systems made an attempt to bring
uniformity to the UNIX OS, but this attempt was not successful.
• Later two standard bodies ANSI and IEEE become successful in
giving the standards to the C programming language and UNIX
OS.
- ANSI (American National Standards Institute) gave
standards for C Language – ANSI C Standards
- IEEE (Institute of Electrical and Electronic Engineers) gave
standards of UNIX OS – POSIX Standards
POSIX – Portable Operating System Interface.
 Need for Standards
• Since there were many versions of UNIX OS. It was very
difficult to write portable application.
• Application written on one versions of the UNIX OS was
not compatible with other version of the UNIX OS.
• Standards are required for writing the portable
applications.
• Standards are very important for the advanced UNIX
programmer’s who make extensive use of the API.
- Ex- fcntl( ) API on some visions of the UNIX OS
supports both file locking and querying the access modifier
flags and in some versions supports only the file locking.
 ANSI C Standards
• ANSI proposed standards to C programming
language standard X3.159 in1989.
• Through X3.159 standard ANSI made an
attempt to bring uniformity to the C and was
successful in it.
• But many computer vendors even today still
support default K & R C (Brain Kernighan and
Dennis Ritchie C).
Difference Between ANSI C and K & R C
• ANSI C supports function prototyping.
K&R C does not support function prototyping.

• ANSI C supports const and volatile data type qualifiers.

K&R C does not support const and volatile data type qualifiers

• ANSI C supports internationalization and wide characters

ASCII Code (one byte per character)
wide characters: (Uni code representation 2 bytes per character)
Supports internationalization through the setlocale( ) system call.
 Difference Between ANSI C and K & R C
Conti…
• Setlocale () prototype:
#include<locale.h>
char * setlocale (int category, const char * locale);

Category values:
LC_CTYPE: Affects the behavior of ctype.h header file
LC_DATE: Affects the format of date
LC_TIME: Affects the format of time
LC_MONETARY: Affects the format of currency
LC_ALL: Affects the behavior of all the above.

Locale vales:
C  Sets to the ANSI C standard format
POSIX  Sets to the POSIX standard format
EN_US  Sets the the US format.
 Difference Between ANSI C and K & R C
conti….
• ANSI C supports function pointer to be used without using
the dereferencing operator (*).
K&R C does not support function pointer to be used
without dereferencing operator (*).
Example: void add(int a, int b)
{
//body
}
Pointer declaration: void (*funcptr)(int, int)=add
Invoked in ANSI C : funcptr(6,7); or add(6,7);
In K&R C: (*funcptr)(6,7); or add(6,7)
 ANSI/ISO C++ Standard
• C++ as invented by B Stroustrup at AT&T Bell labs in 1980s.
• It was derived from C language and incorporates the object
oriented constructs like Class, Object etc.,
• C++ gained wide acceptance by the software professionals.
• This made B Stroustrup to publish an annotated C++ reference
manual in 1989.
• Later the annotated C++ reference manual was used by X3J16
committee of ANSI modified and published it as draft C++ ANSI
standard.
• Later in 1990s WG21 committee of ISO joined X3J16 and
published an updated and complete C++ standards called as
ANSI/ISO C++ Standard.
 Difference Between ANSI C and ANSI/ISO
C++ Standard
• ANSI/ISO C++ standards mandates the function prototyping.
ANSI C supports function prototyping but it is not
mandatory.
• Function without argument
add( );
ANSI C : Treats the function as the function that can take
variable number of arguments.
add(…..);
ANSI/ISO C++: Treats the function with void arguments.
add(void);
 Difference Between ANSI C and ANSI/ISO
C++ Standard Conti…
• ANSI/ISO C++ employs the external type safe linkage.
Example:
A.CPP B.CPP
#include<stdio.h> #include<stdio.h>
int main() void Func(int a)
{ {
Func(); printf(“a=%d”,a);
} }
ANSI/ISO C++ compiler generates the compiler error.
• When compiled using ANSI C compiler does not generate the
compiler error because it does not employ the external type safe
linkage.
 POSIX Standards
• IEEE formed a force called as POSIX to propose standards to the UNIX OS.
• POSIX again divided into 3 sub groups.
- POSIX.1
- POSIX.1b
- POSIX.1c
POSIX.1:
This committee proposed standards for the API related to File manipulation and
Process management. IEEE formally called it as 1003.1 1990[6].

POSIX.1b:
This committee proposed standards for the API related to IPC (Inter-process
Communication). IEEE formally called it as 1003.4 1993[7].

POSIX.1c:
This committee proposed standards for the API related to multi thread programming.
IEEE formally called it as 1003.4 1993[8].
 Writing a Program that Confirms to POSIX
Standards
• Use the manifested constants below.
1) _POSIX_SOURCE: To make C program confirm to POSIX.1
standards define this constant before any header files
ex:- #define _POSIX_SOURCE
//then header files
#include<stdio.h>
2) –D_POSIX_SOURCE: To make C++ program confirm to the
POSIX.1 standards specify this as the option at compile time.
ex:- g++ -D_POSIX_SOURCE <filename.cpp>
 Writing a Program that Confirms to POSIX
Standards
3) _POSIX_C_SOURCE: To make C program confirm to
POSIX.1, POSIX.1b and POSIX.1c define this constant
before any header files.
ex:- #define _POSIX_C_SOURCE 199308L
//then header files
#include<stdio.h>
4) –D_POSIX_C_SOURCE: To make C++ program confirm
to POSIX.1, POSIX.1b and POSIX.1c specify this as the
option during compiling.
ex:- g++ -D_POSIX_C_SOURCE <filename.cpp>
 POSIX Environment
• UNIX environment physical existence of the header
file like stdio.h is required in the /usr/include
directory.
• POSIX environment physical existence of the header
file is not mandatory in the /usr/include directory.
• Hence header files are called as only headers in
POSIX environment.
• If header is not present in the /usr/include directory
in POSIX then it is built into the compiler.
 UNIX and POSIX API Common
Characteristics
• All UNIX and POSIX APIs are designed to return a well known value -1 if they are
unsuccessful.
• Appropriate error status code is set to the global variable errno.
• Exact reason for the failure of the API can be known by examining the global variable
errno.
• UNIX and POSIX provide two API to examine the errno.

1) #include<errno.h>
char * strerror(int errno);
This takes the errno and return the meaningful error message that describes the
reason for failure.
2) #include<errno.h>
char * perror(“Failure:”);
This takes one user string argument that will be appended with the system generated
error message.
Example output: Failure: Bad File Descriptor
User System
Message Message
 Error Status Codes and Their Meanings
• EACCESS  A process does not have access permission to perform
the operation.
• EPERM API aborted because the calling process does not have
super user privilege.
• ENOENT  An API is passed with the invalid file name.
• EBADF  An API is passed with the invalid file descriptor
• EINTR  An API execution is aborted because of signal interruption.
• EAGAIN  An API execution aborted because the resource it
request is temporarily unavailable.
• ENOMEM  An API aborted because it could not be allocated with
the requested dynamic memory.
• EIO  An API aborted because of IO error.
 Examples on strerror () and perror ()
1)
#include<stdio.h>
#include<errno.h>
int main()
{
Printf(“EACCESS:%s”,strerror(EACCESS));
return 0;
}

2)
#include<stdio.h>
#include<errno.h>
int main()
{
errno=EACCESS;
perror(“Failure:”);
return 0;
}