Re: [Bug-tar] paxutils: rmt.c missing va_end()

[Joerg Schilling]

Pavel Raiskup <address@hidden> wrote:

> Hi,
>
> please consider fixing rmt_write function:
>
>   rmt_write (const char *fmt, ...)
>   {
>     va_list ap;
>     va_start (ap, fmt);
>     vfprintf (stdout, fmt, ap);
>     // missing va_end
>     fflush (stdout);
>     VDEBUG (10, "S: ", fmt, ap);
>     // potential re-use of 'ap' (requires new va_start)
>   }
>
> the first issue is not a problem in GNU/Linux GCC/Glibc ecosystem, but
> still it seems to be good candidate for fix for compatibility.

The biggest problem with the grmt implementation is that it is still just a 
rewrite of the 1981 protocol and nobody did ever try to implement the current
rmt protocol.

While this protocol was bad in 1981 already, it was not a problem, since 
"everybody" who used it had a Vax-11/780 running UNIX.

Today, we have different CPUs and it is an anacronism to believe that sending 
raw binary data over the wire still works.

Today, we have Linux and the Linux people ignored the rules for MTIO opcodes.
As a result, there is no grant that the right MTIO opcode is executed on the 
remote side. A simple "rewind" could execute a "erase" on the remote side...

If you like to be sure that no strange things happen and there is a working 
abstraction from CPU and OS, you need to use librmt and the rmt command from 
star.

Jörg

-- 
 EMail:address@hidden                    (home) Jörg Schilling D-13353 Berlin
    address@hidden (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'