Talk:Stdint.h

Linux 'long'

It's only 32 bits on 32 bit architectures isn't it? 155.198.65.73 (talk) 16:35, 28 October 2010 (UTC)[reply]

Correct. On 32-bit Linux (and 32-bit Windows), sizeof(int) = sizeof(long) = sizeof(void*). Alksentrs (talk) 11:18, 29 October 2010 (UTC)[reply]

In that case, the table showing equivalent types was wrong and I have changed it. Celada (talk) 06:03, 6 November 2010 (UTC)[reply]

I'm sorry to be a little blunt here, but the simple fact is there is no such thing as a "Linux long". Linux on what architecture? With what compiler? Are we talking about in the past, today, or tomorrow? Those columns suggesting sizeof(int) etc. in the table didn't make any sense and I removed them. The C language leaves these things unspecified. If Wikipedia would like to be "the source of record", it should not suggest people start thinking that sizeof(long) is guaranteed to be a particular constant. Regardless of how common a particular size may be, it's incorrect and ceases to be C when you talk about it that way. I pity the poor inexperienced C programmer who stumbled upon that table. 174.31.231.72 (talk) 12:21, 6 January 2011 (UTC)[reply]

Maybe something like a table here would be better way to express that information? Also note that the standard does define minimum width requirements. 1exec1 (talk) 00:42, 8 January 2011 (UTC)[reply]

Verification code

I've removed the following piece of text:

Verification Code

This simple union may be added to force the compiler to verify that the sizes are what they say they are for every build.

static union
{
  	char 	int8_t_incorrect 	[sizeof(  int8_t) == 1];
  	char 	uint8_t_incorrect 	[sizeof( uint8_t) == 1];
  	char 	int16_t_incorrect 	[sizeof( int16_t) == 2];
  	char 	uint16_t_incorrect 	[sizeof(uint16_t) == 2];
  	char 	int32_t_incorrect 	[sizeof( int32_t) == 4];
  	char 	uint32_t_incorrect 	[sizeof(uint32_t) == 4];
  	char 	int64_t_incorrect 	[sizeof( int64_t) == 8]; /* Optional */
  	char 	uint64_t_incorrect 	[sizeof(uint64_t) == 8]; /* Optional */
};

I have about three problems with it:

The author seems to assume that sizeof returns a size in 8-bit bytes, but a byte is the smallest addressable unit suitable to store a character, which is not necessarily equal to 8 bits. It would seem to me that it is perfectly legal to e.g. have sizeof(int32_t) == 1 on a platform that has 32-bit addressing.
The author seems to assume that the compilation fails when an array of length 0 is declared, but this is perfectly legal in C99 (where these new integer types are introduced in the first place) and many/most non-C99-compliant compilers allow 0 length arrays as an extension. Therefore, the verification code is only able to verify anything on pre-C99 compilers that do not allow 0 length arrays as an extension but that do provide the required definitions in stdint.h. This seems like a very rare situation, making the verification code useless in most cases.
Even if the code above worked correctly (see 1) and reliably (see 2) I don't think an encyclopedia is the place to document programming tips-'n'-tricks. I'd like to see at least a reputable source (e.g. a standards document or a published programming book) document this trick; in that case, the article text should reference that source.

So if someone wants to add this back in, please address the issues above first, and make sure you cite your sources. Thanks! 130.89.167.52 (talk) 17:31, 25 April 2008 (UTC)[reply]

Objection 1 is fixable with * CHAR_BIT. Objection 2 is fixable with ? 1 : -1. static assert. Objection 3 is fixable by citing the article that Assertion (computing)#Static assertions cites: Jon Jagger, Compile Time Assertions in C, 1999. --Damian Yerrick (talk | stalk) 02:23, 17 August 2011 (UTC)[reply]

Unreadable sentence

Would the author (or anyone) please rewrite this sentence in the "Representation" section? I suspect it may need to become at least two sentences to be readable: "Most programmers deal with this representation because it allows them easily to write portable code by only dealing with −0 and out of range values as opposed to both of those in addition to tricky aliasing rules and trap representations if they choose to deal with the object representation directly." —Wegesrand (talk) 11:31, 4 February 2011 (UTC)[reply]

external links

two of the external links point to the same place: code.google.com/p/msinttypes/ —Preceding unsigned comment added by 203.206.162.148 (talk) 09:21, 3 March 2011 (UTC)[reply]

Unicited

Both claims and criticisms in this article are wholly bereft of citations. They should either be supported by RS refs, or deleted, per our verifiability policy.--Epeefleche (talk) 21:56, 18 September 2011 (UTC)[reply]