Any danger in this sample program?
in [Fortran]
|
Prev: Atarax cheapest. Lowest prices for Atarax online. Atarax how much can you take. Next day delivery on Atarax saturday.
Next: Buy online HYDROCODONE, order prescription free HYDROCODONE, cheap HYDROCODONE next day
From: yaqi on 28 Apr 2010 15:52 On Apr 28, 1:38 pm, nos...(a)see.signature (Richard Maine) wrote: > yaqi <yaqiw...(a)gmail.com> wrote: > > Although a%ptr is not associated, its size is not zero. (I guess it is > > not specified in the Fortran reference.) > > "Not specified" is a bit shy of the mark. It is far worse than that. The > Fortran standard does specify some related things, but the > specifications are in the opposite direction of what you appear to be > thinking. They are also very much the kinds of things that it is > critical to understand when working with pointers. Pointers are tricky. > If you don't understand them *VERY* well, you are highly likely to > introduce subtle bugs. > > First, if a pointer is not associated, the standard specifies that it is > illegal for your program to even inquire about the size. If you do so, > then anything can happen; certainly it could return random bogus values; > it could also abort with an error message. Both of those possibilities > are very real. It could also cause subtle symptoms that show up > elsewhere, though that doesn't seem as likely for the case of inquiring > about size (unless you mistakenly believe the result and index out of > bounds as a result). > > Perhaps even more important is that you need to understand that a > pointer can have one of *3* association statuses. It can be associated, > not associated, or have undefined association status. > > You canot use the associated intrinsic (or anything else) to tell > whether a pointer is associated. That may sound odd, but it is so and it > is very important. In particular, it is illegal to even use the > associated intrinsic on a pointer whose association status is undefined. > If you do so, then, as before, you might get bogus results, an error > result, or subtle symptoms elsewhere. > > The associated intrinsic is useful only to distinguish between > associated and not associated, and only if you have separately ruled out > the possibility of the ssociation status being undefined. That's why I > say it can't tell you wehther a pointer is associated - because it can't > distinguish between associated and undefined. > > If you use the associated intrinsic on something that has undefined > association status, and you then take actions based on the assumption > that it returns a meaningful result, it is very easy to corrupt memory > and cause all kinds of symptoms, possibly in places far removed from > where the error was made. > > And yes, the symptoms can change depending on almost anything. That > certainly includes running in debug versus non-debug mode. > > To determine whether a pointer has undefined association status - there > is no intrinsic for that. The only way to do it is to understand and > watch for all the ways that the standard says a pointer can get > undefined association status. No, that's not easy. It is part of why > pointers are tricky. > > I don't have any direct evidence that this is related to your problem. I > don't have direct evidence of much of anything. But your posting seems > to illustrate inadequate appreciation of these issues, which naturally > makes me suspicious of them. The bugs they cause can be very subtle. > > -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain Hi Richard, I understand what you said. Actually in the type definition, the ptr is pointed to null with =>null(), so once an object is declared, the status of its ptr is defined and unassociated.
From: Jim Xia on 28 Apr 2010 16:04 > > " > > While an entity is associated with a dummy argument, the following > > restrictions hold. > > (1) Action that a ects the allocation status of the entity or a > > subobject thereof shall be taken through > > the dummy argument. > > (2) If the allocation status of the entity or a subobject thereof is a > > ected through the dummy argument, > > then at any time during the invocation and execution of the procedure, > > either before or after the > > allocation or deallocation, it shall be referenced only through the > > dummy argument. > > (3) Action that a ects the value of the entity or any subobject of it > > shall be taken only through the > > dummy argument unless > > (a) the dummy argument has the POINTER attribute or > > (b) the dummy argument has the TARGET attribute, the dummy argument > > does not have INTENT > > (IN), the dummy argument is a scalar object or an assumed-shape array > > without the CONTI- > > GUOUS attribute, and the actual argument is a target other than an > > array section with a > > vector subscript. > > (4) If the value of the entity or any subobject of it is a ected > > through the dummy argument, then at > > any time during the invocation and execution of the procedure, either > > before or after the de nition, > > it may be referenced only through that dummy argument unless > > (a) the dummy argument has the POINTER attribute or > > (b) the dummy argument has the TARGET attribute, the dummy argument > > does not have INTENT > > (IN), the dummy argument is a scalar object or an assumed-shape array > > without the CONTI- > > GUOUS attribute, and the actual argument is a target other than an > > array section with a > > vector subscript." > > > I'm suspecting you have something directly violates the rules. The > > problems are normally ONLY exposed when you turn on high > > optimizations. > > > And of course, you may also be looking at a compiler bug. > > > Cheers, > > > Jim > > If I understand correctly, I can not vaolate these rules because the > module here is like a class definition in c++. There are no data in > the module. The caller pass the arguments to the rename subroutine, > the rename subroutine can only see the passed arguments and does > operations over the arguments. > > Although I really donot want to, I suspect this is a compiler bug > because I print the size of b right after the pointer assignment but > it is not equal to the size of a in my real code.- Hide quoted text - These rules are designed to allow compilers to do aggressive optimizations. For certain circustances, compilers need to move memories around for your dummy arguments. If two dummies are associated with each other, then the memory updates on them can be out of sync. That's why these rules basically say you're not allowes to have two dummies overlapped with each other, not allowed to touch the same piece of memory, etc. This is a common area that programmers got it wrong, thinking execuation orders with their code. In fact when they are not. The latest standard can be found at http://www.nag.co.uk/sc22wg5/ Cheers, Jim
From: robin on 29 Apr 2010 00:28
"yaqi" <yaqiwang(a)gmail.com> wrote in message news:baa630dc-5f6f-4b8f-a425-e6bd1d0fcd7c(a)z13g2000prh.googlegroups.com... >Many thanks! And sorry I am too confident and not test the sample >program I attached here. >The problem is that the actual code is so large and propertery that I >am sure no one want to really look into it. >I add few print statements in my actual code at the beginning of >rename and after. Something like: No, you are doing it again, namely, re-typing stuff, and not giving the ACTUAL code. With your actual code, what compiler checks do you have on? Subscript bound checks? Better to turn on ALL checks. |