Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

C macro question



True that blindly following a standard can lead to trouble. 
Without quoting the rest of what you said, the C standard (ISO 89 or ISO 
99) is a standard for the C language and has nothing to do with any OS. The 
interfaces defined by the standard are OS independent.
POSIX, X/Open (eg xpg3, Unix 95, Unix 98) et. al. are specifications for 
the OS. They standardize many interfaces, both on the system call level as 
well as the library level.
You mentioned signals. The old signal(2) interface is deprecated in most 
Unix systems. Calls such as sigaction(2) are much more reliable. What the C 
standard is defining is the minimum subset of signal. Also, Unix signals 
are unreliable when compared to ASTs in VMS or other operating systems.
Then, enter threads. There are many standard C functions (ctime(3) for 
instance) which is not threadsafe. The old method of declaring errno as a 
global variable is also not threadsafe. Most systems now set up errno as a 
macro whose value depends on whether the program is threaded or not. But, 
because of the C standard, errno must still be defined as a global variable.

The bottom line though, is that the standards provide a guideline to 
portable programming. Programmers who follow the standard generally have 
more portable code than programmers who do not. All major Unix vendors as 
well as GCC comply with ISO 89 and some comply with ISO 99.
"Derek D. Martin" wrote:

> In summary, I offer all this in support of the notion that, while
> having standards is a good thing, blindly following them is not.
> There will always be cases where the standards do the wrong thing, and
> there will always be cases where you will save yourself significant
> work and headaches by ignoring them.  The trick is to know the
> environment(s) you're making use of well enough to know when to do
> that.  =8^)
-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9






BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org