Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

C History

Old News ;) Recommended Links Languages history Multix BCPL PL/1 Early C ASCI C

Old News ;-)

[ Mar 24  2004] Open source development using C99 Is your C code up to standard? by Peter Seebach ([email protected]) What is C99? Who needs it? Is it available yet? Peter Seebach discusses the 1999 revision of the ISO C standard, with a focus on the availability of new features on Linux and BSD systems.

... ... ...
There are two parts of the C programming language. These are, confusingly, called the "language" and the "library." Historically, there was a bundle of commonly used utility code that everyone tended to reuse; this was eventually standardized into what's called the Standard C Library. The distinction was pretty easy to understand at first: If the compiler did it, it was the language; if it was in the add-on code, it was the library.

With time, however, the distinction has been blurred. For instance, some compilers will generate calls to an external library for 64-bit arithmetic, and some library functions might be handled magically by the compiler. For the purposes of this article, the division follows the terminology of the standard: features from the "Library" section of the standard are library features and are discussed in the next section of the article. This section looks at everything else.

The C99 language introduces a number of new features that are of potential interest to software developers. Many of these features are similar to features of the GNU C set of extensions to C; unfortunately, in some cases, they are not quite compatible.

A few features popularized by C++ have made it in. In particular, // comments and mixed declarations and code have become standard features of C99. These have been in GNU C forever and should work on every platform. In general, though, C and C++ remain separate languages; indeed, C99 is a little less compatible with C++ than C89 was. As always, trying to write hybrid code is a bad idea. Good C code will be bad C++ code.

C99 added some support for Unicode characters, both within string literals and in identifiers. In practice, the system support for this probably isn't where it needs to be for most users; don't expect source that uses this to be accessible to other people just yet. In general, the wide character and unicode support is mostly there in the compiler, but the text processing tools aren't quite up to par yet.

The new variable-length array (VLA) feature is partially available. Simple VLAs will work. However, this is a pure coincidence; in fact, GNU C has its own variable-length array support. As a result, while simple code using variable-length arrays will work, a lot of code will run into the differences between the older GNU C support for VLAs and the C99 definition. Declare arrays whose length is a local variable, but don't try to go much further.

Compound literals and designated initializers are a wonderful code maintainability feature. Compare these two code fragments:

Listing 1. Delaying for n microseconds in C89
 


    /* C89 */
    {
        struct timeval tv = { 0, n };
        select(0, 0, 0, 0, &tv);
    }

 

Listing 2. Delaying for n microseconds in C99
 


    // C99
    select(0, 0, 0, 0, & (struct timeval) { .tv_usec = n });

The syntax for a compound literal allows a brace-enclosed series of values to be used to initialize an automatic object of the appropriate type. The object is reinitialized each time its declaration is reached, so it's safe with functions (such as some versions of select) that may modify the corresponding object. The designated initializer syntax allows you to initialize members by name, without regard to the order in which they appear in an object. This is especially useful for large and complicated objects with only a few members initialized. As with a normal aggregate initializer, missing values are treated as though they'd been given 0 as an initializer. Other initialization rules have changed a bit. For instance, you're now allowed to have a trailing comma after the last member of an enum declaration, to make it just a bit easier to write code generators.

For years, people have been debating extensions to the C type system, such as long long. C99 introduces a handful of new integer types. The most widely used is long long. Another type introduced by the standards process is intmax_t. Both of these types are available in gcc. However, the integer promotion rules are not always correct for types larger than long. It's probably best to use explicit casts.

There are also a lot of types allowing more specific descriptions of desired qualities. For instance, there are types with names like int_least8_t, which has at least 8 bits, and int32_t, which has exactly 32 bits. The standard guarantees access to types of at least 8, 16, 32, and 64 bits. There is no promise that any exact-width types will be provided. Don't use such types unless you are really, totally sure that you can't accept a larger type. Another optional type is the new intptr_t type, which is an integer large enough to hold a pointer. Not all systems provide such a type (although all current Linux and BSD implementations do).

The C preprocessor has a number of new features. It allows empty arguments, and it supports macros with varying numbers of arguments. There is a _Pragma operator for macro-generating pragmas, and there's a __func__ macro, which always contains the name of the current function. These features are available in current versions of gcc.

C99 added the inline keyword to suggest function inlining. GNU C also supports this keyword, but with slightly different semantics. If you're using gcc, you should always use the static keyword on inline functions if you want the same behavior as C99 would give for the code. This may be addressed in future revisions; in the meantime, you can use inline as a compiler hint, but don't depend on the exact semantics.

C99 introduced a qualifier, restrict, which can give a compiler optimization hints about pointers. Because there is no requirement that a compiler do anything with this, it's done in that gcc accepts it. The degree of optimization done varies. It's safe to use, but don't count on it making a huge difference yet. On a related note, the new type-aliasing rules are fully supported in gcc. This mostly means that you must be more careful about type punning, which is almost always going to invoke undefined behavior, unless the type you're using to access data of the wrong sort is unsigned char.

Array declarators as function arguments now have a meaningful difference from pointer declarators: you can put in type qualifiers. Of particular interest is the very odd optimizer hint of giving an array declarator the static type modifier. Given this declaration: int foo(int a[static 10]);

It is undefined behavior to call foo() with a pointer that doesn't point to at least 10 objects of type int. This is an optimizer hint. All you're doing is promising the compiler that the argument passed to the function will be at least that large; some machines might use this for loop unrolling. As old hands will be well aware, it's not a new C standard without an entirely new meaning for the static keyword.

One last feature to mention is flexible array members. There is a common problem of wanting to declare a structure that is essentially a header followed by some data bytes. Unfortunately, C89 provided no good way to do this without giving the structure a pointer to a separately allocated region. Two common solutions included declaring a member with exactly one byte of storage, then allocating extra and overrunning the bounds of the array, and declaring a member with more storage than you could possibly need, underallocating, and being careful to use only the storage available. Both of these were problematic for some compilers, so C99 introduced a new syntax for this:

Listing 3. A structure with a flexible array
 


    struct header {
        size_t len;
        unsigned char data[];
    };

This structure has the useful property that if you allocate space for (sizeof(struct header) + 10) bytes, you can treat data as being an array of 10 bytes. This new syntax is supported in gcc.

Library features
That's fine for the compiler. What about the standard library? A lot of the library features added in C99 were based on existing practice, especially practices found in the BSD and Linux communities. So, many of these features are preexisting ones already found in the Linux and BSD standard libraries. Many of these features are simple utility functions; almost all of them could in principle be done in portable code, but many of them would be exceedingly difficult.

Some of the most convenient features added in C99 are in the printf family of functions. First, the v*scanf functions have become standardized; for every member of the scanf family, there is a corresponding v*scanf function that takes a va_list parameter instead of a variable argument list. These functions serve the same role as the v*printf functions, allowing user-defined functions that take variable argument lists and end up calling a function from the printf or scanf family to do the hard work.

Secondly, the 4.4BSD snprintf function family has been imported. The snprintf function allows you to print safely into a buffer of fixed size. When told to print no more than n bytes, snprintf guarantees that it creates a string of length no more than n-1, with a null terminator at the end of the string. However, its return code is the number of characters it would have written if n had been large enough. Thus, you can reliably find out how much buffer space you would need to format something completely. This function is available everywhere, and you should use it just about all the time; a lot of security holes have been based on buffer overruns in sprintf, and this can protect against them.

A number of new math features, including complex math features and special functions designed to help optimizing compilers for specific floating point chips are in the new standard, but not reliably implemented everywhere. If you need these functions, it is best to check on the exact platform you're targeting. The floating point environment functions are not always supported, and some platforms will not have support for IEEE arithmetic. Don't count on these new features yet.

The strftime() function has been extended in C99 to provide a few more commonly desired formatting characters. These new characters appear to be available on recent Linux and BSD systems; they aren't always widely available on somewhat older systems, though. Check the documentation before using new formats.

As noted, most of the internationalization code is not reliably implemented yet.

Other new library features are typically not universally available; the math functions are likely to be available in supercomputer compilers, and the internationalization functions are likely to be available in compilers developed outside the United States. Compiler vendors implement the features they have a call for.

... ... ...

Resources

 

 kuro5hin.org/Are you Ready For C99

Status of C99 features in GCC - GNU Project - Free Software ...

Tech Talk about C++ and C Issues - Comeau C++ and C FAQ

Dinkum C99 Library Reference

C9X -- The New C Standard

C99.ORG

Open source development using C99

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

See also Selected Computing Sciences Technical Reports from Bell Labs

BCPL


Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to to buy a cup of coffee for authors of this site

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019