Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Transfer and variables that don't use all their storage space.
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Richard Maine  
View profile  
 More options Apr 9 2007, 12:28 am
Newsgroups: comp.lang.fortran
From: nos...@see.signature (Richard Maine)
Date: Sun, 8 Apr 2007 21:28:36 -0700
Local: Mon, Apr 9 2007 12:28 am
Subject: Re: Transfer and variables that don't use all their storage space.

Brooks Moses <bmoses-nos...@cits1.stanford.edu> wrote:
> Richard Maine wrote:
> I think I'm confused as to what it means, in practical terms, when "the
> standard ... requires disallowed behavior".

My phrasing of that isn't the world's best (or even second best :-)),
but I was basically agreeing with what seemed to be your logic. If the
standard requires behavior that the standard also disallows, I think one
can deduce that code that does that is non-conforming (by one of those
basic section 1.4 arguments). Thus the compiler can do anything.

> Doing that would either require that the entire initialization-
> expression evaluation mechanism store all logical variables in a way
> that records all eight bytes of "target storage" even though they are
> almost never meaningful,

Ok. I'm the naive one here, but I think that is the behavior anticipated
by the standard. If variables of a type (the 8-byte logical one or any
other) can be used as repositories of arbitrary bits by transfer, then
it seems to me that you need to store all those bits. Perhaps in special
cases, you can deduce that you can optimize storage of some of them
away, but that seems like an optimization to me.

> If I understand your above comments correctly, you've agreed that this
> is illegal code, but you also explicitly agreed with the second half of
> my first paragraph (the bit starting with "In particular," which says
> that transfer(transfer(-5_8, L), -5_8) must return -5, not 1.  It seems
> completely counterintuitive to me that the compiler is required to
> produce a specific result for illegal code.  However, that's what I'm
> understanding you to be saying.

No. I'm using a back door argument to explain why the code is illegal.
More or less a proof by contradiction, which is perhaps why it seems
contradictory. :-) I arise at a contradiction if I assume the code is
standard conforming. The contradiction is that the standard requires a
result that the standard also prohibits. Thus, I conclude that the
assumption of standard conformance is false.

> Would it be allowable, at least, for a compiler to throw an error and
> refuse to compile "transfer(transfer(-5_8, L), -5_8)" at all?

I think you could argue that. But then you might get users who
considered it a poor quality of implementation; that one is harder. I
have trouble imagining why anyone would ever want to do such a strange
thing, but James Buskirk can probably come up with something useful. :-)

I think the more "obvious" thing to do is to use all 8 bytes. But I
don't know what the costs of that are and what the tradoffs might be of
those costs versus the (rare?) usage of an idiom like that.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.