allocatable components and TRANSFER behavior
steve
supplied intrinsic subprogram)? In particular, in the second TRANSFER
is TRANSFER suppose to automagically allocate the allocatable
component?
program transfertest
type node
integer, allocatable :: c(:)
end type node
integer tempv(128)
type(node) v1, v2
allocate(v1%c(1))
v1%c(1) = 42
tempv = 0
tempv = transfer(v1, tempv)
open(10, status='scratch')
write(10,*) tempv
rewind(10)
tempv = 0
read(10,*) tempv
v2 = transfer(tempv, v1)
print '(I0,1X,I0)', v1%c(1), loc(v1%c(1))
print '(I0,1X,I0)', v2%c(1), loc(v2%c(1))
end program transfertest
Dan Nagle
On 2011-04-22 12:53:03 -0400, steve said:
> Is the following code conforming (where the LOC function is a vendor
> supplied intrinsic subprogram)?
No. The vendor is standard conforming to supply
an extended intrinsic set, but the application
is not standard conforming if it uses one.
See 10-007r1 at subclause 1.5, pp 2 item (7) and pp 4, page 23.
HTH
--
Cheers!
Dan Nagle
steve
I was simply trying to pre-empt someone from fixiating on my
use of LOC.
What do the two TRANFERs do here:
program transfertest
type node
integer, allocatable :: c(:)
end type node
integer tempv(128)
type(node) v1, v2
allocate(v1%c(1))
v1%c(1) = 42
tempv = 0
tempv = transfer(v1, tempv)
v2 = transfer(tempv, v1)
end program transfertest
--
steve
Richard Maine
> Is the following code conforming (where the LOC function is a vendor
> supplied intrinsic subprogram)? In particular, in the second TRANSFER
> is TRANSFER suppose to automagically allocate the allocatable
> component?
No. Its a bit tricky to work through the exact words that say no, but
I'm convinced they are there. Transfer is just about copying bits.
Automagic allocation is not just copying bits.
There probably ought to be more explicit prohibitions against things
like that. Perhaps there are, but if so I'm not sure where. Even without
the explicit prohibitions, I think the up-front general out applies -
the one that says that anything that has behavior not defined by the
standard is prohibited. The standard doesn't define what it means to
copy the bits of such a derived type. The standard's definition of
transfer does explicitly say that it just copies bits.
In my opinion, the standard's description of transfer is flawed in that
its attempts to elaborate say things that are not always actually
compatible with the definition.
P.S. I'd expect a mess, quite plausibly including segfaults and the
like. It would be very easy to end up with two separate allocatables
"pointing" to the same storage. That's not supposed to be able to
happen.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
steve
> steve <kar...@comcast.net> wrote:
> > Is the following code conforming (where the LOC function is a vendor
> > supplied intrinsic subprogram)? In particular, in the second TRANSFER
> > is TRANSFER suppose to automagically allocate the allocatable
> > component?
>
> No. Its a bit tricky to work through the exact words that say no, but
> I'm convinced they are there. Transfer is just about copying bits.
> Automagic allocation is not just copying bits.
I'll certainly agree that this is a bit tricky. I've spent several
hours reading through sections of the standard trying to
pinpoint a prohibition.
> There probably ought to be more explicit prohibitions against things
> like that. Perhaps there are, but if so I'm not sure where. Even without
> the explicit prohibitions, I think the up-front general out applies -
> the one that says that anything that has behavior not defined by the
> standard is prohibited. The standard doesn't define what it means to
> copy the bits of such a derived type. The standard's definition of
> transfer does explicitly say that it just copies bits.
I had a nagging feeling that the code should be nonconforming,
but the description of TRANSFER states that SOURCE and MOLD
can be of "any type". Unfortunately, "any type" includes user
defined derived types, which may include allocatable components.
As you may guess I was trying to find an explicit prohibition in
the standard.
> In my opinion, the standard's description of transfer is flawed in that
> its attempts to elaborate say things that are not always actually
> compatible with the definition.
>
> P.S. I'd expect a mess, quite plausibly including segfaults and the
> like. It would be very easy to end up with two separate allocatables
> "pointing" to the same storage. That's not supposed to be able to
> happen.
Yes, it is a mess. gfortran is essentially (and for the lack of a
better phrase) copying the array descriptor of the allocatable
component from one entity to another, including the address
of the allocated memory. With gfortran and the code from
my original post, one gets
troutmask:sgk[205] gfc4x -o z mn2.f90 && ./z
42 8615231632
42 8615231632
Segmentation fault (core dumped)
The 2nd number shows that 8615231632 is the memory
address of both v1%c(1) and v2%c(2). The segfault occurs
when during cleanup at the end of execution, ie., the memory
is freed twice!
Thanks for confirming (or at least supporting) my hunch that
the code is probably nonconforming.
--
steve
Richard Maine
> On Apr 22, 12:07 pm, nos...@see.signature (Richard Maine) wrote:
> > steve <kar...@comcast.net> wrote:
> > > Is the following code conforming (where the LOC function is a vendor
> > > supplied intrinsic subprogram)? In particular, in the second TRANSFER
> > > is TRANSFER suppose to automagically allocate the allocatable
> > > component?
> >
> > No. Its a bit tricky to work through the exact words that say no, but
> > I'm convinced they are there. Transfer is just about copying bits.
> > Automagic allocation is not just copying bits.
> address of both v1%c(1) and v2%c(2). The segfault occurs
> when during cleanup at the end of execution, ie., the memory
> is freed twice!
Very much what I'd expect.
In case you have trouble finding the bit of the standard I was referring
to, it is in the first sentence of 1.5 (in f2003, but all the other
versions have simillar words) and is easy to overlook.
"A program (2.2.1) is standard conforming if it uses only those forms
and relationships described herein AND IF THE PROGRAM HAS AN
INTERPRETATION ACCORDING TO THIS STANDARD." (emphasis obviously mine).
I don't think that the standard gives an interpretation for what it
means for two derived types like that to have the same "physical
representation" (the standard's description of transfer actually talks
about "physical represenation"; I normally express that with the much
shorter phrase "bits", but better go with the standard's exact words
when being this picky).
I hate it when one has to resort to citing that particular part of the
standard. That usually means that the standard is flawed elsewhere. But
yes, I already said that I think the standard's description of transfer
is badly flawed.
James Van Buskirk
news:e16139db-e8c3-48aa...@r35g2000prj.googlegroups.com...
> Is the following code conforming (where the LOC function is a vendor
> supplied intrinsic subprogram)? In particular, in the second TRANSFER
> is TRANSFER suppose to automagically allocate the allocatable
> component?
> program transfertest
> type node
> integer, allocatable :: c(:)
> end type node
> integer tempv(128)
> type(node) v1, v2
> allocate(v1%c(1))
> v1%c(1) = 42
> tempv = 0
> tempv = transfer(v1, tempv)
Is the size of an array descriptor 128*4 bytes? If not, the
line above should be an error because the result of TRANSFER
should be an array of default integers of the smallest size
that is at least as large as v1, which only has a single
component which is an array descriptor. Making tempv ALLOCATABLE
or including the SIZE argument would fix this.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
steve
> "steve" <kar...@comcast.net> wrote in message
>
> news:e16139db-e8c3-48aa...@r35g2000prj.googlegroups.com...
>
> > Is the following code conforming (where the LOC function is a vendor
> > supplied intrinsic subprogram)? In particular, in the second TRANSFER
> > is TRANSFER suppose to automagically allocate the allocatable
> > component?
> > program transfertest
> > type node
> > integer, allocatable :: c(:)
> > end type node
> > integer tempv(128)
> > type(node) v1, v2
> > allocate(v1%c(1))
> > v1%c(1) = 42
> > tempv = 0
> > tempv = transfer(v1, tempv)
>
> Is the size of an array descriptor 128*4 bytes?
No. sizeof(var1) = 24.
> If not, the
> line above should be an error because the result of TRANSFER
> should be an array of default integers of the smallest size
> that is at least as large as v1, which only has a single
> component which is an array descriptor.
The rhs has lbound = 1 and ubound = 6. AFAICT, there is
no issue in the evaluation of TRANSFER.
> Making tempv ALLOCATABLE
> or including the SIZE argument would fix this.
No error even with -fcheck=all, which isn't too surprising
given the history of transfer in gfortran.
--
steve
Richard Maine
> On Apr 22, 3:57 pm, "James Van Buskirk" <not_va...@comcast.net> wrote:
> > "steve" <kar...@comcast.net> wrote in message
> >
> > news:e16139db-e8c3-48aa...@r35g2000prj.googlegroups.com...
...
> > > integer tempv(128)
...
> > > tempv = transfer(v1, tempv)
> >
> > Is the size of an array descriptor 128*4 bytes?
>
> No. sizeof(var1) = 24.
...
> The rhs has lbound = 1 and ubound = 6. AFAICT, there is
> no issue in the evaluation of TRANSFER.
But there should be a problem with the assignment. (I had overlooked
this bit in my prior comments - just concentrating on what I thought was
the concept illustrated rather than on unrelated bugs in the code).
> No error even with -fcheck=all, which isn't too surprising
> given the history of transfer in gfortran.
The error would probably fall in the category of run-time array size
tests (which aren't mandated, but are nice). In this particular case, th
etest could in principle be figured out at compile time, but I wouldn't
normally expect most compilers to do that (I also could well be
surprised).
glen herrmannsfeldt
> steve <kar...@comcast.net> wrote:
(previously snipped)
allocate(v1%c(1))
v1%c(1) = 42
tempv = 0
tempv = transfer(v1, tempv)
v2 = transfer(tempv, v1)
>> Is the following code conforming
> No. Its a bit tricky to work through the exact words that say no, but
> I'm convinced they are there. Transfer is just about copying bits.
> Automagic allocation is not just copying bits.
It doesn't seem so obvious to me. Separate from the copy bits
question, allocate on assignment (that is what I thought was
being asked) is a property of the assignment. How about:
v2 = transfer(tempv, v1) + 1
Now the expression has to be evaluated before the assignment.
> There probably ought to be more explicit prohibitions against things
> like that. Perhaps there are, but if so I'm not sure where. Even without
> the explicit prohibitions, I think the up-front general out applies -
> the one that says that anything that has behavior not defined by the
> standard is prohibited. The standard doesn't define what it means to
> copy the bits of such a derived type. The standard's definition of
> transfer does explicitly say that it just copies bits.
If you think in terms of the descriptor that is actually stored,
(as I probably do too often) then the question of which bits are
copied comes up.
If you think of a structure containing an array of (previously)
unknown size, and where the size is known after allocate, then it
doesn't seem so strange to me. (Though I am very glad that I
don't have to implemement such.)
> In my opinion, the standard's description of transfer is flawed in that
> its attempts to elaborate say things that are not always actually
> compatible with the definition.
> P.S. I'd expect a mess, quite plausibly including segfaults and the
> like. It would be very easy to end up with two separate allocatables
> "pointing" to the same storage. That's not supposed to be able to
> happen.
If it does copy the descriptor, or whatever is used to implement
the ALLOCATABLE, then I agree. Maybe that is what it is supposed
to do, but, in terms of the way Fortran, and especially ALLOCATABLE,
is supposed to work, it would seem that it should copy the array
bits, not the descriptor bits. That it should give results similar
to what you would get without ALLOCATABLE, with arrays of the
appropriate size.
-- glen
glen herrmannsfeldt
(snip, someone wrote)
>> No. Its a bit tricky to work through the exact words that say no, but
>> I'm convinced they are there. Transfer is just about copying bits.
>> Automagic allocation is not just copying bits.
> I'll certainly agree that this is a bit tricky. I've spent several
> hours reading through sections of the standard trying to
> pinpoint a prohibition.
(snip)
> I had a nagging feeling that the code should be nonconforming,
> but the description of TRANSFER states that SOURCE and MOLD
> can be of "any type". Unfortunately, "any type" includes user
> defined derived types, which may include allocatable components.
> As you may guess I was trying to find an explicit prohibition in
> the standard.
(snip)
>> P.S. I'd expect a mess, quite plausibly including segfaults and the
>> like. It would be very easy to end up with two separate allocatables
>> "pointing" to the same storage. That's not supposed to be able to
>> happen.
> Yes, it is a mess. gfortran is essentially (and for the lack of a
> better phrase) copying the array descriptor of the allocatable
> component from one entity to another, including the address
> of the allocated memory. With gfortran and the code from
> my original post, one gets
Without going through it in too much detail, is it possible to
consider an implementation that copies the array, and not the
descriptor?
Considering that ALLOCATABLE isn't POINTER, even though the
implementation may be similar, it seems to me that it should
copy the array. I haven't looked at TRANSFER and POINTER, but
as this isn't POINTER, that shouldn't apply anyway.
> troutmask:sgk[205] gfc4x -o z mn2.f90 && ./z
> 42 8615231632
> 42 8615231632
> Segmentation fault (core dumped)
> The 2nd number shows that 8615231632 is the memory
> address of both v1%c(1) and v2%c(2). The segfault occurs
> when during cleanup at the end of execution, ie., the memory
> is freed twice!
I do agree that it shouldn't do that!
-- glen
steve
How is transfer going to determine how much memory to
automagically allocate? The standard states that
"If it [MOLD] is a variable, it need not be defined."
Richard Maine
> Richard Maine <nos...@see.signature> wrote:
> > No. Its a bit tricky to work through the exact words that say no, but
> > I'm convinced they are there. Transfer is just about copying bits.
> > Automagic allocation is not just copying bits.
>
> It doesn't seem so obvious to me. Separate from the copy bits
> question, allocate on assignment (that is what I thought was
> being asked) is a property of the assignment. How about:
>
> v2 = transfer(tempv, v1) + 1
>
> Now the expression has to be evaluated before the assignment.
It has nothing to do with the assignment. The transfer itself is what
has the problem. And, as usual, you are thinking to much about
implementation issues. This is most definitely a question about the
standard - not about what an implementation is likely to do. As
described by the standard, the RHS is *ALWAYS* evaluated before the
assignment. Anything ese is an optimization. While your +1 might change
the odds of an implementation optimizing things, it does not change what
the standard says about it.
The transfer itself gives a copy of the "physical representation". The
descriptor is part of that physical representation". If the transfer
allocated memory elsewhere and made the descriptor point to that new
memory, then the result would not have the same physical representation.
See also the description of what happens to allocatable components of
function results. They are deallocated after the statement completes.
That's going to be a problem here.
Richard Maine
> Without going through it in too much detail, is it possible to
> consider an implementation that copies the array, and not the
> descriptor?
No, because that's not what the standard says. The descriptor is part of
the "physical representation". The standard says the result has the same
physical representation.
Not to speak of the fact that this would make a (even worse than it is
already) mess of the implementation. Sounds like you are trying to turn
transfer into assignment; that ain't what it is.
glen herrmannsfeldt
(snip, I wrote)
>> v2 = transfer(tempv, v1) + 1
>> Now the expression has to be evaluated before the assignment.
> It has nothing to do with the assignment.
Yes. The +1 was to make it even more obvious that the transfer
is separate from the assignment.
> The transfer itself is what
> has the problem. And, as usual, you are thinking to much about
> implementation issues. This is most definitely a question about the
> standard - not about what an implementation is likely to do. As
> described by the standard, the RHS is *ALWAYS* evaluated before the
> assignment. Anything ese is an optimization. While your +1 might change
> the odds of an implementation optimizing things, it does not change what
> the standard says about it.
Well, if the standard requires something that can't be implemented,
then the standard had better change.
> The transfer itself gives a copy of the "physical representation".
OK.
> The descriptor is part of that physical representation".
This one I would have to look at in more depth.
> If the transfer allocated memory elsewhere and made the
> descriptor point to that new memory, then the result would
> not have the same physical representation.
> See also the description of what happens to allocatable components of
> function results. They are deallocated after the statement completes.
> That's going to be a problem here.
-- glen
Uno
> On Apr 22, 10:39 am, Dan Nagle<danna...@verizon.net> wrote:
>> Hello,
>>
>> On 2011-04-22 12:53:03 -0400, steve said:
>>
>>> Is the following code conforming (where the LOC function is a vendor
>>> supplied intrinsic subprogram)?
>>
>> No. The vendor is standard conforming to supply
>> an extended intrinsic set, but the application
>> is not standard conforming if it uses one.
>>
>> See 10-007r1 at subclause 1.5, pp 2 item (7) and pp 4, page 23.
>>
> That isn't the point of the post, which you conveniently ignored.
> I was simply trying to pre-empt someone from fixiating on my
> use of LOC.
>
> What do the two TRANFERs do here:
[code elided]
I don't know, but it's at least interesting:
$ gfortran -Wall -Wextra trans1.f03 -o out
$ ./out
*** glibc detected *** ./out: double free or corruption (fasttop):
0x09d2bbe0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6c501)[0x7a5501]
/lib/libc.so.6(+0x6dd70)[0x7a6d70]
/lib/libc.so.6(cfree+0x6d)[0x7a9e5d]
./out[0x8048b20]
./out[0x8048b6b]
/lib/libc.so.6(__libc_start_main+0xe7)[0x74fce7]
./out[0x8048591]
======= Memory map: ========
00450000-00451000 r-xp 00000000 00:00 0 [vdso]
0049d000-004b9000 r-xp 00000000 08:01 1646595 /lib/ld-2.12.1.so
004b9000-004ba000 r--p 0001b000 08:01 1646595 /lib/ld-2.12.1.so
004ba000-004bb000 rw-p 0001c000 08:01 1646595 /lib/ld-2.12.1.so
00515000-0052f000 r-xp 00000000 08:01 1646671 /lib/libgcc_s.so.1
0052f000-00530000 r--p 00019000 08:01 1646671 /lib/libgcc_s.so.1
00530000-00531000 rw-p 0001a000 08:01 1646671 /lib/libgcc_s.so.1
00739000-00890000 r-xp 00000000 08:01 1646678 /lib/libc-2.12.1.so
00890000-00892000 r--p 00157000 08:01 1646678 /lib/libc-2.12.1.so
00892000-00893000 rw-p 00159000 08:01 1646678 /lib/libc-2.12.1.so
00893000-00896000 rw-p 00000000 00:00 0
00a22000-00adb000 r-xp 00000000 08:01 681377
/usr/lib/libgfortran.so.3.0.0
00adb000-00adc000 r--p 000b8000 08:01 681377
/usr/lib/libgfortran.so.3.0.0
00adc000-00add000 rw-p 000b9000 08:01 681377
/usr/lib/libgfortran.so.3.0.0
00add000-00ade000 rw-p 00000000 00:00 0
00bc7000-00beb000 r-xp 00000000 08:01 1646832 /lib/libm-2.12.1.so
00beb000-00bec000 r--p 00023000 08:01 1646832 /lib/libm-2.12.1.so
00bec000-00bed000 rw-p 00024000 08:01 1646832 /lib/libm-2.12.1.so
08048000-08049000 r-xp 00000000 08:04 557532
/home/dan/source/fortran_stuff/out
08049000-0804a000 r--p 00000000 08:04 557532
/home/dan/source/fortran_stuff/out
0804a000-0804b000 rw-p 00001000 08:04 557532
/home/dan/source/fortran_stuff/out
09d2b000-09d4c000 rw-p 00000000 00:00 0 [heap]
b7600000-b7621000 rw-p 00000000 00:00 0
b7621000-b7700000 ---p 00000000 00:00 0
b77ef000-b77f1000 rw-p 00000000 00:00 0
b7800000-b7802000 rw-p 00000000 00:00 0
bfe38000-bfe59000 rw-p 00000000 00:00 0 [stack]
Aborted
$ cat trans1.f03
program transfertest
implicit none
type node
integer, allocatable :: c(:)
end type node
integer tempv(128)
type(node) v1, v2
allocate(v1%c(1))
v1%c(1) = 42
tempv = 0
tempv = transfer(v1, tempv)
v2 = transfer(tempv, v1)
end program transfertest
! gfortran -Wall -Wextra trans1.f03 -o out
$
I'm still interested in Dan's sentence:
"The vendor is standard conforming to supply
an extended intrinsic set, but the application
is not standard conforming if it uses one."
That sounds like Catholicism, not fortran.
--
Uno
steve
> I'm still interested in Dan's sentence:
>
> "The vendor is standard conforming to supply
> an extended intrinsic set, but the application
> is not standard conforming if it uses one."
>
> That sounds like Catholicism, not fortran.
*plonk*
Welcome to the the kill file. You have the
distinction of joining only one other individual
with such an honor.
--
steve
Richard Maine
> Well, if the standard requires something that can't be implemented,
> then the standard had better change.
I never said that the stanard requires something that "can't be
implemented." What I said was that the standard gives no interpretation
of what it means to copy the physical representation in such a case. I
also quoted the part of the standard that says that it is non-standard
to do things that the standard gives no interpretation of. In other
words, no the standard does not require it; quite the opposite in that
the standard forbids it, at least by my reading. Note that my very first
reply was to say that I believed the code in question to be violating
the standard.
I also do agree, however, that the standard ought to be changed (to make
the exclusion more explicit) as I also previously said.
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Well, if the standard requires something that can't be implemented,
>> then the standard had better change.
> I never said that the stanard requires something that "can't be
> implemented." What I said was that the standard gives no interpretation
> of what it means to copy the physical representation in such a case.
The statement was meant to be in general, not specifically
to the case under discussion. Many features have been well tested
as extensions in compilers before they are added, so one hopes not
to add something that can't be implemented. But if it did happen...
-- glen
glen herrmannsfeldt
(snip related to TRANSFER)
> I don't think that the standard gives an interpretation for what it
> means for two derived types like that to have the same "physical
> representation" (the standard's description of transfer actually talks
> about "physical represenation"; I normally express that with the much
> shorter phrase "bits", but better go with the standard's exact words
> when being this picky).
As a distraction from the original question, that could get
interesting where the underlying representation isn't binary.
If the representation was BCD, one might consider that the bits
be copied, though the result might not be a legal BCD value.
The underlying representation might be one that doesn't allow
for the transfer of a "physical representation." Decimal values
store in a 2 of 5 code (five signal wires, of which two are
active). That could be true on a system that uses a different
code for floating point or character data.
-- glen
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Without going through it in too much detail, is it possible to
>> consider an implementation that copies the array, and not the
>> descriptor?
> No, because that's not what the standard says. The descriptor is part of
> the "physical representation". The standard says the result has the same
> physical representation.
I was first considering the case of pointers. Consider:
real, pointer:: x(:)
allocate (x(1))
x(1)=123
print *,transfer(x,0)
do I expect the "physical representation" of the pointer?
Most C programmers would likely expect the representation
of the pointer, but I will presume that Fortran uses the
representation of 123.
> Not to speak of the fact that this would make a (even worse than it is
> already) mess of the implementation. Sounds like you are trying to turn
> transfer into assignment; that ain't what it is.
I was specifically trying not to do that. I was also considering
that allocate on assignment should work, such that an allocatable
variable on the left of an assignment be allocated appropriately.
(And I agree that isn't especially obvious in the case of
allocatable structure components.)
-- glen
Uno
Dude, I think you need a psychological intervention; my guess is that
you've burned a lot of bridges.
The dan you know doesn't do anything conveniently.
--
Uno
Richard Maine
> Richard Maine <nos...@see.signature> wrote:
> > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> >> Without going through it in too much detail, is it possible to
> >> consider an implementation that copies the array, and not the
> >> descriptor?
>
> > No, because that's not what the standard says. The descriptor is part of
> > the "physical representation". The standard says the result has the same
> > physical representation.
>
> I was first considering the case of pointers. Consider:
>
> real, pointer:: x(:)
> allocate (x(1))
> x(1)=123
> print *,transfer(x,0)
>
> do I expect the "physical representation" of the pointer?
No, but that's because you aren't doing a transfer on the pointer. You
are doing a transfer on the target of the pointer. Pointers are
deferenced as actual arguments except when the dummy is a pointer. If
you want to transfer the physical representation of the pointer, you
need to do the "usual" trick of having a derived type with a pointer
component. That will then be much more like the OP's example... except
that having two pointers to the same target is legal.
There would still be the unadressed question of whether a copy of the
physical representation of a pointer is necessarily menaingful. That's
processor dependent. It would be with most implementations, but one
could certainly imagine (anyway, I can) implementations where a copy of
the physical representation of a pointer was not a valid pointer. Maybe
something with relative addressing instead of absolute, though that
seems like it would be messy and thus unlikely as an implementation
anyway. Or other things. Too much bother to try to think one through.
The thing is that I don't see that the standard actually guarantees that
a copy of the physical representation will be valid. That's sort of like
your example elsethread where there are bit patterns that aren't
necssarily valid for all types. The standard's wording of transfer seems
to assume that any bit patern wil be valid for any type. It leaves it
processor dependent what value is implied by the bit pattern, but
doesn't seem to consider the cases where the bit pattern just isn't
valid at all for the type in question.
Richard Maine
> Richard Maine <nos...@see.signature> wrote:
> > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> >> Well, if the standard requires something that can't be implemented,
> >> then the standard had better change.
>
> > I never said that the stanard requires something that "can't be
> > implemented." What I said was that the standard gives no interpretation
> > of what it means to copy the physical representation in such a case.
>
> The statement was meant to be in general, not specifically
> to the case under discussion.
Oh... Kay...
I guess that as a general statement I can't argue with it. I was making
the (mistaken?) assumption that it had something to do with the rest of
the thread. I have a feeling that I'm still missing something, though
because it is hard for me to imagine that it was meant just completely
out of the blue.