Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > size of a pointer on 4-bit system

Reply
Thread Tools

size of a pointer on 4-bit system

 
 
James Kuyper
Guest
Posts: n/a
 
      02-03-2013
On 02/03/2013 02:09 PM, Richard Damon wrote:
> On 2/3/13 7:46 AM, James Kuyper wrote:

....
>> The case which does matter is if an extended integer type is used by the
>> implementation for one of the standard things that can be typedefs for
>> an integer type, such as size_t. Using a size_t that's a typedef for an
>> extended integer type does not have undefined behavior (at least, not
>> for that reason), and must have behavior consistent with the
>> requirements of the standard. Which rules out, among other things,
>> having sizeof() behave as oddly as you suggests it could, if used on
>> that typedef. If used directly on the extended type, there's no problem,
>> but when used on the standard typedef, it must behave normally. It must
>> do all the things that the standard requires of a type suitable for use
>> as the corresponding typedef.
>>
>> If it weren't for the sizeof() issue, _Nybble could obviously meet the
>> requirements for [u]int4_t, [u]int_least4_t, and [u]int_fast4_t. Less
>> obviously, it could also meet the requirements for clock_t, fpos_t.
>> time_t, though selecting it for any of those purposes would render the
>> corresponding features of C nearly useless.
>>

>
> I never said size_t would be en extended integer type.


No, you did not. However, an implementation choosing to identify _Nybble
as one of the extended integer types it supports, and then using it in
one of the standard typedefs, is the only way in which there could be a
non-trivial connection between the language it implements and the
requirements of the C standard. That non-trivial connection is that it
cannot conform to the standard's requirements of sizeof expressions, but
the reasons why are subtle enough to be worthy of some discussion.
Otherwise, everything is covered by "undefined behavior", and there's
nothing worth saying about it in this forum (which hasn't apparently
stopped people).
--
James Kuyper
 
Reply With Quote
 
 
 
 
Shao Miller
Guest
Posts: n/a
 
      02-03-2013
On 2/3/2013 14:27, James Kuyper wrote:
> On 02/03/2013 02:09 PM, Richard Damon wrote:
>> On 2/3/13 7:46 AM, James Kuyper wrote:

> ...
>>> The case which does matter is if an extended integer type is used by the
>>> implementation for one of the standard things that can be typedefs for
>>> an integer type, such as size_t. Using a size_t that's a typedef for an
>>> extended integer type does not have undefined behavior (at least, not
>>> for that reason), and must have behavior consistent with the
>>> requirements of the standard. Which rules out, among other things,
>>> having sizeof() behave as oddly as you suggests it could, if used on
>>> that typedef. If used directly on the extended type, there's no problem,
>>> but when used on the standard typedef, it must behave normally. It must
>>> do all the things that the standard requires of a type suitable for use
>>> as the corresponding typedef.
>>>
>>> If it weren't for the sizeof() issue, _Nybble could obviously meet the
>>> requirements for [u]int4_t, [u]int_least4_t, and [u]int_fast4_t. Less
>>> obviously, it could also meet the requirements for clock_t, fpos_t.
>>> time_t, though selecting it for any of those purposes would render the
>>> corresponding features of C nearly useless.
>>>

>>
>> I never said size_t would be en extended integer type.

>
> No, you did not. However, an implementation choosing to identify _Nybble
> as one of the extended integer types it supports, and then using it in
> one of the standard typedefs, is the only way in which there could be a
> non-trivial connection between the language it implements and the
> requirements of the C standard. That non-trivial connection is that it
> cannot conform to the standard's requirements of sizeof expressions, but
> the reasons why are subtle enough to be worthy of some discussion.
> Otherwise, everything is covered by "undefined behavior", and there's
> nothing worth saying about it in this forum (which hasn't apparently
> stopped people).
>


This response could be evidence of the problem with using "type" that I
had tried to point out earlier. Don't call it a "type" and someone
can't confuse it with "extended integer type". '_Nybble' and '_Nsize_t'
could be extension keywords and could be defined as part of the
'type-specifier' syntax, but like 'typedef' as a
'storage-class-specifier', could have different meaning and constraints.

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-04-2013
James Kuyper <(E-Mail Removed)> writes:

> On 02/02/2013 09:25 PM, Ben Bacarisse wrote:
> ...
>> Are you imagining a sort of nuclear option for UB? ...

>
> Undefined behavior IS the nuclear option. It's hard to go any more
> "nuclear" than "no requirements".


I meant nuclear in terms of the discussion. When talking about how well
or easily C can support feature X, the discussion is interesting (to me
at least) only in so far as the "nuclear option" is not invoked. All
features can be supported in an extended C -- just add

__Undefined;

at the top and you can have bit addressing, arbitrary precision numbers,
closures and what have you. What's interesting is how well the new
facility integrates with the rest of the language. How much of the
existing semantics must be thrown out? How much of the normal behaviour
of C can be applied to the new types or features? Once you use a
_Nibble type, it's perfectly permissible for the expression 1 + 2 to
have the value "banana", but we'd really like most of C to remain
unchanged.

--
Ben.
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      02-04-2013
On 2/3/2013 19:04, Ben Bacarisse wrote:
> James Kuyper <(E-Mail Removed)> writes:
>
>> On 02/02/2013 09:25 PM, Ben Bacarisse wrote:
>> ...
>>> Are you imagining a sort of nuclear option for UB? ...

>>
>> Undefined behavior IS the nuclear option. It's hard to go any more
>> "nuclear" than "no requirements".

>
> I meant nuclear in terms of the discussion. When talking about how well
> or easily C can support feature X, the discussion is interesting (to me
> at least) only in so far as the "nuclear option" is not invoked. All
> features can be supported in an extended C -- just add
>
> __Undefined;
>
> at the top and you can have bit addressing, arbitrary precision numbers,
> closures and what have you. What's interesting is how well the new
> facility integrates with the rest of the language. How much of the
> existing semantics must be thrown out? How much of the normal behaviour
> of C can be applied to the new types or features? Once you use a
> _Nibble type, it's perfectly permissible for the expression 1 + 2 to
> have the value "banana", but we'd really like most of C to remain
> unchanged.
>


Agreed, and Objective-C comes to mind.

But to be honest, I'd prefer to use a 'malloc' wrapper, "array access"
wrapper function (which could be inlined during translation), etc. that
know about nibbles and perform the required computations, rather than to
spend hours defining a new
language^H^H^H^H^H^H^H^H^H^H^H^H^H^Hextensions. $0.02.

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      02-04-2013
Ben Bacarisse <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>
>> "BartC" <(E-Mail Removed)> writes:
>>
>>> "Tim Rentsch" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> glen herrmannsfeldt <(E-Mail Removed)> writes:
>>>
>>>>>> There's no reason a conforming implementation couldn't provide its
>>>>>> own four-bit data types, including arrays of such data types. The
>>>>>> rule that all non-bitfield types must be multiples of 'char' in
>>>>>> width applies only to Standard-defined types, not to types provided
>>>>>> as part of extensions.
>>>>>
>>>>> OK, I agree. It does have the complication that
>>>>>
>>>>> nybble *x;
>>>>> x=malloc(100*sizeof(*x));
>>>>>
>>>>> won't allocate 100 nybbles, unless sizeof works differently.
>>>>> [snip]
>>>>
>>>> The sizeof operator can be defined in a way that satisfies all
>>>> the Standard's requirements but still allows this example to
>>>> allocate only 100 nibbles.
>>>
>>> So what would be the value of sizeof(*x)? It can only really
>>> be 1 or 0. [snip elaboration]

>>
>> Actually that isn't right. Using 'sizeof' on a non-standard
>> datatype may behave in unexpected ways. Here's a hint: sizeof
>> yields a result of type size_t; size_t is an (unsigned) integer
>> type; integer types larger than character types may have padding
>> bits. Can you fill in the rest?

>
> I can't. Can the value of an operator that yields an integer have
> padding bits? The wording is not always 100% unambiguous, but my
> understanding that padding bits are part of the representation.


The point of my comment is not that it is possible but that it is
feasible. It's easy enough to make sizeof give an appropriate
value. The question is, can we devise a representation for size_t
that can hold such values reliably but still falls within the
Standard's boundaries for integer types, and also has a reasonable
implementation?

> My first thought was that you want the padding bits (always
> supposing they can be there in a value) to encode the fact the
> result is a nibble size rather than a byte size, but I still can't
> square that with the need for the result to be both "an integer"
> and "the size (in bytes) of its operand".


I don't know quite how to respond to this. What we're talking
about is an extension to standard C. It seems obvious that an
extension to C necessarily involves undefined behavior, otherwise
it wouldn't be an extension. On top of that, I already said in
the previous posting that "Using 'sizeof' on a non-standard
datatype may behave in unexpected ways." The Standard doesn't
impose any requirements for sizeof applied to such data types, or
indeed any type outside of those defined in the Standard. The
interesting part is what happens downstream from sizeof. In
particular, can we define semantics for size_t that both satisfies
the requirements for regular C data types, and also allows size_t
values for the four-bit data types to be used in the same sorts of
ways that their Standard-defined counterparts are and still have
them work as expected? (And obviously I think the answer is yes.)
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      02-04-2013
Richard Damon <(E-Mail Removed)> writes:

> On 2/1/13 5:41 AM, BartC wrote:
>> "Tim Rentsch" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> "BartC" <(E-Mail Removed)> writes:
>>>
>>>> "Tim Rentsch" <(E-Mail Removed)> wrote in message

>>
>>>>> The sizeof operator can be defined in a way that satisfies all
>>>>> the Standard's requirements but still allows this example to
>>>>> allocate only 100 nibbles.
>>>>
>>>> So what would be the value of sizeof(*x)? It can only really
>>>> be 1 or 0. [snip elaboration]
>>>
>>> Actually that isn't right. Using 'sizeof' on a non-standard
>>> datatype may behave in unexpected ways. Here's a hint: sizeof
>>> yields a result of type size_t; size_t is an (unsigned) integer
>>> type; integer types larger than character types may have padding
>>> bits. Can you fill in the rest?

>>
>> What, that extra information is stored in those padding bits? How is
>> that going to help?
>>
>> What bit-pattern could be returned by sizeof(*x) that would make
>> 100*sizeof(*x) yield 50 instead of 100?

>
> one simple solution is to have the sizeof operator not return a
> size_t for the nybble type, but some special type that does math
> "funny" to get the right value, for example a fixed point type
> with 1 fractional bit. When doing arithmetic on this type, the
> compiler can get the "right" answer, and also do the right thing
> when converting it to a standard type.


This is basically the idea, except the result isn't a new type
but is always a size_t. The key insight is that size_t can be
what is in effect a fixed-point type (with three fraction bits,
for example), but still satisfy the requirements for being an
integer type by designating the fraction bits as "padding bits".
Any combination of fraction bits other than all zeroes would be
a trap representation, allowing both standard behavior and
extended behavior in the same data type (ie, size_t).


> It would say that
>
> malloc(100 * sizeof(*x));
>
> and
>
> size_t size = sizeof(*x);
> malloc(100 * size);
>
> might return different sized allocations, but as long as the
> "nybble" type is given a name in the implementation reserved
> name space (like _Nybble), the the use of that name leads to
> "undefined behavior" by the standard which is then defiend by
> the implementation to be useful.


I would find discrepancies like this disquieting. And there are
other cases, eg, calloc(), where preserving the fractional
information in size_t could be important. It seems better to
have size_t be able to carry around the extra information,
since generally that should yield higher fidelity overall.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      02-04-2013
"BartC" <(E-Mail Removed)> writes:

> "Tim Rentsch" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> "BartC" <(E-Mail Removed)> writes:
>>
>>> "Tim Rentsch" <(E-Mail Removed)> wrote in message

>
>>>> The sizeof operator can be defined in a way that satisfies all
>>>> the Standard's requirements but still allows this example to
>>>> allocate only 100 nibbles.
>>>
>>> So what would be the value of sizeof(*x)? It can only really
>>> be 1 or 0. [snip elaboration]

>>
>> Actually that isn't right. Using 'sizeof' on a non-standard
>> datatype may behave in unexpected ways. Here's a hint: sizeof
>> yields a result of type size_t; size_t is an (unsigned) integer
>> type; integer types larger than character types may have padding
>> bits. Can you fill in the rest?

>
> What, that extra information is stored in those padding bits?
> How is that going to help?
>
> What bit-pattern could be returned by sizeof(*x) that would
> make 100*sizeof(*x) yield 50 instead of 100?


Richard Damon gives an idea along similar lines to what I was
thinking. My response to his posting has the details.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      02-04-2013
"BartC" <(E-Mail Removed)> writes:

> "Richard Damon" <(E-Mail Removed)> wrote in message
> news:z8lPs.378247$(E-Mail Removed)1.easynews.com...
>> On 2/2/13 1:34 PM, Shao Miller wrote:
>>
>>> Why bother calling them "implementation defined types" if the
>>> subjects' properties can deviate in dramatic ways from the
>>> usual, Standard-derived expectations for types?

>
>> Because for most usages they act just like regular types!
>> Note that the change in behavior that I described is not
>> "dramatically" different than for normal types, sizeof just
>> returns a type that can express fractions of a "byte" and
>> defines math the make this work as normal.

>
> That would need to include all conversions to int being rounded
> up, [snip elaboration].


Another possibility would be to trap any conversion that would
lose information. The implementation could provide various
rounding functions (guaranteed to succeed) for converting a
possibly non-integral size_t values. Alternatively, assigning a
size_t to a floating-point type could be used to extract the
fractional value safely, or provide rounding as desired. Needless
to say the actual code generated wouldn't necessarily have any
floating-point conversions in it, under the "as if" rule.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      02-04-2013
Ben Bacarisse <(E-Mail Removed)> writes:

> Richard Damon <(E-Mail Removed)> writes:
>
>> On 2/1/13 5:41 AM, BartC wrote:
>>> "Tim Rentsch" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> "BartC" <(E-Mail Removed)> writes:
>>>>
>>>>> "Tim Rentsch" <(E-Mail Removed)> wrote in message
>>>
>>>>>> The sizeof operator can be defined in a way that satisfies all
>>>>>> the Standard's requirements but still allows this example to
>>>>>> allocate only 100 nibbles.
>>>>>
>>>>> So what would be the value of sizeof(*x)? It can only really
>>>>> be 1 or 0. [snip elaboration]
>>>>
>>>> Actually that isn't right. Using 'sizeof' on a non-standard
>>>> datatype may behave in unexpected ways. Here's a hint: sizeof
>>>> yields a result of type size_t; size_t is an (unsigned) integer
>>>> type; integer types larger than character types may have padding
>>>> bits. Can you fill in the rest?
>>>
>>> What, that extra information is stored in those padding bits? How is
>>> that going to help?
>>>
>>> What bit-pattern could be returned by sizeof(*x) that would make
>>> 100*sizeof(*x) yield 50 instead of 100?

>>
>> one simple solution is to have the sizeof operator not return a size_t
>> for the nybble type, but some special type that does math "funny" to get
>> the right value, for example a fixed point type with 1 fractional bit.
>> When doing arithmetic on this type, the compiler can get the "right"
>> answer, and also do the right thing when converting it to a standard
>> type.

>
> I don't see how that can be permitted, at least without twisting
> things some more! The type of a sizeof expression is size_t (an
> unsigned integer type) and the result must be "an integer".


Here's another way of looking at it that may help. Using sizeof
is supposed to give the size of its operand in bytes. For a
four-bit data type, that should be a number strictly between
zero and one. Under 6.5 p5, such a circumstance qualifies as an
exceptional condition and therefore is undefined behavior.

> If (and this is a moot point) a value can have padding bits,
> the result could be a trap representation and then all bets are
> off and the implementation could do what it likes, but I don't
> think that's how values work.
>
>> It would say that
>>
>> malloc(100 * sizeof(*x));
>>
>> and
>>
>> size_t size = sizeof(*x);
>> malloc(100 * size);
>>
>> might return different sized allocations, but as long as the "nybble"
>> type is given a name in the implementation reserved name space (like
>> _Nybble), the the use of that name leads to "undefined behavior" by the
>> standard which is then defiend by the implementation to be useful.

>
> Are you imagining a sort of nuclear option for UB? I.e. that
> just using some non-standard type anywhere in a program makes
> all of it undefined? That's probably defensible, but it's not
> how most people like to talk about such things.


I was meaning to say something stronger, or at least how I think
of it is stronger. There is local undefined behavior at sizeof,
because of the exceptional condition, and another local undefined
behavior for a size_t with non-zero fraction bits. However, once
these two local undefined behaviors are defined, everything else
proceeds definedly (not counting things like pointers to the new
type, etc, which also have to be defined, but I think you get the
idea). The presence of undefined behavior is repaired purely
locally by defining the semantics for these two specific cases, and
otherwise has no effect (again assuming that other aspects have
been defined suitably).
 
Reply With Quote
 
Shao Miller
Guest
Posts: n/a
 
      02-04-2013
On 2/3/2013 20:12, Tim Rentsch wrote:
> Richard Damon <(E-Mail Removed)> writes:
>
>> On 2/1/13 5:41 AM, BartC wrote:
>>> "Tim Rentsch" <(E-Mail Removed)> wrote in message
>>> news:(E-Mail Removed)...
>>>> "BartC" <(E-Mail Removed)> writes:
>>>>
>>>>> "Tim Rentsch" <(E-Mail Removed)> wrote in message
>>>
>>>>>> The sizeof operator can be defined in a way that satisfies all
>>>>>> the Standard's requirements but still allows this example to
>>>>>> allocate only 100 nibbles.
>>>>>
>>>>> So what would be the value of sizeof(*x)? It can only really
>>>>> be 1 or 0. [snip elaboration]
>>>>
>>>> Actually that isn't right. Using 'sizeof' on a non-standard
>>>> datatype may behave in unexpected ways. Here's a hint: sizeof
>>>> yields a result of type size_t; size_t is an (unsigned) integer
>>>> type; integer types larger than character types may have padding
>>>> bits. Can you fill in the rest?
>>>
>>> What, that extra information is stored in those padding bits? How is
>>> that going to help?
>>>
>>> What bit-pattern could be returned by sizeof(*x) that would make
>>> 100*sizeof(*x) yield 50 instead of 100?

>>
>> one simple solution is to have the sizeof operator not return a
>> size_t for the nybble type, but some special type that does math
>> "funny" to get the right value, for example a fixed point type
>> with 1 fractional bit. When doing arithmetic on this type, the
>> compiler can get the "right" answer, and also do the right thing
>> when converting it to a standard type.

>
> This is basically the idea, except the result isn't a new type
> but is always a size_t. The key insight is that size_t can be
> what is in effect a fixed-point type (with three fraction bits,
> for example), but still satisfy the requirements for being an
> integer type by designating the fraction bits as "padding bits".
> Any combination of fraction bits other than all zeroes would be
> a trap representation, allowing both standard behavior and
> extended behavior in the same data type (ie, size_t).
>


Why bother calling it a "trap representation"? 'sizeof (_Nibble)'
doesn't involve any lvalues, so any usage of the result doesn't have to
do with trap representations until it's been stored somewhere and read
back[6.2.6.1p5]. If, instead, you say that the undefined behaviour is
invoked by '_Nibble' not being a complete object type but also not
contradicting the constraints of 6.5.3.4p1, then you don't _need_ any
trap representations nor even a 'size_t' result...

But if you want to call it a trap representation when you store the
undefined 'size_t' value because that object representation will have
padding bits and does "not represent a value of the object type", so be
it. It just seems a bit arbitrary... Why not call it "an invalid
value", instead?

--
- Shao Miller
--
"Thank you for the kind words; those are the kind of words I like to hear.

Cheerily," -- Richard Harter
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
pointer to an array vs pointer to pointer subramanian100in@yahoo.com, India C Programming 5 09-23-2011 10:28 AM
Pointer to pointer or reference to pointer A C++ 7 07-05-2011 07:49 PM
Pointer to pointer Vs References to Pointer bansalvikrant@gmail.com C++ 4 07-02-2009 10:20 AM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
Pointer-to-pointer-to-pointer question masood.iqbal@lycos.com C Programming 10 02-04-2005 02:57 AM



Advertisments