«

On 2/1/2013 19:24, Shao Miller wrote:
> On 2/1/2013 19:16, Shao Miller wrote:
>> On 2/1/2013 19:00, glen herrmannsfeldt wrote:
>>>
>>> How about sizeof(2**x) vs. (sizeof 2 * * x)?
>>>
>>
>> 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...?
>>
>
> Ooh, heheh. I missed your point of the parentheses. My mistake. Don't
> do that!
>

(For some reason I thought you were emphasizing the spacing differences
of '**' and '* *' and I didn't read the parentheses at all. :S )

But I don't quite understand what the latter's "intuitive" expectation
might be... That 'sizeof' would process everything until the closing
bracket because an opener came before it? If so, could the same
argument be made for:

*(x + 2)

versus:

(* x + 2)

? Is the problem that 'sizeof' requires some separation from its
operand, unlike '*'?

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

Cheerily," -- Richard Harter

Tim Rentsch <> writes:

> "BartC" <> writes:
>
>> "Tim Rentsch" <> wrote in message
>> news:...
>>> glen herrmannsfeldt <> 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.

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

--
Ben.

Shao Miller <> writes:
> On 2/1/2013 05:41, BartC wrote:
>> What bit-pattern could be returned by sizeof(*x) that would make
>> 100*sizeof(*x) yield 50 instead of 100?
>
> The 'sizeof' operator only requires parentheses when used with a
> type-name. Your example clearly does not use a type-name, so it could
> be: 100 * sizeof *x

true, but there's nothing wrong with writing 100*sizeof(*x).

--
Keith Thompson (The_Other_Keith) kst- <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"

On 1/31/2013 17:16, Tim Rentsch wrote:
> glen herrmannsfeldt <> writes:
>
>>> [snip]
>>
>> C requires char to be at least 8 bits, but it can be more. All
>> other types have to be multiples (including 1) of the size of
>> char.
>>
>> That seems to prohibit a four bit type, which would be especially
>> useful on a four bit processor.
>
> 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.
>

On 1/7/2013 01:30, Tim Rentsch wrote:
> You've made a common mistake here. You start with a statement
> about something you think an implementation might benefit from
> doing, and use that to draw a conclusion about what the Standard
> allows. The reasoning process needs to go the other direction:
> start with what the Standard allows (or more importantly in this
> case, what it effectively prohibits), and show that a conforming
> implementation could act as suggested and still not violate any
> requirements. The reasoning given above proves nothing at all.
>

Interesting... So in this particular case, the Standard's definitions
that we might expect to apply to all object types needn't apply, because
these rules only apply to Standard-defined types. So actually, perhaps
we don't need to bother calling these subjects "types" at all, so as not
to confuse them with the usual Standard notions. In that case

>> That seems to prohibit a four bit type, which would be especially
>> useful on a four bit processor.

appears to be agreeable. We could call them "extendo-types," just like
"nobjects," else-thread. Interesting...

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

Cheerily," -- Richard Harter

On Wednesday, January 30, 2013 2:28:14 AM UTC-6, Noob wrote:
> Robert Miles wrote:
>
> > Server systems now use a similar idea of using more than one word to
> > hold an address - some 32-bit servers use 2 32-bit words to hold an
> > address, and can therefore reach more than tha 4 GB of memory they
> > could use if they only used one 32-bit word.
>
> Which (computer) architecture do you have in mind?

PC type with x86, with an extra register to hold part of addresses.

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

On Thu, 31 Jan 2013 10:04:42 +0100, Rosario1903 wrote:

> On Wed, 30 Jan 2013 14:44:44 -0600, Robert Wessel
> <> wrote:
>
>>On Wed, 30 Jan 2013 10:12:07 -0800, Keith Thompson <kst->
>>wrote:
>>
>>>Robert Miles <> writes:
>
>>Non-char, non-void pointers don't need to be able to address any byte in
>>the data space, just each possible instance of whatever object they're
>>pointing at. Which is why we've seen some word addressed machines with
>>void/char pointers that are larger than other types of data pointers.
>>
>>Although one would assume that a 4-bit CPU is not going to have any
>>significant alignment requirements.
>
> even if the C languge say other
> i think pointer is one unsigned number of fixed size

That might be what you think, but history does not agree with you.
The 80286 processor supports different sized pointers for data and
functions, and either of them could be larger than an int.
int == 16 bits
void* == 16 or 20 bits (effective size; depending on the memory model)
void(*)() == 16 or 20 bits (effective size; depending on the memory model)
There were different memory models for each combination of pointer sizes.

> all that goes
> different from above produce errors or wrong programming behaviours or
> difficult code to understand

That has not been my experience. On the contrary, failing to understand
that pointers and integers are different, unrelated things is what causes
wrong programming habits and difficult to port code.

Bart v Ingen Schenau

Robert Wessel <> wrote:
> On Sat, 2 Feb 2013 09:22:20 +0000 (UTC), Bart van Ingen Schenau

(snip)
>>That might be what you think, but history does not agree with you.
>>The 80286 processor supports different sized pointers for data and
>>functions, and either of them could be larger than an int.
>>int == 16 bits
>>void* == 16 or 20 bits (effective size; depending on the memory model)
>>void(*)() == 16 or 20 bits (effective size; depending on the memory model)
>>There were different memory models for each combination of pointer sizes.

> While x86 far pointers are effectively about 20 bits long in real mode
> (while the pointer was physically 32 bits in size), in 16-bit
> protected mode, far pointers are closer to 30 bits in effective size.

I guess 29 is close to 30.

The segment selector has two bits of protection ring and the
global/local bit.

There is one 29 bit global address space, and a 29 bit space
for each task.

Starting with the 80386, the segment selectors work the same
way, but with a 32 bit offset, so 45 bits each. Would have been
more useful without a 32 bit MMU in between.

-- glen

Robert Miles <> 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'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?

-- glen

"glen herrmannsfeldt" <> wrote in message
news:keivin$65f$...
> Robert Miles <> 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'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?

Because all the best operator symbols have been used up; which symbol would
be used instead?

--
Bartc