Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #4785

Re: gcc-4.x.x and endianess

Show all headers | View raw

On 2014-09-15, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Mon, 15 Sep 2014 11:51:29 +0100, in comp.programming you wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 
>>> [ which also presumes that the language does not provide means to expose
>>> endianness through legal operations defined on the type. E.g. whatever you
>>> write with the type the result would not depend on the endianness. In C you
>>> have shifts and type casts which expose endinness.
>> 
>> That's a common misconception about shifts in C.
>
> Shifting signed integers.

Shifting integers in C has nothing to do with endianness.
Firstly, it has some well-defined portable behaviors, which are
all arithmetically defined. For instance if we shift a signed int
value like 42 to the left by a position (42 << 1), this is
defined by the ISO standard as producing 84, because well-defined (not out of
range) shifts are multiplications or divisions by a power of two.
It produces 82 regardless of how many bytes make up that int,
or how it is stored in memory into those bytes.

Shifts expose certain inherent nonportabilities of the integral types,
but these are not tied to endiannness. They are tied to the representation,
and range. Representation and range are abstract properties defined
in terms of a field of bits, independently how those bits are stored
in memory.

>> It is also a common
>> misconception that casts expose endianness.
>
> Of course they do, especially casts like *(T*) &x or ((A*) &x) [i]

Type punning does provide the tool for revealing endiannness. If we are on a
platform where the type int consists of two or more bytes and does not contain
padding bits (the majority of them), we can take an object of type int in which
the value 1 is stored, and see which byte has a nonzero bit.  If it is the
lowest-addressed byte, for instance, then it's probably a little-endian
platform.

>
>> Obviously C *can* reveal
>> the representation of its types (though pointers and unions for
>> example) but casts are defined as value conversions in C.
>
> The point exactly is that it "can". In a properly designed language it 

Please stop using words like "properly", when referring to you personal
preferences.

> should be "cannot", unless explicitly demanded by the programmer involving 
> some heavy syntax clearly distinguishable from daily used constructs.

Heavy syntax is naive; because if a smart programmer is confronted with
cumbersome syntax, he or she can easily add a component to the toolchain
to generate that syntax from a simpler syntax: a macro preprocessor, or
a full blown compiler for a light-weight notation into the cumbersome
language.

You might think that the heavy syntax at least impede the B grade programmers,
but that is not true: the tool can be well documented and made widely
available.

(Usually the result, though, is that the cumbersome language is simply eschewed.
Programmers, by and large, are a pragmatic lot: when "hello world" takes 100
lines in some language, they instinctively avoid it.)

In C, you will not expose endianness unless you use specific syntax, like casts
or unions. The syntax isn't "heavy", but it's not invisible.  It's light enough
that programmers don't automatically run for the macro preprocessor to hide it.

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-13 21:41 -0400
  Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-14 09:14 +0200
    Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-14 15:31 -0400
      Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-14 21:38 +0200
        Re: gcc-4.x.x and endianess Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-09-14 22:05 +0100
          Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-15 09:40 +0200
            Re: gcc-4.x.x and endianess Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-09-15 11:51 +0100
              Re: gcc-4.x.x and endianess "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-15 13:49 +0100
              Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-15 17:16 +0200
                Re: gcc-4.x.x and endianess Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-09-15 22:23 +0100
                Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-16 10:44 +0200
                Re: gcc-4.x.x and endianess Kaz Kylheku <kaz@kylheku.com> - 2014-09-16 00:18 +0000
          Re: gcc-4.x.x and endianess BGB <cr88192@hotmail.com> - 2014-09-15 06:18 -0500
        Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-15 14:23 -0400
          Re: gcc-4.x.x and endianess "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-09-15 21:08 +0200
            Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-15 19:32 -0400
          Re: gcc-4.x.x and endianess Richard Heathfield <invalid@see.sig.invalid> - 2014-09-15 21:07 +0100
            Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-15 21:48 -0400
  Re: gcc-4.x.x and endianess Jongware <jongware@no-spam.plz> - 2014-09-15 10:57 +0200
  Re: gcc-4.x.x and endianess "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-15 14:06 +0100
    Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-15 21:50 -0400
      Re: gcc-4.x.x and endianess "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2014-09-17 09:54 +0100
        Re: gcc-4.x.x and endianess "Bill Cunningham" <nospam@nspam.invalid> - 2014-09-17 22:29 -0400

csiph-web