stat (AGAIN!)

[John E. Malmberg]

[bcc to:]
Jean-François PIÉRONNE wrote:
>>
>>Then I found that there was a PYTHON version of Rsync, but that the
>>Python port was not operational.  Jean-Francois Pieronne has remedied
>>that for the most part, but I am trying to make things better with it's
>>build.  I hope to be testing pysnc soon.
>>  
> Well, I tend to disagree, Python port is operational,

It is now, thanks to you.  But I was refering to the what was left on 
the web before you started posting the kits again.

So we are not in dissagreement, perhaps a language difference.

> the only known problems are on non-blocking mode socket and into the 
> sprintf port (VMS don't provide snprintf) which appear to not
> correctly format some big number.

The snprintf is coming, and the compiler knows how to optimize it.  It 
already is having problems because the of the name conflict with the 
internal routine and the external routine.  So far these problems are 
not directly visible.

A replacement routine for a broken or missing official UNIX function 
should not have the same symbol name.  This causes problems on OpenVMS 
and some UNIX platforms.  The better the optimizer in the compiler, and 
the better that the platform manages virtual memory, the more likely you 
are to encounter it.

So replacement routine for foobar() from a UNIX library should be 
replaced with my_foobar().  And then the following macro should be used 
in the config.h or equivalent to make sure that the rest of the code 
finds it like below.

#ifndef HAVE_FOOBAR
#ifdef foobar
#undef foobar
#endif
#define foobar my_foobar
#endif

If foobar takes a fixed number of arguments, a macro that specifies them 
is preferred.  This prevents problems if someone decided to name a 
structure or structure member the same name as a function.

#define foobar(a, b, c) my_foobar(a, b, c)

If you do not do this, an optimizing compiler will use it's internal 
knowlege of a routine instead of calling the replacement routine, or you 
may get a duplicate symbol at link time.

The perl port just tripped over this with the last ECO to the C runtime 
library.

> But the current port is based on 2.3 which is still under
> development. Python pysync and rsync.py work but it seem that they
> don't include the server part, only the client part. I have test
> locally these two tools successfully.

Good to hear that they worked locally.  The next step is to see if they 
can be used to keep a local copy of a master open-source library up to date.

-John
wb8tyw at qsl.network
Personal Opinion Only