Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: A glitch regarding the usual malloc() idiom Date: Sun, 24 Jul 2016 21:12:01 -0700 Organization: None to speak of Lines: 79 Message-ID: References: <4cd22745-22ad-4ac7-bdba-39ffa1c75e13@googlegroups.com> <7d995799-5f23-4784-a62e-ea423de00650@googlegroups.com> <36f1e05e-609e-4e0e-8819-86feee1f4d8c@googlegroups.com> <57933a73.4812875@news.xs4all.nl> <5793c8e5.2941812@news.xs4all.nl> <87oa5n97rz.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="28614"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19NlhzCmWjZ61+oZKQcyb1u" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:cu/tNv6tEjS8G3eh55Qp11P7wFQ= sha1:0Rf8j21U2K0YHrpW+H8ha6+Vn60= Xref: csiph.com comp.lang.c:90959 James Kuyper writes: > On 07/24/2016 10:14 PM, Keith Thompson wrote: >> jameskuyper@verizon.net writes: >> [...] >>> There are CHAR_BIT padding bits in a padding byte. >> [...] >> >> As I just mentioned in response to Richard Heathfield, the standard >> (almost) consistently uses the the term "padding bits" to refer to >> bits within the representation of an integer that do not contribute >> to its value, and "padding bytes" to refer to bytes within the >> representation of a structure or union that are not part of the >> representation of any member. >> >> A collection of CHAR_BIT padding bits is just CHAR_BIT padding bits. >> The collection, though it happens to be the same size as a byte, >> might not even be addressible, which means it would not meet the >> standard's definition of a "byte". > > The standard never provides it's own definition of "padding bit" or > "padding byte", so we're left to rely upon the rules of ordinary English > usage. As far as I'm concerned, it's entirely reasonable to refer to an > entire byte consisting of padding bits as a padding byte. The standard > never says anything about padding bytes that is inconsistent with that > belief. Only if that byte is addressible. The standard's definition of a "byte" is addressable unit of data storage large enough to hold any member of the basic character set of the execution environment So (assuming CHAR_BIT==8), if 8 padding bits happen to occupy an addressible byte of memory, then we might call them a "padding byte", but 8 bits straddling a byte boundary are not strictly speaking a "byte". Not that it matters, of course. > More importantly, the point we're trying to convince Jerry about also > does not depend upon whether or not "padding byte" is an appropriate > term to use for such a byte. All that matters is the fact that the > standard imposes no upper limit on the number of padding bits. Whether > or not the type has any bytes that consist entirely of padding bits is > irrelevant to that argument. Right. I don't read Jerry's posts (he's buried so deeply in my killfile/scorefile I never even see them unless someone else quotes him), but certainly the question of whether padding bits can gather into bytes is irrelevant to the current discussion. Clearly the standard places no upper bound on the number of padding bits a (non-char) integer type can have, and clearly the standard permits sizeof (short) > sizeof (int). A conforming implementation could have: CHAR_BIT == 8 sizeof (unsigned short) == 4 USHRT_MAX == 65535 // implying that unsigned short has 16 value bits and 16 padding bits sizeof (unsigned int) == 2 UINT_MAX == 65535 // implying that unsigned int has 16 value bits and no padding bits (I've omitted signed short and signed int. I don't think they're necessary to make the point.) Those 16 padding bits in type unsigned short may or may not occupy 2 bytes. The standard doesn't call them "padding bytes" because it doesn't matter whether they do or not. I can't think of a good reason that a real implementation would do that, but nothing in the standard forbids it. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"