An implementation where sizeof(short int) does not divide sizeof(int)

[Spiros Bousbouras]

Do you have an example of an implementation where
sizeof(short int) does not divide sizeof(int) or
sizeof(int) does not divide sizeof(long int) or
sizeof(long int) does not divide sizeof(long long int) ?

Same question for the corresponding unsigned types.

 

[christian.bau]

Do you have an example of an implementation where
sizeof(short int) does not divide sizeof(int) or
sizeof(int) does not divide sizeof(long int) or
sizeof(long int) does not divide sizeof(long long int) ?

Same question for the corresponding unsigned types.

What about...

An implementation where long has 40 value bits... (TI DSPs)
An implementation where sizeof (long double) == 10 or == 12... (IEEE
754 Standard)

 

[David T. Ashley]

Do you have an example of an implementation where
sizeof(short int) does not divide sizeof(int) or
sizeof(int) does not divide sizeof(long int) or
sizeof(long int) does not divide sizeof(long long int) ?

Same question for the corresponding unsigned types.

Interesting question, but probably irrelevant to actual programming.

It is an accident of computer evolution that the relationships you are
seeking an exception to exist. I have no idea why in the world one can't
easily find a computer with 40-bit integers or 48-bit integers, for example.

Counteroffer: can you show me a poor 'C' implementation that will fail if
the relationships you mention don't hold? I've never seen that, either.

 

[Peter Nilsson]

Do you have an example of an implementation where
sizeof(short int) does not divide sizeof(int) or
sizeof(int) does not divide sizeof(long int) or
sizeof(long int) does not divide sizeof(long long int) ?

No, but I have used two where sizeof(int) does not divide
sizeof(double) [4 and 10 respectively.]

Same question for the corresponding unsigned types.

Yes, it is the same question. The size of a signed integer
is necessarily the same as the size of the corresponding
unsigned type.

But why are you concerned about size? It's a common
misconception that size is more important than value.
[Read that any way you want.] Another popular
misconception is that _where_ an object is located is
more important than _when_ it exists.

 

[user923005]

Do you have an example of an implementation where
sizeof(short int) does not divide sizeof(int) or
sizeof(int) does not divide sizeof(long int) or
sizeof(long int) does not divide sizeof(long long int) ?

Same question for the corresponding unsigned types.

How about where sizeof int is not evenly divisible by sizeof char?
CDC Cyber UTexas C compiler

60 bits is not divisible by 8. They stored characters two words at a
time though, so you had 120 bits, which is divisible by 8.

IIRC.

 

[Ben Pfaff]

How about where sizeof int is not evenly divisible by sizeof char?
CDC Cyber UTexas C compiler

I don't think non-ANSI implementations are on-topic here.

 

[Dik T. Winter]

>
> Interesting question, but probably irrelevant to actual programming.

Indeed, not very interesting. But something like that happened on
the Cray-1. I disremember whether a short was 24 or 32 bits. But
there was a compiler flag that said that ints were either 48 or 64
bits, but the size of a short was fixed. I think the base mode was
shorts of 24 bits and ints of 48 bits and the extravaganza mode was
shorts of 24 bits and ints of 64 bits.

 

[Rudolf]

How about where sizeof int is not evenly divisible by sizeof char?
CDC Cyber UTexas C compiler

sizeof char is 1. How is anything not evenly divisible by one?

 

[Old Wolf]

How about where sizeof int is not evenly divisible by sizeof char?

sizeof(char) is always 1, so this is not possible.

CDC Cyber UTexas C compiler

60 bits is not divisible by 8. They stored characters two words at a
time though, so you had 120 bits, which is divisible by 8.

"sizeof" gives the size in bytes, not in bits.

 

[Dik T. Winter]

>
> How about where sizeof int is not evenly divisible by sizeof char?
> CDC Cyber UTexas C compiler

That would violate the standard. sizeof is expressed as an integral
unit, where sizeof char == 1. And that was already true in K&R.

> 60 bits is not divisible by 8. They stored characters two words at a
> time though, so you had 120 bits, which is divisible by 8.

That is possible (but gives problems with floats that are also 60 bits).
But on those machines it is much more reasonable to have 48 bit ints
with the remaining 16 bits (possible) garbage. But integer arithmetic
on those machines had quite a few strange points. That is, I could
easily construct examples where:
(a + a) * 2 != a + a + a + a
in integer arithmetic, even when a < 2**48.

 

[user923005]

That would violate the standard. sizeof is expressed as an integral
unit, where sizeof char == 1. And that was already true in K&R.

I wonder if it was written between 1969 (~ eariliest origins of C) and
1978 (K&R I published), in which case K&R I does not apply.

Some of the C compilers I used around 1984-1986 were at extreme
opposition. As I recall, Lattice C, Manx C, Microsoft C (and some
other which I forget) were so dissimilar that it was often easier to
write separate source files instead of using #ifdef
COMPILER_SPECIFIC_FLAG #endif around the compiler specific stuff.

 

[Dik T. Winter]

>
> I wonder if it was written between 1969 (~ eariliest origins of C) and
> 1978 (K&R I published), in which case K&R I does not apply.

We shifted to a CDC Cyber around 1976, or perhaps earlier. The first time
I even heard about the UTexas C compiler was about 10 years later. That was
when the computing centre asked us whether it should be available as a
standard compiler kit, I do not think it was much older. My answer to
the question was: *no*. The reason was that it was not suitable for
interactive work (the compiler required too much memory). And it never
was made available. BTW, at that time we had an Algol 68 compiler that
did nearly everything of Algol 68 in interactive sessions. But as far
as that C compiler was concerned, that is just what I did look at. And
we had already quite a few PDP's running, *with* C compilers, so C on
the mainframe without the possibility to do it interactive was out of
the question.

> As I recall, Lattice C, Manx C, Microsoft C (and some
> other which I forget) were so dissimilar that it was often easier to
> write separate source files instead of using #ifdef
> COMPILER_SPECIFIC_FLAG #endif around the compiler specific stuff.

Possibly true. They all implemented dialects of C, and also had all
their idiosyncrastic bugs. I have still some source files around
really littered with #ifdef and #endif statements. But, they still
do compile. (That is a program I ported to about 40 different
compiler/OS combos.)

 

[Ben Pfaff]

We shifted to a CDC Cyber around 1976, or perhaps earlier. The first time
I even heard about the UTexas C compiler was about 10 years later. That was
when the computing centre asked us whether it should be available as a
standard compiler kit, I do not think it was much older. My answer to
the question was: *no*. The reason was that it was not suitable for
interactive work (the compiler required too much memory).
[...]

Out of curiosity: how much memory was considered too much for a
compiler to consume on that machine at the time?

 

[CBFalconer]

How about where sizeof int is not evenly divisible by sizeof char?
CDC Cyber UTexas C compiler

Impossible on the face of it. Anything is divisible by one.

60 bits is not divisible by 8. They stored characters two words at a
time though, so you had 120 bits, which is divisible by 8.

I suspect you are confusing CHAR_BIT with sizeof char.

--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

 

[user923005]

I don't think non-ANSI implementations are on-topic here.

Perhaps, but if that is the case then what is topical has drifted. For
example:

"From: Lawrence Kirby - view profile
Date: Wed, Jul 29 1998 11:00 pm
Email: (e-mail address removed) (Lawrence Kirby)
Groups: comp.lang.c

....

The topic here is "C". Not ANSI C just C.

Lets be perfectly clear about this. comp.lang.c is a newsgroup for
discussinbg the C programming language. The C programming language
is currently defined by the ISO 9899-1990 standard (plus a few minor
amendments). That hasn't always been the case and it is reasonable to
discuss historical forms of the language (such as "K&R C") here as long

as that is clear in the article."

{remainder snipped}

 

[user923005]

Ben Pfaff wrote:
[snip]

Out of curiosity: how much memory was considered too much for a
compiler to consume on that machine at the time?

{not related to the CDC Cyber, but of the same period...}
In 1976, I worked on an IBM 360 at Patrick AFB in Florida.
Any job that consumed more than 200K required special permission,
granted by an officer.
I remember well, because I had to run a job that required 276K at least
once every day.

 

[Ben Pfaff]

I don't think non-ANSI implementations are on-topic here.

Perhaps, but if that is the case then what is topical has
drifted. [...]

Indeed. Let me state my objection better, then:

The CDC Cyber UTexas C compiler must not have been an ANSI C
compiler, because that situation can't happen in ANSI C. I
suspect that the OP is looking for current compilers, not ancient
and obsolete ones.

(It's a fascinating fact in any case.)

 

[user923005]

Spiros Bousbouras wrote:
Do you have an example of an implementation where
sizeof(short int) does not divide sizeof(int) or
sizeof(int) does not divide sizeof(long int) or
sizeof(long int) does not divide sizeof(long long int) ?

Same question for the corresponding unsigned types.

How about where sizeof int is not evenly divisible by sizeof char?
CDC Cyber UTexas C compiler

I don't think non-ANSI implementations are on-topic here.

Perhaps, but if that is the case then what is topical has
drifted. [...]

Indeed. Let me state my objection better, then:

The CDC Cyber UTexas C compiler must not have been an ANSI C
compiler, because that situation can't happen in ANSI C. I
suspect that the OP is looking for current compilers, not ancient
and obsolete ones.

I might be misremembering in any case, because we never actually got it
to work and just stuck with FORTRAN anyway. The FORTRAN compiler also
had really weird operations to pack and unpack character strings from
words. I doubt that the FORTRAN compiler for that machine met F77
standards.

 

[user923005]

Impossible on the face of it. Anything is divisible by one.

Hard to argue with that.

I suspect you are confusing CHAR_BIT with sizeof char.

Ummm... What he said.

 

[Keith Thompson]

How about where sizeof int is not evenly divisible by sizeof char?
CDC Cyber UTexas C compiler

60 bits is not divisible by 8. They stored characters two words at a
time though, so you had 120 bits, which is divisible by 8.

sizeof(int) is divisible by sizeof(char) in any conforming C
implementation; sizeof(char) is 1 by definition.

Implementing C on a system with 8-bit characters and 60-bit integers
would be, um, interesting.