| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Hello,
I have discovered the problem with mcc_aes_copy. It is not able to copy an
entity when the source and destination entities are the same.
In my particular case, the following thing happened.
MCC_A_AES p_source_entity;
MCC_A_AES p_dest_entity;
p_source_entity is created 3 levels deep.
p_dest_entity = p_source_entity;
status = mcc_aes_copy(&p_source_entity, &p_dest_entity);
The status is equal to MCC_S_NORMAL, the values of p_source_entity and
p_dest_entity pointers are the same, and they are the same, as before
mcc_aes_copy call, but the resulting entity is only 1 level deep, without any
instance.
Please, note, that I do understand, that it is questionable to write the line
p_dest_entity = p_source_entity;
but I don't think that it is different, than writing
p_dest_entity = MCC_K_NULL_PTR;
and you have to do that, because there is no mcc_aes_init function, and you
have to set a pointer to MCC_K_NULL_PTR when you create entity from scratch.
Plus, I haven't seen anywhere the prohibition to write the following line
status = mcc_aes_copy(&p_source_entity, &p_source_entity);
which will lead to the same result as above.
Any ideas?
Thank you,
Gene
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3366.1 | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Wed Jul 15 1992 17:26 | 5 | |
Doctor, it hurts when I stick my hand in a flame....
What problem are you trying to solve? It doesn't make sense
to copy an AES onto itself.
| |||||
| 3366.2 | SWORD1::ES | Eugene Shvartsman | Wed Jul 15 1992 18:23 | 22 | |
> Doctor, it hurts when I stick my hand in a flame....
Jim,
Absolutely agree. Maybe a litle bit more appropriate word is 'swamp': you try
to pull out one leg, but the other will stuck deeper.
The problem is, that real code is not so simple as presented.
The actual mcc_aes_copy call is inside one function, where p_source_entity and
p_dest_entity are passed as a pointers, and actual entities has been created
somewhere else. So this function has no idea that they may happen to be the
same.
For example, strcpy, memcpy in C, lib$scopy_dxdx, str$copy_dx, movc in Macro
all work ok, when source and destination are the same.
Yes, I probably may create something to avoid this problem, but call to
mcc_aes_copy by itself is done to avoid a problem in some of the AMs. How many
work-arounds should I build in a program?
Gene.
| |||||
| 3366.3 | V1.2 does no damage, returns MCC_S_NORMAL | TOOK::T_HUPPER | The rest, as they say, is history. | Thu Jul 16 1992 10:04 | 8 |
You must be using field test code.
Real code is much simpler now. The V1.2 release protects against abuse
of the AES structures if the pointers are the same in the
mcc_aes_copy() call. The code shortcuts to a quick return of
MCC_S_NORMAL in this case.
Ted
| |||||
| 3366.4 | thank you | SWORD1::ES | Eugene Shvartsman | Thu Jul 16 1992 11:57 | 6 |
Thank you, Ted. You are right, we are installing the official realease now. Thanks again, Gene | |||||