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

Groups > comp.lang.c > #28872 > unrolled thread

Casts on lvalues

Back to article view | Back to comp.lang.c

Contents

  Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-02 13:23 +0000
    Re: Casts on lvalues SG <sgesemann@gmail.invalid> - 2012-12-02 14:40 +0100
    Re: Casts on lvalues Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-02 13:53 +0000
      Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-06 12:26 +0000
        Re: Casts on lvalues Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-06 15:15 +0000
        Re: Casts on lvalues Keith Thompson <kst-u@mib.org> - 2012-12-06 12:05 -0800
    Re: Casts on lvalues Keith Thompson <kst-u@mib.org> - 2012-12-02 12:34 -0800
      Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-02 21:18 +0000
        Re: Casts on lvalues Willem <willem@turtle.stack.nl> - 2012-12-05 22:36 +0000
          Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-05 23:46 +0000
            Re: Casts on lvalues Willem <willem@turtle.stack.nl> - 2012-12-06 18:35 +0000
      Re: Casts on lvalues pete <pfiland@mindspring.com> - 2012-12-02 16:21 -0500
        Re: Casts on lvalues Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-02 17:10 -0500
          Re: Casts on lvalues pete <pfiland@mindspring.com> - 2012-12-02 18:50 -0500
        Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-02 19:14 -0500
    Re: Casts on lvalues falk@rahul.net (Edward A. Falk) - 2012-12-04 23:57 +0000
      Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-05 01:35 +0000
        Re: Casts on lvalues Piotr Kalinowski <pitkali@gmail.com> - 2012-12-05 16:07 +0100
          Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-05 16:47 +0000
            Re: Casts on lvalues Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-05 13:04 -0500
              Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-05 18:39 +0000
                Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-05 14:23 -0500
                  Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-05 22:11 +0000
                    Re: Casts on lvalues Ian Collins <ian-news@hotmail.com> - 2012-12-06 11:51 +1300
                      Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-05 23:58 +0000
                        Re: Casts on lvalues Piotr Kalinowski <pitkali@gmail.com> - 2012-12-06 22:00 +0100
                    Re: Casts on lvalues glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-06 03:05 +0000
                Re: Casts on lvalues Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-05 14:43 -0500
                Re: Casts on lvalues Greg Martin <greg@softsprocket.com> - 2012-12-05 12:25 -0800
                  Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-05 21:57 +0000
                    Re: Casts on lvalues Keith Thompson <kst-u@mib.org> - 2012-12-05 16:09 -0800
                      Re: Casts on lvalues Philipp Thomas <kthomas@linux01.gwdg.de> - 2012-12-07 01:24 +0100
                        Re: Casts on lvalues Keith Thompson <kst-u@mib.org> - 2012-12-06 17:22 -0800
                          Re: Casts on lvalues Öö Tiib <ootiib@hot.ee> - 2012-12-07 00:31 -0800
                            Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-07 08:18 -0500
                              Re: Casts on lvalues Öö Tiib <ootiib@hot.ee> - 2012-12-07 09:07 -0800
                            Re: Casts on lvalues Keith Thompson <kst-u@mib.org> - 2012-12-07 11:01 -0800
                              Re: Casts on lvalues glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-07 21:57 +0000
                                Re: Casts on lvalues Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-07 22:29 +0000
                                  Re: Casts on lvalues glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-08 00:04 +0000
                              Re: Casts on lvalues lawrence.jones@siemens.com - 2012-12-15 16:51 -0500
                                Re: Casts on lvalues Keith Thompson <kst-u@mib.org> - 2012-12-15 15:48 -0800
                                  Re: Casts on lvalues lawrence.jones@siemens.com - 2012-12-17 16:37 -0500
                              Re: Casts on lvalues Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 02:58 -0800
                            Re: Casts on lvalues Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 02:53 -0800
                          Re: Casts on lvalues Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 02:43 -0800
                Re: Casts on lvalues Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-05 22:07 +0000
                  Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-05 22:20 +0000
                    Re: Casts on lvalues Keith Thompson <kst-u@mib.org> - 2012-12-05 16:10 -0800
                    Re: Casts on lvalues Philip Lantz <prl@canterey.us> - 2012-12-06 22:49 -0800
                      Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-07 12:54 +0000
                        Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-07 08:22 -0500
                          Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-07 13:48 +0000
                            Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-07 11:17 -0500
                              Re: Casts on lvalues glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-07 17:33 +0000
                                Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-07 18:28 +0000
                                  Re: Casts on lvalues glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-07 22:18 +0000
                              Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-07 18:27 +0000
                                Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-07 14:14 -0500
                                  Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-07 20:16 +0000
                                    Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-07 15:41 -0500
                                      Re: Casts on lvalues Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 03:03 -0800
                Re: Casts on lvalues Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-09 17:54 +0200
                  Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-09 12:38 -0500
                    Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-09 18:50 +0000
                      Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-09 14:31 -0500
                        Re: Casts on lvalues Keith Thompson <kst-u@mib.org> - 2012-12-09 20:12 -0800
                          Re: Casts on lvalues Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-12-10 07:38 +0000
                            Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-10 08:12 -0500
                              Re: Casts on lvalues Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-12-10 17:46 +0000
                                Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-10 12:59 -0500
                                Re: Casts on lvalues Keith Thompson <kst-u@mib.org> - 2012-12-10 12:07 -0800
                              Re: Casts on lvalues Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 03:11 -0800
                          Re: Casts on lvalues Ian Collins <ian-news@hotmail.com> - 2012-12-10 20:50 +1300
                          Re: Casts on lvalues James Kuyper <jameskuyper@verizon.net> - 2012-12-10 07:49 -0500
    Re: Casts on lvalues Rui Maciel <rui.maciel@gmail.com> - 2012-12-07 15:19 +0000
      Re: Casts on lvalues "BartC" <bc@freeuk.com> - 2012-12-07 16:54 +0000

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#29298

Keith Thompson <kst-u@mib.org> wrote:
> 
> I can't find the list of C99 DRs (the link I had,
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm>
> now points to the list of C2011 DRs), so I don't know which DR
> introduced this change.

C89 DRs: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr.htm>

C99 DRs: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary-c99.htm>
-- 
Larry Jones

What this games needs are negotiated settlements. -- Calvin

[toc] | [prev] | [next] | [standalone]

#29301

lawrence.jones@siemens.com writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> 
>> I can't find the list of C99 DRs (the link I had,
>> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm>
>> now points to the list of C2011 DRs), so I don't know which DR
>> introduced this change.
>
> C89 DRs: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr.htm>
>
> C99 DRs: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary-c99.htm>

Thanks!

(Small annoying quibble: Those are C90 DRs, not C89 DRs; they refer to
the C90 section numbers.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#29441

Keith Thompson <kst-u@mib.org> wrote:
> lawrence.jones@siemens.com writes:
> > Keith Thompson <kst-u@mib.org> wrote:
> >> 
> >> I can't find the list of C99 DRs (the link I had,
> >> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm>
> >> now points to the list of C2011 DRs), so I don't know which DR
> >> introduced this change.
> >
> > C89 DRs: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr.htm>
> >
> > C99 DRs: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary-c99.htm>
> 
> Thanks!
> 
> (Small annoying quibble: Those are C90 DRs, not C89 DRs; they refer to
> the C90 section numbers.)

Oops, right you are!  DRs are an ISO thing, so they naturally refer to
the ISO standard rather than the ANSI one.
-- 
Larry Jones

It seems like once people grow up, they have no idea what's cool. -- Calvin

[toc] | [prev] | [next] | [standalone]

#29388

Keith Thompson <kst-u@mib.org> writes:

> @C3{96}@C3{B6} Tiib <ootiib@hot.ee> writes:
>> On Friday, 7 December 2012 03:22:47 UTC+2, Keith Thompson  wrote:
>>> Philipp Thomas <kthomas@linux01.gwdg.de> writes:
>>> > On Wed, 05 Dec 2012 16:09:23 -0800, Keith Thompson <kst-u@mib.org>
>>> > wrote:
>>> >>Or you can use a union; this avoids alignment issues, but the other
>>> >>problems still apply.
>>> >
>>> > When used for type-punning that isn't guaranteed to work but depends
>>> > on the compiler.
>>> 
>>> A footnote in the standard (N1370 6.5.2.3p3, footnote 95) says:
>>> 
>>>     If the member used to read the contents of a union object is
>>>     not the same as the member last used to store a value in the
>>>     object, the appropriate part of the object representation of
>>>     the value is reinterpreted as an object representation in the
>>>     new type as described in 6.2.6 (a process sometimes called
>>>     "type punning"). This might be a trap representation.
>>> 
>>> I'm not sure why that's stated only in a non-normative footnote.
>>> I suppose the implication is that it's already stated normatively,
>>> but it's not clear to me that it is.
>>
>> C99 has such texts:
>>
>>     6.2.5p20, union has an overlapping set of member objects
>>     6.7.2.1p14, the value of at most one of the members can be stored
>>     in a union object at any time
>>     Annex J.1 the value of a union member other than the last one
>>     stored into is unspecified.
>>
>> I do not feel it safe to use union for type punning.
>
> Note that C99 doesn't have that footnote, but N1256 does.  It was added
> by one of Technical Corrigenda 3 -- but N1256 (which incorporates TC3)
> still has that clause in Annex J.1.  I suspect this is just an
> oversight.
>
> N1570 (essentially C2011) changed the wording of the clause in J.1
> (which is a list of unspecified behaviors) from:
>     The value of a union member other than the last one stored into
>     (6.2.6.1)
> to:
>     The values of bytes that correspond to union members other than the
>     one last stored into (6.2.6.1).
>
> I can't find the list of C99 DRs (the link I had,
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm>
> now points to the list of C2011 DRs), so I don't know which DR
> introduced this change.
>
> But the implication is that the committee felt that the existing C99
> standard already implied what the footnote says.  [snip]

In fact, the footnote was added precisely because someone was
concerned it wasn't obvious (or obvious enough) that C99's
rules produced the same behavior (ie, type punning) for union
access as had been true before C99.

[toc] | [prev] | [next] | [standalone]

#29385

[someone] writes:

> On Friday, 7 December 2012 03:22:47 UTC+2, Keith Thompson  wrote:
>> Philipp Thomas <kthomas@linux01.gwdg.de> writes:
>> > On Wed, 05 Dec 2012 16:09:23 -0800, Keith Thompson <kst-u@mib.org>
>> > wrote:
>> >>Or you can use a union; this avoids alignment issues, but the other
>> >>problems still apply.
>> >
>> > When used for type-punning that isn't guaranteed to work but depends
>> > on the compiler.
>> 
>> A footnote in the standard (N1370 6.5.2.3p3, footnote 95) says:
>> 
>>     If the member used to read the contents of a union object is
>>     not the same as the member last used to store a value in the
>>     object, the appropriate part of the object representation of
>>     the value is reinterpreted as an object representation in the
>>     new type as described in 6.2.6 (a process sometimes called
>>     "type punning"). This might be a trap representation.
>> 
>> I'm not sure why that's stated only in a non-normative footnote.
>> I suppose the implication is that it's already stated normatively,
>> but it's not clear to me that it is.
>
> C99 has such texts:
>
>     6.2.5p20, union has an overlapping set of member objects
>     6.7.2.1p14, the value of at most one of the members can be stored in a union object at any time
>     Annex J.1 the value of a union member other than the last one stored into is unspecified.
>
> I do not feel it safe to use union for type punning.

And you feel that way despite the Standard clearly stating
in plain English that this is how union access /does/ work,
including explaining that it is called 'type punning'?

[toc] | [prev] | [next] | [standalone]

#29380

Keith Thompson <kst-u@mib.org> writes:

> Philipp Thomas <kthomas@linux01.gwdg.de> writes:
>> On Wed, 05 Dec 2012 16:09:23 -0800, Keith Thompson <kst-u@mib.org>
>> wrote:
>>>Or you can use a union; this avoids alignment issues, but the other
>>>problems still apply.
>>
>> When used for type-punning that isn't guaranteed to work but depends
>> on the compiler.
>
> A footnote in the standard (N1370 6.5.2.3p3, footnote 95) says:
>
>     If the member used to read the contents of a union object is
>     not the same as the member last used to store a value in the
>     object, the appropriate part of the object representation of
>     the value is reinterpreted as an object representation in the
>     new type as described in 6.2.6 (a process sometimes called
>     "type punning"). This might be a trap representation.
>
> I'm not sure why that's stated only in a non-normative footnote.
> I suppose the implication is that it's already stated normatively,
> but it's not clear to me that it is.

I've explained this before.  It's a consequence of the definition
of union types and the normal rules for lvalue conversion.  There
isn't anything hard about it for anyone willing to sit down and
trace through the different sections;  all it takes is checking
that everything is defined and what the defined semantics are.
Basically, if variable access "works", then doing a type-punning
access on a union member has to "work", because the same semantics
are invoked in the two cases.

[toc] | [prev] | [next] | [standalone]

#28957

"BartC" <bc@freeuk.com> writes:

> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
> news:k9o2b3$bcb$1@dont-email.me...
<snip>
>>     Um, er, assignment itself is asymmetric ...
>
> Plenty of terms can appear interchangeably on both left and right sides.
>
> But while A can appear on either side, (T)A can't. And there doesn't
> appear to be a convincing reason why not.

 B    = (T)A;   // OK
 (T)A = B;      // not OK
 B    = +A;     // OK
 +A   = B;      // not OK
 B    = !A;     // OK
 !A   = B;      // not OK
 B     = A + C; // OK
 A + C = B;     // not OK

... and so on.  There's a pattern.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#28960

"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
news:0.9fd76eb692e0db06bfc4.20121205220731GMT.87mwxsywyk.fsf@bsb.me.uk...
> "BartC" <bc@freeuk.com> writes:
>
>> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
>> news:k9o2b3$bcb$1@dont-email.me...
> <snip>
>>>     Um, er, assignment itself is asymmetric ...
>>
>> Plenty of terms can appear interchangeably on both left and right sides.
>>
>> But while A can appear on either side, (T)A can't. And there doesn't
>> appear to be a convincing reason why not.
>
> B    = (T)A;   // OK
> (T)A = B;      // not OK
> B    = +A;     // OK
> +A   = B;      // not OK
> B    = !A;     // OK
> !A   = B;      // not OK
> B     = A + C; // OK
> A + C = B;     // not OK
>
> ... and so on.  There's a pattern.

OK, I see it. But: the (T)A=B example might be done instead as:

 memcpy(&A, &B, sizeof(T));

So it expresses something that could conceivably make sense. Unlike the 
other examples that don't!

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#28966

"BartC" <bc@freeuk.com> writes:
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.9fd76eb692e0db06bfc4.20121205220731GMT.87mwxsywyk.fsf@bsb.me.uk...
>> "BartC" <bc@freeuk.com> writes:
>>> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
>>> news:k9o2b3$bcb$1@dont-email.me...
>> <snip>
>>>>     Um, er, assignment itself is asymmetric ...
>>>
>>> Plenty of terms can appear interchangeably on both left and right sides.
>>>
>>> But while A can appear on either side, (T)A can't. And there doesn't
>>> appear to be a convincing reason why not.
>>
>> B    = (T)A;   // OK
>> (T)A = B;      // not OK
>> B    = +A;     // OK
>> +A   = B;      // not OK
>> B    = !A;     // OK
>> !A   = B;      // not OK
>> B     = A + C; // OK
>> A + C = B;     // not OK
>>
>> ... and so on.  There's a pattern.
>
> OK, I see it. But: the (T)A=B example might be done instead as:
>
>  memcpy(&A, &B, sizeof(T));
>
> So it expresses something that could conceivably make sense. Unlike the 
> other examples that don't!

Ok, you're right, lvalue casts could conceivably make sense.

C doesn't have lvalue casts.

Are there any unanswered questions remaining?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#29006

BartC wrote:
> 
> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
> news:0.9fd76eb692e0db06bfc4.20121205220731GMT.87mwxsywyk.fsf@bsb.me.uk...
> > "BartC" <bc@freeuk.com> writes:
> >
> >> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
> >> news:k9o2b3$bcb$1@dont-email.me...
> > <snip>
> >>>     Um, er, assignment itself is asymmetric ...
> >>
> >> Plenty of terms can appear interchangeably on both left and right sides.
> >>
> >> But while A can appear on either side, (T)A can't. And there doesn't
> >> appear to be a convincing reason why not.
> >
> > B    = (T)A;   // OK
> > (T)A = B;      // not OK
> > B    = +A;     // OK
> > +A   = B;      // not OK
> > B    = !A;     // OK
> > !A   = B;      // not OK
> > B     = A + C; // OK
> > A + C = B;     // not OK
> >
> > ... and so on.  There's a pattern.
> 
> OK, I see it. But: the (T)A=B example might be done instead as:
> 
>  memcpy(&A, &B, sizeof(T));
> 
> So it expresses something that could conceivably make sense. Unlike the 
> other examples that don't!

Do you think that "B = (T)A" is similar to "memcpy(&B, &A, sizeof(T))"?

It's not.

So, if you did think that, it helps me understand why you think lvalue 
casts make sense.

[toc] | [prev] | [next] | [standalone]

#29014

"Philip Lantz" <prl@canterey.us> wrote in message
news:MPG.2b2a08f2d3f3130f9896d6@news.eternal-september.org...
> BartC wrote:
>>
>> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>> news:0.9fd76eb692e0db06bfc4.20121205220731GMT.87mwxsywyk.fsf@bsb.me.uk...

>> > B    = (T)A;   // OK
>> > (T)A = B;      // not OK

>> OK, I see it. But: the (T)A=B example might be done instead as:
>>
>>  memcpy(&A, &B, sizeof(T));
>>
>> So it expresses something that could conceivably make sense. Unlike the
>> other examples that don't!
>
> Do you think that "B = (T)A" is similar to "memcpy(&B, &A, sizeof(T))"?

No. I'm interested in type-punning the left-hand-side; memcpy might be one
way of achieving that in some cases.

Your example might also work, except that (T) on the right-hand-side does
type conversion not type-punning.

> It's not.
>
> So, if you did think that, it helps me understand why you think lvalue
> casts make sense.

Since any 'lvalue cast' of the form (T)A can be written instead as *(T*)&A, 
which is perfectly legal, then why shouldn't it make sense?

Look, I have this compiler project from a couple of months back. That
language also doesn't have lvalue casts (it wasn't too hot on casts, but it 
*does* have the 'equivalence' feature which C doesn't have, which is what is 
used instead, and is better IMO).

I decided to add lvalue casts to that language. It took ten minutes, and six 
lines of code, to have them working for assignment! (Needs a bit more work 
for general lvalues, and  obviously a lot more testing.)

So I can now write in that language:

real x
int a

a:=x
real(a):=x           # lvalue cast!

Intermediate output:

0003: 1:005       convert                   (a,x)                     int32,
real64
0004: 1:006       move                      (a,x)
real64, real64

And, since it was set up to produce C code, this is the final output
(obviously r64 and i32 are typedefs):

r64 x;
i32 a;

 a = x;
 *(r64*)&a = x;

Notice anything similar between this last line (which I haven't doctored)
and the *(T*)&A I wrote above? (I didn't even change any part of the code
generation; this is what naturally came out. However, I didn't run this
example because I just realised the destination is too small..)

Lvalue casts *can* be meaningful, and while people are right in that C
doesn't directly define them, they can be achieved with a simple
transformation.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#29018

On 12/07/2012 07:54 AM, BartC wrote:
...
> Look, I have this compiler project from a couple of months back. That
> language also doesn't have lvalue casts (it wasn't too hot on casts, but it 
> *does* have the 'equivalence' feature which C doesn't have, which is what is 
> used instead, and is better IMO).

C does have a feature with the same semantics as your "equivalence"
feature, just different syntax. That feature is called a union.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#29019

"James Kuyper" <jameskuyper@verizon.net> wrote in message
news:k9sqi4$do2$1@dont-email.me...
> On 12/07/2012 07:54 AM, BartC wrote:
> ...
>> Look, I have this compiler project from a couple of months back. That
>> language also doesn't have lvalue casts (it wasn't too hot on casts, but
>> it
>> *does* have the 'equivalence' feature which C doesn't have, which is what
>> is
>> used instead, and is better IMO).
>
> C does have a feature with the same semantics as your "equivalence"
> feature, just different syntax. That feature is called a union.

Unions are much more limited. For example, if you have:

int A[25];
double X;

you can't 'equivalence' X to A[16] without some difficulty. (Actually X
might span both A[16] and A[17].)

A might also be external, limiting the options further.

It's also harder to refer to A and X entirely independently; you might need
to use U.A and U.X (if you can even get that far).

(BTW 'equivalence' is a (now-deprecated) feature of Fortran. I thought
people might be familiar with it. My version just uses @, for example: 
double X @ A[16]; )

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#29022

On 12/07/2012 08:48 AM, BartC wrote:
> 
> 
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:k9sqi4$do2$1@dont-email.me...
>> On 12/07/2012 07:54 AM, BartC wrote:
>> ...
>>> Look, I have this compiler project from a couple of months back. That
>>> language also doesn't have lvalue casts (it wasn't too hot on casts, but
>>> it
>>> *does* have the 'equivalence' feature which C doesn't have, which is what
>>> is
>>> used instead, and is better IMO).
>>
>> C does have a feature with the same semantics as your "equivalence"
>> feature, just different syntax. That feature is called a union.
> 
> Unions are much more limited. For example, if you have:
> 
> int A[25];
> double X;
> 
> you can't 'equivalence' X to A[16] without some difficulty. (Actually X
> might span both A[16] and A[17].)

Your earlier description of how "equivalence" works in your language
didn't mention that it could be used in that fashion. Yes, that would be
a bit harder to do in C. If _Alignof(int) != _Alignof(double), make sure
that a[16] is correctly aligned to be used as a place to store a double
could, in principle, be problematic. The fact that you chose a power of
2 as a subscript makes this unlikely to be an issue on most machines,
but I presume your language also allows X to be equivalenced with A[17]?
If there was only one 'double' object equivalenced to A[17], you could
adjust the location of A to make sure that A[17] was correctly aligned
for a double. However, that approach wouldn't work if multiple
incompatible equivalences were specified. How does your language deal
with that? Can it only be implemented on platforms with no alignment
restrictions?

> A might also be external, limiting the options further.

In C, if A were external, code compiled to work with A could be
optimized to assume that no pointer to double ever aliases any part of
A. The union approach removes permission to make such optimizations, at
least for code within the scope of the union, but if the declaration of
A is outside your control, that's not an option.
Allowing anything in C that's similar to your language's "equivalence"
would require disabling such optimizations. Allowing it for arbitrary
types would require disabling all such optimizations; I presume that
such optimizations are prohibited in your language? Or perhaps code
which would interact badly with such optimizations is prohibited? That
would be the equivalent of restrict-qualifying most pointer declarations
in C.

> It's also harder to refer to A and X entirely independently; you might need
> to use U.A and U.X (if you can even get that far).
> 
> (BTW 'equivalence' is a (now-deprecated) feature of Fortran. I thought
> people might be familiar with it. My version just uses @, for example: 
> double X @ A[16]; )

Its been a couple of decades since the last time I wrote much Fortran
code, and I don't think I ever used that feature, but I was aware of it.
If it has the same capability you describe above, I didn't remember that
fact, which isn't particularly surprising.

[toc] | [prev] | [next] | [standalone]

#29030

James Kuyper <jameskuyper@verizon.net> wrote:
> On 12/07/2012 08:48 AM, BartC wrote:

(snip, someone wrote)
>>> C does have a feature with the same semantics as your "equivalence"
>>> feature, just different syntax. That feature is called a union.
 
>> Unions are much more limited. For example, if you have:
 
>> int A[25];
>> double X;
 
>> you can't 'equivalence' X to A[16] without some difficulty. (Actually X
>> might span both A[16] and A[17].)
 
> Your earlier description of how "equivalence" works in your language
> didn't mention that it could be used in that fashion. Yes, that would be
> a bit harder to do in C. If _Alignof(int) != _Alignof(double), make sure
> that a[16] is correctly aligned to be used as a place to store a double
> could, in principle, be problematic. 

(snip)
 
>> It's also harder to refer to A and X entirely independently; 
>> you might need to use U.A and U.X (if you can even get that far).
 
>> (BTW 'equivalence' is a (now-deprecated) feature of Fortran. 
>> I thought people might be familiar with it. My version just 
>> uses @, for example: double X @ A[16]; )
 
> Its been a couple of decades since the last time I wrote much Fortran
> code, and I don't think I ever used that feature, but I was aware of it.
> If it has the same capability you describe above, I didn't remember that
> fact, which isn't particularly surprising.

Fortran EQUIVALENCE has many of the same restrictions as union, though
it is often used to get bits between different types.

Fortran now has TRANSFER, an intrinsic function that is defined 
to "transfer the physical representation." It also avoids any
questions about alignment. 

But then C has memcpy() and casts to (unsigned char *) to do it.

-- glen
 

[toc] | [prev] | [next] | [standalone]

#29033

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:k9t999$r5g$1@speranza.aioe.org...
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 12/07/2012 08:48 AM, BartC wrote:


>>> (BTW 'equivalence' is a (now-deprecated) feature of Fortran.
>>> I thought people might be familiar with it.

>> Its been a couple of decades since the last time I wrote much Fortran
>> code, and I don't think I ever used that feature, but I was aware of it.
>> If it has the same capability you describe above, I didn't remember that
>> fact, which isn't particularly surprising.
>
> Fortran EQUIVALENCE has many of the same restrictions as union, though
> it is often used to get bits between different types.

This page shows you can still set up all sorts of relationships between 
unrelated data:

http://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9b/index.html

-- 
Bartc  

[toc] | [prev] | [next] | [standalone]

#29049

BartC <bc@freeuk.com> wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
> news:k9t999$r5g$1@speranza.aioe.org...
>> James Kuyper <jameskuyper@verizon.net> wrote:

(snip on EQUIVALENCE)

>>> Its been a couple of decades since the last time I wrote much Fortran
>>> code, and I don't think I ever used that feature, but I was aware of it.
>>> If it has the same capability you describe above, I didn't remember 
>>> that fact, which isn't particularly surprising.

>> Fortran EQUIVALENCE has many of the same restrictions as union, though
>> it is often used to get bits between different types.
 
> This page shows you can still set up all sorts of relationships between 
> unrelated data:
 
> http://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn9b/index.html

EQUIVALENCE goes back to the first Fortran compiler, usually called 
Fortran I, in 1956. It required at least 4K (36 bit) words to run.
A 704 with the full 32K (36 bit) words was pretty much the super
computer of the time. EQUIVALENCE was needed to conserve memory
use, and much less for type punning. 

But yes, in later years, with more memory available, EQUIVALENCE
was commonly used to move bits between different data types.

TRANSFER wasn't added until, I believe, Fortran 90.
(Fortran 90 added dynamic allocation, which doesn't work
with EQUIVALENCE.)

-- glen

[toc] | [prev] | [next] | [standalone]

#29032

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:50C216B3.60103@verizon.net...
> On 12/07/2012 08:48 AM, BartC wrote:

>> Unions are much more limited. For example, if you have:
>>
>> int A[25];
>> double X;
>>
>> you can't 'equivalence' X to A[16] without some difficulty. (Actually X
>> might span both A[16] and A[17].)

> but I presume your language also allows X to be equivalenced with A[17]?

Yes. Or one byte past. (Well, if the hardware allows it, why not?)

> However, that approach wouldn't work if multiple
> incompatible equivalences were specified. How does your language deal
> with that?

The language is dumb. If you override the default alignments by using this 
aliasing, then it will use exactly the address you gave it. Just like you 
can do in assembly code.

> Can it only be implemented on platforms with no alignment
> restrictions?

Usually the feature will be used sensibly. Doubly so if unaligned accesses 
cause a crash. Although it's possible to deal with that properly; I've seen 
gcc generate byte-at-a-time code for accessing an int via a pointer it 
thought was unaligned.

> I presume that
> such optimizations are prohibited in your language?

Not in the language. But my compilers never did sophisticated optimisations 
anyway. (Actually I don't think they did unsophisticated ones either...)

> Or perhaps code
> which would interact badly with such optimizations is prohibited?

I don't think optimisations would need to be entirely ruled out. All the 
information is there at compile-time (unlike pointers where you're never 
quite sure what's pointing to what.) And you wouldn't use this stuff 
everywhere.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#29039

On 12/07/2012 01:27 PM, BartC wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message 
> news:50C216B3.60103@verizon.net...
...
>> I presume that
>> such optimizations are prohibited in your language?
> 
> Not in the language. But my compilers never did sophisticated optimisations 
> anyway. (Actually I don't think they did unsophisticated ones either...)
> 
>> Or perhaps code
>> which would interact badly with such optimizations is prohibited?
> 
> I don't think optimisations would need to be entirely ruled out. All the 
> information is there at compile-time (unlike pointers where you're never 
> quite sure what's pointing to what.) And you wouldn't use this stuff 
> everywhere.

I'm not talking about all optimizations, just the ones that depend upon
C's anti-aliasing guarantees. Consider the following function:

    void func(int n, float array[static n], long *l)
    {
        for(int i=0; i<n; i++)
            array[i] = *l;
        *l = n;
    }

This isn't a particularly useful function - I've chosen it solely to
clearly illustrate my point - but my point also applies to more
complicated and useful functions.
An implementation is permitted, because of 6.5p7, to compile that
function as if it had been written:

    void func(int n, float array[static n], long *l)
    {
        long temp = *l;
        for(int i=0; i<n; i++)
            array[i] = temp;
        *l = n;
    }

The optimized version has exactly the same behavior as the original, so
long as 6.5p7 is not violated. If C were changed to allow a long integer
to be equivalenced with a element of a float array, the value of *l
might change during the loop. If so, these two versions of the code
would no longer be equivalent, and there's an important question to be
asked about which one actually matches the user's intent. If the initial
value of *l was carefully chosen with the intent that it would, in fact,
be changed by this code inside that loop, the developer is going to be a
little upset if that didn't actually happen.

[toc] | [prev] | [next] | [standalone]

#29042

"James Kuyper" <jameskuyper@verizon.net> wrote in message 
news:50C24019.1020505@verizon.net...
> On 12/07/2012 01:27 PM, BartC wrote:

>> I don't think optimisations would need to be entirely ruled out. All the
>> information is there at compile-time (unlike pointers where you're never
>> quite sure what's pointing to what.)

> I'm not talking about all optimizations, just the ones that depend upon
> C's anti-aliasing guarantees. Consider the following function:
>
>    void func(int n, float array[static n], long *l)
>    {
>        for(int i=0; i<n; i++)
>            array[i] = *l;
>        *l = n;
>    }

> An implementation is permitted, because of 6.5p7, to compile that
> function as if it had been written:

>    void func(int n, float array[static n], long *l)
>    {
>        long temp = *l;
>        for(int i=0; i<n; i++)
>            array[i] = temp;
>        *l = n;
>    }
>
> The optimized version has exactly the same behavior as the original, so
> long as 6.5p7 is not violated. If C were changed to allow a long integer
> to be equivalenced with a element of a float array, the value of *l
> might change during the loop.

(Seems like it might just be copied to itself? In this example).

 >If so, these two versions of the code
> would no longer be equivalent, and there's an important question to be
> asked about which one actually matches the user's intent. If the initial
> value of *l was carefully chosen with the intent that it would, in fact,
> be changed by this code inside that loop, the developer is going to be a
> little upset if that didn't actually happen.

I can't see that the problems are going to be that different from the ones 
you might get when using pointers. (And the solutions might be similar.)

Because even without equivalencing, 'l' might anyway point into the array, 
via a cast.

If this was part of the language, at least the aliasing would be done in an 
overt manner, not hidden away in a pointer cast, in an operation done at 
runtime so you don't know at any time what is aliasing what.

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web