Q:

How can I detect endianness on a system where all primitive integer sizes are the same? 

(This question came out of explaining the details of CHAR_BIT, sizeof, and endianness to someone yesterday.  It's entirely hypothetical.) 
Let's say I'm on a platform where CHAR_BIT is 32, so sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long).  I believe this is still a standards-conformant environment. 
The usual way to detect endianness at runtime (because there is no reliable way to do it at compile time) is to make a union { int i, char c[sizeof(int)] } x; x.i = 1 and see whether x.c[0] or x.c[sizeof(int)-1] got set. 
But that doesn't work on this platform, as I end up with a char[1]. 
Is there a way to detect whether such a platform is big-endian or little-endian, at runtime?  Obviously it doesn't matter inside this hypothetical system, but one can imagine it is writing to a file, or some kind of memory-mapped area, which another machine reads and reconstructs it according to its (saner) memory model. 

A:

Hypothetically, in an environment where all data types are of the same size, there is no endianess. 
I can see three possibilities for you:

If the limitation is only given by C compiler and technically the platform has some smaller data types, you can use assembler to detect endianess. 
If the platform supports double data type, you can use it to detect endianess, because it is always 64 bits wide. 
Also you can write data to file, as you suggested, and then read back.  Simply write two chars (file in binary mode), move file pointer to position 1 and read back a char. 

A:

The concept of endianness only makes sense for scalar types represented by multiple bytes.  By definition, a char is single-byte, so any integer type having the same size as char has no endianness. 
Also keep in mind that endianness can be different for different types: For example, the PDP-11 is a little-endian 16-bit architecture, and 32-bit integers are built from two 16-bit little-endian values, ending up mixed endian.