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

 
 
BartC
Guest
Posts: n/a
 
      02-02-2013


"Shao Miller" <(E-Mail Removed)> wrote in message
news:kejee8$5mi$(E-Mail Removed)...
> On 2/2/2013 04:39, Robert Wessel wrote:
>> On Sat, 2 Feb 2013 00:01:13 -0800 (PST), Robert Miles
>> <(E-Mail Removed)> wrote:
>>
>>> On Friday, February 1, 2013 6:16:46 PM UTC-6, Shao Miller wrote:
>>>> On 2/1/2013 19:00, glen herrmannsfeldt wrote:
>>>>
>>>>> How about sizeof(2**x) vs. (sizeof 2 * * x)?
>>>>
>>>> ... I can
>>>> imagine some language that has '**' as an exponent operator...?
>>>
>>> Fortran does. I haven't checked if there are any more.

>>
>>
>> Ada, Cobol, Haskell, Perl, PL/I, Python, Rexx, Ruby...
>>

>
> Off-topic, but: Do any of these care about '2 * * x' versus '2**x'?


In most of them, *x doesn't have the meaning it has in C. So it would be
syntax error. But I don't think ** for exponentiation is that universal
either.

--
Bartc

 
Reply With Quote
 
 
 
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      02-02-2013
Keith Thompson <(E-Mail Removed)> wrote:
> glen herrmannsfeldt <(E-Mail Removed)> writes:
> [...]
>> PL/I has no reserved words, but requires space between adjacent keywords
>> and variables. There are some special exceptions. I believe like C,
>> both GOTO and GO TO are allowed in free-form Fortran and PL/I.

> [...]


> Like C? C allows `goto`; `go to` is a syntax error.


Oops. I haven't written a goto in C for a long time,
and then, even in the other languages, I wrote it goto.

-- glen
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-02-2013
glen herrmannsfeldt <(E-Mail Removed)> writes:
> Robert Miles <(E-Mail Removed)> wrote:
>> On Friday, February 1, 2013 6:16:46 PM UTC-6, Shao Miller wrote:
>>> On 2/1/2013 19:00, glen herrmannsfeldt wrote:
>>> > How about sizeof(2**x) vs. (sizeof 2 * * x)?


The unary sizeof operator binds more tightly than multiplication, so
the first yields the size of `2 * *x`, and the second is equivalent
to `(sizeof 2) * (*x)`.

It's not usually necessary to use parentheses with sizeof applied to an
expression, but as with any other operator you sometimes need
parentheses to deal with precedence.

>>> I'm so conditioned to C that I don't see the difference, but I can
>>> imagine some language that has '**' as an exponent operator...?

>
>> Fortran does. I haven't checked if there are any more.

>
> PL/I inherited it from Fortran, gawk (GNU awk) has it in
> addition to the ^ operator.
>
> Now, why doesn't C have one?


x**y and x^y are already well-defined expressions in C
(multiplication by a dereference and exclusive-or, respectively).

I suppose ^^ could have been used (since you can't have a
short-circuit xor). But the systems programming domain for which
C was originally designed didn't have much use for exponentiation.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
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"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      02-02-2013
"BartC" <(E-Mail Removed)> writes:
> "Shao Miller" <(E-Mail Removed)> wrote in message
> news:kejee8$5mi$(E-Mail Removed)...
>> On 2/2/2013 04:39, Robert Wessel wrote:
>>> On Sat, 2 Feb 2013 00:01:13 -0800 (PST), Robert Miles
>>> <(E-Mail Removed)> wrote:
>>>
>>>> On Friday, February 1, 2013 6:16:46 PM UTC-6, Shao Miller wrote:
>>>>> On 2/1/2013 19:00, glen herrmannsfeldt wrote:
>>>>>
>>>>>> How about sizeof(2**x) vs. (sizeof 2 * * x)?
>>>>>
>>>>> ... I can
>>>>> imagine some language that has '**' as an exponent operator...?
>>>>
>>>> Fortran does. I haven't checked if there are any more.
>>>
>>> Ada, Cobol, Haskell, Perl, PL/I, Python, Rexx, Ruby...

>>
>> Off-topic, but: Do any of these care about '2 * * x' versus '2**x'?

>
> In most of them, *x doesn't have the meaning it has in C. So it would be
> syntax error. But I don't think ** for exponentiation is that universal
> either.


It's not universal, but I think most languages that have an
exponentiation operator spell it "**".

C *could* have had ** as an exponentation operator from the
beginning. Then multiplication by a dereference would have to
be written with a space or parentheses (`x * *y` or `x*(*y)`) --
just as we have to do for `x - -y`.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
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"
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      02-03-2013
Keith Thompson <(E-Mail Removed)> wrote:

(snip)
>>> Off-topic, but: Do any of these care about '2 * * x' versus '2**x'?


>> In most of them, *x doesn't have the meaning it has in C. So it would be
>> syntax error. But I don't think ** for exponentiation is that universal
>> either.


> It's not universal, but I think most languages that have an
> exponentiation operator spell it "**".


Well, when BASIC was new ASCII had an up-arrow character, later
replaced by tilde. EBCDIC has no up-arror or tilde, so it wasn't
likely that any IBM language would use them.

I normally don't use ^ for exponentiation in posts, as it seems
too much like the XOR operator.

> C *could* have had ** as an exponentation operator from the
> beginning. Then multiplication by a dereference would have to
> be written with a space or parentheses (`x * *y` or `x*(*y)`) --
> just as we have to do for `x - -y`.


Yes, but now it is too late for that one.

Which combination of characters doesn't currently have any meaning.
My thought so far is !*! which I believe isn't used. You can't
apply unary * to the result from !, and there is no postfix !
that could come before binary *.

I suppose ^^ could also work, though I keep hoping for a logical
(not bitwise) XOR operator.

-- glen

 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      02-03-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.


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".

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.

--
Ben.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      02-03-2013
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".
--
James Kuyper
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      02-03-2013
On 02/02/2013 10:50 PM, Richard Damon wrote:
> 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? Quite seriously, if these subjects are defined
>> only by the implementation and those definitions include references to
>> _some_ pieces of the Standard (including _some_ pieces about "types"),
>> doesn't it seem more natural to call these subjects by some other name
>> than to call them "types" at all? Using "implementation defined type"
>> implies that somehow it's a "type", but the implementation has stripped
>> some of what it means to be a "type"; this doesn't seem to be a
>> constructive approach, but a destructive one. (Where "constructive" is
>> not meant to be confused with "useful" or "enjoyable".)
>>

>
> 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.
>
> Remember, the original question was how to make an implementation that
> allowed for a type that was smaller than char. This method keeps totally
> conforming behavior for programs that do not use this feature, and
> mostly the expected result when using the feature.
>
> Yes, it would be possible based on this logic to make an implementation
> that did something totally weird when using a type like _Nybble, but
> then, based on the standard that IS allowed. It should only be done with
> an implementation that has provided a useful meaning to this form of
> undefined behavior.


Explicit use of _Nybble can have arbitrarily weird consequences, because
it's a reserved name, so your code can't define it itself, and because
most uses of an identifier that has no definition are constraint
violations. That's not the case which justifies bothering to explicitly
allow for extended integer types.

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.
--
James Kuyper
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      02-03-2013
"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, so that
99*sizeof(nybble) gives 50 rather than 49. But there would still be plenty
of dodgy areas:

nybble A[39];
int x,y;

x=sizeof(A); // 20
y=sizeof(A[0]); // 1

Now, x/y will yield 20 instead of 39.

On the other hand, a new bitsizeof() version would give 156/4 or 39 as
expected (and would work for other types too, and would benefit from being a
64-bit result rather than 32-bit). An explicit conversion is needed to give
a rounded-up byte size (eg. bitstobytes()).

--
Bartc

 
Reply With Quote
 
Roberto Waltman
Guest
Posts: n/a
 
      02-03-2013
Bart van Ingen Schenau wrote:
>The 80286 processor supports different sized pointers for data and
>functions, and either of them could be larger than an int.


So did the humble 8088/8086 in the "compact" and "medium" memory
models.
--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]
 
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