Hello Craig,
It appears that there is something wrong with nntp.perl.org so until
this evening I have limited access to e-mails.
I've attached a patch which I'm still testing that addresses this and
a couple of other stat-related nits. After applying it, I don't get
the accvio when running the stat.t test any more. I'm not entirely
convinced we've found the bug, as copying 8 bytes when we only needed
6 should have just put the first 2 bytes of the st_mode field into
the high word of our rvn field where it would never be seen. We
probably need a more thorough review of alignment settings and such.
Depending on the build options, the size of struct stat varies greatly.
I have found about 14 different variants. Most of the struct stat
variants have either a 64 bit ino_t field or are padding it with a 16
bit filler field.
With the _USE_STD_STAT, the ino_t value is scaler and must be passed by
address with the & prefix. With out it, the ino_t value is an array and
does not need the & prefix. While the & prefix is superfluous on an
array, if someone does the same thing with a pointer, it greatly changes
the meaning.
That is why I had the two separate syntaxes.
-#ifdef _USE_STD_STAT
- memcpy(&statbufp->st_ino, &statbufp->crtl_stat.st_ino, 8);
-#else
- memcpy(&statbufp->st_ino, statbufp->crtl_stat.st_ino, 8);
-#endif
This could be wrapped in a macro for COPY_INO_T(x,y) and CMP_INO_T(x,y)
to make the code more readable, where memcpy and memcmp are only used
when the st_ino is an array type.
Such a macro could be put in vmsish.h to remove the tests for
_USE_STD_STAT from vms.c.
In any case, the memcpy should not be the cause of the access violation
unless the ranges were overlapping.
Obviously the st_fab_mrs member is not being referenced or the compiler
would have caught my typo.
-John
[EMAIL PROTECTED]
Personal Opinion Only
