[Info-vax] ACL-reading mystery -- Big ACL v. ATR$S_READACL

[SMS]

   So, if I were to do a QIO with IO$_ACCESS and ATR$C_READACL
(on a disk file) to get less than all of a big ACL, is there
anything which will tell me how many good bytes I got?

   Background: A victim complaint has revealed that "ZIP -V"
doesn't do ACLs right.  ("fib$l_aclctx?  What's fib$l_aclctx?"
"fib$l_acl_status?  What's fib$l_acl_status?")  ATR$C_ACLLENGTH
gets you the real ACL size, but ATR$S_READACL is only 512
(bytes), so a big ACL might not fit in the "Maximum Size"
buffer.  The docs say that ATR$C_READACL "Reads the entire ACL
or as much as will fit in the supplied buffer.  Only complete
ACEs are transferred."  (And reality seems to agree.)  So, if
the ACEs which fit are smaller than 512 bytes, there'll be some
dead space at the end of the buffer.  I can scan the buffer ACE
by ACE until I hit a zero byte count (or end-of-buffer (512
bytes)), but if there's a clever way to get the size of the
ACL data returned, that'd be simpler, faster, and generally
more elegant.  Unfortunately, if there is such a way, I haven't
spotted it.  ("fib$l_acl_status" is not "fib$l_acl_iosb".)
Anyone have greater wisdom, or is the tedious way the only way?