clipka <ano### [at] anonymousorg> wrote:
> Okay, I guess everyone who has ever touched C or C++ has at least heard
> rumors of this: The standard data types, such as "int", "short int" or
> "long int", are anything but. For instance, a "long int" will typically
> be 32 bits wide on a 32 bit machine, but 64 bits on a 64 bit machine -
> unless you're running Windows, in which case it's still 32 bit. And
> "int" will typically be 32 bits wide - unless you're running on a 64 bit
> Cray machine, in which case it will be a whopping 64 bit as well. Or on
> an embedded computer, in which case it may be as small as 16 bits. Hell,
> there are even systems out there where the most fundamental data type,
> "char", is not 8 but 16 bits wide!
>
char, according to wikipedia, is supposed to be exactly one byte.  Byte is
defined, in turn, to be large enough to carry any member of the basic execution
character set and UTF-8 code units. This implies that it must be at least 8 bits
wide.

POSIX requires it to be exactly 8 bits, but the exact number of bits can be
checked with CHAR_BIT from limits.h (or <climits>). It should be 8 bits on most
systems.

Regards,
A.D.B.

Post a reply to this message

I worked on such platform, not a PDP-11 (I am too young for that) but an
awkward embedded DSP chip:

http://roker.spamt.net/c++/datatypes_c55x.png

It was very annoying to do C++ on that, e.g. file I/O and std::string
didn't work as I expected. :-(

Lars R.

Post a reply to this message

Am 24.08.2015 um 12:28 schrieb Lars Rohwedder:
> I worked on such platform, not a PDP-11 (I am too young for that) but an
> awkward embedded DSP chip:
> 
> http://roker.spamt.net/c++/datatypes_c55x.png
> 
> It was very annoying to do C++ on that, e.g. file I/O and std::string
> didn't work as I expected. :-(

Been there, done that. I once had to write a portable driver for some
proprietary communications protocol to run on a set of embedded systems,
and on one of the target platforms the message data somehow kept getting
misaligned in the buffers. The first hint that put me on the right track
was that this weirdo also had the baffling ability to store pointers in
char-wide variables, while providing 64k of RAM...

That thing was some obscure microcontroller with a built-in Bluetooth
stack, and yes - apparently some DSP capabilities as well. Can't
remember the name of the controller or the manufacturer though.

Post a reply to this message

On 24/08/2015 11:28 AM, Lars Rohwedder wrote:
> I worked on such platform, not a PDP-11 (I am too young for that) but an
> awkward embedded DSP chip:
>
> http://roker.spamt.net/c++/datatypes_c55x.png
>
> It was very annoying to do C++ on that, e.g. file I/O and std::string
> didn't work as I expected. :-(

I saw an FAQ page somewhere that had examples of systems where the size 
of a pointer really does change depending on what it points to.

I imagine trying to do C on a Harvard architecture machine would be 
"interesting" for exactly this reason. (And I gather that's quite 
popular in DSP chips...)

Post a reply to this message

Am 24.08.2015 um 19:44 schrieb Orchid Win7 v1:
> On 24/08/2015 11:28 AM, Lars Rohwedder wrote:
>> I worked on such platform, not a PDP-11 (I am too young for that) but an
>> awkward embedded DSP chip:
>>
>> http://roker.spamt.net/c++/datatypes_c55x.png
>>
>> It was very annoying to do C++ on that, e.g. file I/O and std::string
>> didn't work as I expected. :-(
> 
> I saw an FAQ page somewhere that had examples of systems where the size
> of a pointer really does change depending on what it points to.
> 
> I imagine trying to do C on a Harvard architecture machine would be
> "interesting" for exactly this reason. (And I gather that's quite
> popular in DSP chips...)

Get a MCS-51 development environment and see for yourself...

It might also be interesting to see if and how the MCS-51 C compiler
supports the bit-addressable portion of data memory, external data
memory (which has a 16-bit address space separate from both core data
memory and instruction memory), and so forth...

Post a reply to this message

> I saw an FAQ page somewhere that had examples of systems where the size
> of a pointer really does change depending on what it points to.
> 
> I imagine trying to do C on a Harvard architecture machine would be
> "interesting" for exactly this reason. (And I gather that's quite
> popular in DSP chips...)

You don't need an exotic DSP platform, just use C or C++ on DOS. There
you have different "memory models" (TINY, SMALL, MEDIUM, COMPACT, LARGE,
HUGE), which result in different pointer sizes for code and/or data and
the way pointer arithmetics work at all.

In the SMALL model object and function pointers are incomparable. They
both are 16 bit but point to completely independent 64K memory segments.
In the MEDIUM and COMPACT models the size of object pointers and
function pointers differ (one is 16 the other is 32 bit, in the other
model the sizes are reverted)

I'd like to see that every C programmer has to learn C on such a
platform so they never ever learn to du non-ISO-C-compliant pointer
conversions. But I think it is too late for that. ;-(

Lars R.

Post a reply to this message

On 28/08/2015 02:37 PM, Lars Rohwedder wrote:
>> I saw an FAQ page somewhere that had examples of systems where the size
>> of a pointer really does change depending on what it points to.
>>
>> I imagine trying to do C on a Harvard architecture machine would be
>> "interesting" for exactly this reason. (And I gather that's quite
>> popular in DSP chips...)
>
> You don't need an exotic DSP platform, just use C or C++ on DOS. There
> you have different "memory models" (TINY, SMALL, MEDIUM, COMPACT, LARGE,
> HUGE), which result in different pointer sizes for code and/or data and
> the way pointer arithmetics work at all.

Oh, hello LPCWSTR, I didn't see you there... :-}

(In other words: Yes, 30 years later, the Win32 API still has these 
obsolete type designations in it. Oh goodie.)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> One more thing that bugs me is that standards /still/ don't provide a
> straightforward way to detect the byte ordering of the standard integer
> data types (unless I missed some recent news).

You can detect it at runtime, but it's impossible to detect it at
compile time. (Yes, I have researched it. It's just not possible.)

(Ok, I'm not 100% certain that the runtime trick is 100% standard
kosher, but it works in all relevant modern hardware.)

-- 
                                                          - Warp

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> And yet, this is one of the few programming languages on Earth which 
> doesn't guarantee how many bits are in a particular data type, and 
> provides no way to specify what you actually want.

C doesn't want to force the compiler to generate inefficient code
behind the scenes in order to support some particular type. For example,
if the target hardware doesn't support, let's say, 32-bit integers,
C doesn't want to force the compiler to generate inefficient code
that handles 32-bit integers on that system. It allows the compiler to
refuse support.

In principle C tries to be as portable as possible in the sense that it
makes no assumptions about the target hardware. It doesn't even assume
that a byte is 8 bits, and it doesn't make any assumptions about the
bitness of the target platform. (I think that in principle it doesn't
even assume that integral variables use 2's complement representation.)

The only guarantee that it gives is that sizeof(char) <= sizeof(short)
<= sizeof(int) <= sizeof(long). (There might have been a guarantee that
sizeof(char) < sizeof(long), but I don't remember if that's true.)

-- 
                                                          - Warp

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> I saw an FAQ page somewhere that had examples of systems where the size 
> of a pointer really does change depending on what it points to.

Many C programmers assume that you can convert any pointer to void*
and back, as they assume that all pointers have the same size.

In C++ you can't always make that assumption. More precisely, a pointer
to a virtual function is (most probably) larger than a regular function
pointer. A pointer-to-virtual-function cannot be converted to void* and
back without malfunction.

-- 
                                                          - Warp

Post a reply to this message