PDF versions of the standard
As of 1st September 2014 September 2021, the best locations by price for the official C and C++ standards documents in PDF seem to be:
Non-PDF electronic versions of the standard
Print versions of the standard
Print copies of the standards are available from national standards bodies and ISO but are very expensive.
If you want a hardcopy of the C90 standard for much less money than above, you may be able to find a cheap used copy of Herb Schildt's book The Annotated ANSI Standard at Amazon, which contains the actual text of the standard (useful) and commentary on the standard (less useful - it contains several dangerous and misleading errors).
The C99 and C++03 standards are available in book form from Wiley and the BSI (British Standards Institute):
Standards committee draft versions (free)
The working drafts for future standards are often available from the committee websites:
If you want to get drafts from the current or earlier C/C++ standards, there are some available for free on the internet:
For C:
ANSI X3.159-198 (C89):
I cannot find a PDF of C89, but it is almost the same as C90. The only major differences are in the boilerplate and section numbering, although there are some slight textual differences
ISO/IEC 9899:1990 (C90):
(Almost the same as ANSI X3.159-198 (C89) except for the frontmatter and section numbering. There is at least one textual difference in section 6.5.7 (previously 3.5.7), where "a list" became "a brace-enclosed list". Note that the conversion between ANSI and ISO/IEC Standard is seen inside this document, the document refers to its name as "ANSI/ISO: 9899/99" although this isn't the right name of the later made standard of it, the right name is "ISO/IEC 9899:1990")
TC1 for C90: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n423.pdf
There isn't a PDF link for TC2 on the WG14 website, sadly.
ISO/IEC 9899:1999 (C99 incorporating all three Technical Corrigenda):
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
An earlier version of C99 incorporating only TC1 and TC2:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
Working draft for the original (i.e. pre-corrigenda) C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n843.htm (HTML) and http://www.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.pdf (PDF).
Note that there were two later working drafts: N869 and N878, but they seem to have been removed from the WG14 website, so this is the latest one available.
List of changes between C89/C90 and C99: http://port70.net/~nsz/c/c89/c9x_changes.html
TC1 for C99 (only the TC, not the standard incorporating it): http://www.open-std.org/jtc1/sc22/wg14/www/docs/9899tc1/n32071.PDF
TC2 for C99 (only the TC, not the standard incorporating it): http://www.open-std.org/jtc1/sc22/wg14/www/docs/9899-1999_cor_2-2004.pdf
ISO/IEC 9899:2011 (C11):
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
ISO/IEC 9899:2011/Cor 1:2012 (C11's only technical corrigendum): This can be viewed at https://www.iso.org/obp/ui/#iso:std:iso-iec:9899:ed-3:v1:cor:1:v1:en but cannot be downloaded. It is the actual corrigendum, not a draft.
ISO/IEC 9899:2018 (C17/C18):
https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf (N2176)
C2x work-in-progress - latest working draft as of 18th October 2020 (N2731):
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2731.pdf
For C++:
Note that these documents are not the same as the standard, though the versions just prior to the meetings that decide on a standard are usually very close to what is in the final standard. The FCD (Final Committee Draft) versions are password protected; you need to be on the standards committee to get them.
Even though the draft versions might be very close to the final ratified versions of the standards, some of this post's editors would strongly advise you to get a copy of the actual documents — especially if you're planning on quoting them as references. Of course, starving students should go ahead and use the drafts if strapped for cash.
It appears that, if you are willing and able to wait a few months after ratification of a standard, to search for "INCITS/ISO/IEC" instead of "ISO/IEC" when looking for a standard is the key. By doing so, one of this post's editors was able to find the C11 and C++11 standards at reasonable prices. For example, if you search for "INCITS/ISO/IEC 9899:2011" instead of "ISO/IEC 9899:2011" on webstore.ansi.org you will find the reasonably priced PDF version.
The site https://wg21.link/ provides short-URL links to the C++ current working draft and draft standards, and committee papers:
The current draft of the standard is maintained as LaTeX sources on Github. These sources can be converted to HTML using cxxdraft-htmlgen. The following sites maintain HTML pages so generated:
Tim Song also maintains generated HTML and PDF versions of the Networking TS and Ranges TS.
POSIX extensions to the C standard
The POSIX standard (IEEE 1003.1) requires a compliant operating system to include a C compiler. This compiler must in turn be compliant with the C standard, and must also support various extensions defined in the "System Interfaces" section of POSIX (such as the off_t
data type, the <aio.h>
header, the clock_gettime()
function and the _POSIX_C_SOURCE
macro.)
So if you've tried to look up a particular function, been informed "This function is part of POSIX, not the C standard", and wondered why an operating system standard was mandating compiler features and language extensions... now you know!
There is a draft version of POSIX.1-2008 at http://www.open-std.org/jtc1/sc22/open/n4217.pdf.
POSIX.1-2008 also had two technical corrigenda, the latter of the two being dated 2016. There is an online HTML version of the standard incorporating the corrigenda at https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/ - though, again, I have had situations where the site's own search box wasn't good for finding information.
There is an online HTML version of POSIX.1-2017 at https://pubs.opengroup.org/onlinepubs/9699919799/ - though, again, I recommend using Google instead of that site's searchbox. According to the Open Group website "IEEE 1003.1-2017 ... is a revision to the 1003.1-2008 standard to rollup the standard including its two technical corrigenda (as-is)". Linux manpages describe it as "technically identical" to POSIX.1-2008 with Technical Corrigenda 1 and 2 applied. This is therefore not a major revision and does not change the value of the _POSIX_C_SOURCE
macro.
The bit shifting operators do exactly what their name implies. They shift bits. Here's a brief (or not-so-brief) introduction to the different shift operators.
The Operators
>>
is the arithmetic (or signed) right shift operator.
>>>
is the logical (or unsigned) right shift operator.
<<
is the left shift operator, and meets the needs of both logical and arithmetic shifts.
All of these operators can be applied to integer values (int
, long
, possibly short
and byte
or char
). In some languages, applying the shift operators to any datatype smaller than int
automatically resizes the operand to be an int
.
Note that <<<
is not an operator, because it would be redundant.
Also note that C and C++ do not distinguish between the right shift operators. They provide only the >>
operator, and the right-shifting behavior is implementation defined for signed types. The rest of the answer uses the C# / Java operators.
(In all mainstream C and C++ implementations including GCC and Clang/LLVM, >>
on signed types is arithmetic. Some code assumes this, but it isn't something the standard guarantees. It's not undefined, though; the standard requires implementations to define it one way or another. However, left shifts of negative signed numbers is undefined behaviour (signed integer overflow). So unless you need arithmetic right shift, it's usually a good idea to do your bit-shifting with unsigned types.)
Left shift (<<)
Integers are stored, in memory, as a series of bits. For example, the number 6 stored as a 32-bit int
would be:
00000000 00000000 00000000 00000110
Shifting this bit pattern to the left one position (6 << 1
) would result in the number 12:
00000000 00000000 00000000 00001100
As you can see, the digits have shifted to the left by one position, and the last digit on the right is filled with a zero. You might also note that shifting left is equivalent to multiplication by powers of 2. So 6 << 1
is equivalent to 6 * 2
, and 6 << 3
is equivalent to 6 * 8
. A good optimizing compiler will replace multiplications with shifts when possible.
Non-circular shifting
Please note that these are not circular shifts. Shifting this value to the left by one position (3,758,096,384 << 1
):
11100000 00000000 00000000 00000000
results in 3,221,225,472:
11000000 00000000 00000000 00000000
The digit that gets shifted "off the end" is lost. It does not wrap around.
Logical right shift (>>>)
A logical right shift is the converse to the left shift. Rather than moving bits to the left, they simply move to the right. For example, shifting the number 12:
00000000 00000000 00000000 00001100
to the right by one position (12 >>> 1
) will get back our original 6:
00000000 00000000 00000000 00000110
So we see that shifting to the right is equivalent to division by powers of 2.
Lost bits are gone
However, a shift cannot reclaim "lost" bits. For example, if we shift this pattern:
00111000 00000000 00000000 00000110
to the left 4 positions (939,524,102 << 4
), we get 2,147,483,744:
10000000 00000000 00000000 01100000
and then shifting back ((939,524,102 << 4) >>> 4
) we get 134,217,734:
00001000 00000000 00000000 00000110
We cannot get back our original value once we have lost bits.
Arithmetic right shift (>>)
The arithmetic right shift is exactly like the logical right shift, except instead of padding with zero, it pads with the most significant bit. This is because the most significant bit is the sign bit, or the bit that distinguishes positive and negative numbers. By padding with the most significant bit, the arithmetic right shift is sign-preserving.
For example, if we interpret this bit pattern as a negative number:
10000000 00000000 00000000 01100000
we have the number -2,147,483,552. Shifting this to the right 4 positions with the arithmetic shift (-2,147,483,552 >> 4) would give us:
11111000 00000000 00000000 00000110
or the number -134,217,722.
So we see that we have preserved the sign of our negative numbers by using the arithmetic right shift, rather than the logical right shift. And once again, we see that we are performing division by powers of 2.
Best Answer
Bitwise operations (like arithmetic operations) operate on values and ignore padding. The implementation may or may not modify padding bits (or use them internally, eg as parity bits), but portable C code will never be able to detect this. Any value (including
UINT_MAX
) will not include the padding.Where integer padding might lead to problems on is if you use things like
sizeof (int) * CHAR_BIT
and then try to use shifts to access all these bits. If you want to be portable, either only use (unsigned
)char
, fixed-sized integers (a C99 addition) or determine the number of value-bits programatically. This can be done at compile-time with the preprocessor by comparingUINT_MAX
against powers of 2 or at runtime by using bit-operations.edit:
C90 does not mention integer padding at all, but as far as I can tell, 'invisible' preceding or trailing integer padding bits shouldn't violate the standard (I didn't go through all relevant sections to make sure this is really the case, though); there probaby are problems with mixed padding and value bits as mentioned in the C99 rationale because otherwise, the standard would not have needed to be changed.
As to the meaning of user-accessible: Padding bits are accessible insofar as you can alwaye get at any bit of
foo
(including padding) by using bit-operations on((unsigned char *)&foo)[…]
. Be careful when modifying the padding bits, though: the result won't change the value of the integer, but might create be a trap-representation nevertheless. In case of C90, this is implicitly unspecified (as in not mentioned at all), in case of C99, it's implementation-defined.This was not what the rationale quotation was about, though: the cited architecture represents 32-bit integers via two 16-bit integers. In case of unsigned types, the resulting integer has 32 value bits and a precision of 32; in case of signed integers, it only has 31 value bits and a precision of 30: one of the sign bits of the 16-bit integers is used as the sign bit of the 32-bit integer, the other one is ignored, thus creating a padding bit surrounded by value bits. Now, if you access a 32-bit signed integer as an unsigned integer (which is explicitly allowed and does not violate the C99 aliasing rules), the padding bit becomes a (user-accessible) value bit.