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

Groups > comp.lang.c > #112168

Re: Unexpected error on x[0] != y[0]

Show all headers | View raw

On 14/06/17 02:53, Rick C. Hodgin wrote:
> On Tuesday, June 13, 2017 at 2:07:25 PM UTC-4, Bart wrote:
>> On 13/06/2017 18:00, Rick C. Hodgin wrote:
>> The casts will do that in C. But there are other ways. This would be a 
>> useful feature for C I think:
>>
>> union {
>>    int a;
>>    int b[10];
>>    float x;
>> };
> 
> As I understand it, unions only allow valid extraction from the storage
> of the type last written to it.  I write an int into a, and I can only
> legally extract an int out from a.  Even b[0] would not technically be
> legal.

See C11 n1570 sections 6.5.2.3 and 6.2.6.1.  This is called "type
punning", and is defined behaviour.  (I believe it was not well
expressed in some earlier standard versions, but since compilers
supported it and code relied on it, it was clarified in the later
standards.)

There are still some gotchas.  For example, if you write something to
"b", then write to "a", the parts of "b" beyond the overlap with "a"
take unspecified values.  A compiler might use that if it made a
difference in execution speed - for example, if "a" were a 16-bit short,
and the processor has no 16-bit write instruction (such as early ARM
devices, or Alpha cpus), then the write could stomp over b[2] and b[3].

> 
> My argument all along has been that such a constraint is ridiculous,
> and that the purpose of the union should be exactly this type of non-
> cast conversion.

Well, yes.  The C committee thought so too.

> 
>> This is legal syntax now, but doesn't do anything. The intention is that 
>> in this form, it declares variables a, b and x that all occupy the same 
>> location (the start of a 40-byte block).
>>
>> Then you can write x=1.0; and print out its bit pattern using a.
>>
>> There is another similar feature but that is not as tidy; I used to use 
>> it like this:
>>
>>   int64 c @ &b[4]
>>
>> where the b is the 10-int array. Now, c is a 64-bit value occupying the 
>> same location as b[4] and b[5].
>>
>> So you can do sharing of memory, and read it in whichever way you like. 
>> You have to use a different identifier for each type, but that is better.
> 
> In CAlive, I allow every variable to be referenced by its name prefixed
> with an underscore, which is the unsigned int equivalent of whatever type
> it is.  It does not require a union, but allows everything to be used as
> an unsigned integer of its bytes, used for passing things around, setting
> things without casting, etc.

I do low-level programming all the time, and it is extremely rare for me
to need such access.  For more "normal" programming, it would be even
less useful.  I think it is good for a language to have some way of
accessing the low-level data, but I can't see it as something common
enough to need this sort of syntax - it is just not a feature that
people will have significant use of.  On the other hand, the use of _ as
a letter will be much, much more common, so this will lead to confusion.

It is good that a language can handle as many possibilities as you can
think of, but rare tasks can involve awkward or difficult coding.  In
fact, a task like this /should/ involve awkward coding - it is not an
operation that people should carry out lightly or do unnecessarily.  To
me, it would make much more sense to have a function like:

	read_as_uint32_t(x);

In C, you often use the memcpy() function for this sort of access - it
looks awkward, but the compiler can normally turn it into optimal
assembly and keep everything in registers without needing memory
accesses at all.


> 
> I am explicitly using it for pointers, and for function pointers, where
> the my_func() function is referenced as _my_func to reference its address.
> 
> Thank you,
> Rick C. Hodgin
> 

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

Thread

Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 06:57 -0700
  Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-12 15:11 +0100
    Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 07:18 -0700
      Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-12 15:29 +0100
        Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 07:41 -0700
          Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-12 18:32 +0100
            Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 10:56 -0700
              Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 08:14 -0700
                Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-13 17:52 +0100
                Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 10:00 -0700
                Re: Unexpected error on x[0] != y[0] scott@slp53.sl.home (Scott Lurndal) - 2017-06-13 17:19 +0000
                Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 10:33 -0700
                Re: Unexpected error on x[0] != y[0] scott@slp53.sl.home (Scott Lurndal) - 2017-06-13 17:56 +0000
                Re: Unexpected error on x[0] != y[0] Gareth Owen <gwowen@gmail.com> - 2017-06-13 19:45 +0100
                Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 17:54 -0700
                Re: Unexpected error on x[0] != y[0] joel.rees@gmail.com - 2017-06-13 20:57 -0700
                Re: Unexpected error on x[0] != y[0] Gareth Owen <gwowen@gmail.com> - 2017-06-14 06:41 +0100
                Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 03:37 -0700
                Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 03:54 -0700
                Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 17:45 -0700
                Re: Unexpected error on x[0] != y[0] David Brown <david.brown@hesbynett.no> - 2017-06-14 08:49 +0200
                Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-13 19:07 +0100
                Re: Unexpected error on x[0] != y[0] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-13 19:23 +0100
                Re: Unexpected error on x[0] != y[0] bartc <bc@freeuk.com> - 2017-06-13 22:30 +0100
                Re: Unexpected error on x[0] != y[0] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-13 23:29 +0100
                Re: Unexpected error on x[0] != y[0] supercat@casperkitty.com - 2017-06-13 11:51 -0700
                Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-13 17:53 -0700
                Re: Unexpected error on x[0] != y[0] Reinhardt Behm <rbehm@hushmail.com> - 2017-06-14 13:34 +0800
                Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 03:24 -0700
                Re: Unexpected error on x[0] != y[0] David Brown <david.brown@hesbynett.no> - 2017-06-14 09:10 +0200
  Re: Unexpected error on x[0] != y[0] John Bode <jfbode1029@gmail.com> - 2017-06-12 07:26 -0700
    Re: Unexpected error on x[0] != y[0] "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-12 10:54 -0400
      Re: Unexpected error on x[0] != y[0] Keith Thompson <kst-u@mib.org> - 2017-06-12 09:23 -0700
    Re: Unexpected error on x[0] != y[0] Gareth Owen <gwowen@gmail.com> - 2017-06-12 19:05 +0100
  Re: Unexpected error on x[0] != y[0] Anton Shepelev <anton.txt@gmail.com> - 2017-06-12 17:29 +0300
  Re: Unexpected error on x[0] != y[0] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-12 15:52 +0100
    Re: Unexpected error on x[0] != y[0] "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-12 08:31 -0700
  Re: Unexpected error on x[0] != y[0] joel.rees@gmail.com - 2017-06-13 22:09 -0700
    Re: Unexpected error on x[0] != y[0] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-14 11:24 +0100

csiph-web