rsync.h always including syslog.h even when not used.

[John E. Malmberg]

jw schultz wrote:
> On Sun, Oct 12, 2003 at 12:38:40AM -0400, John E. Malmberg wrote:
> 
>>>
>>>Won't work.  LOG_DAEMON is defined in syslog.h.
>>
>>Didn't there use to be a HAVE_SYSLOG or USE_SYSLOG in the source before?
>  
> Unlikely.  That isn't the sort of thing that gets removed.
> 
>>>>OpenVMS currently does not have a syslog facility, so it does not have a 
>>>>syslog.h.
>>
>>If I put an empty syslog.h in my build directory, than the compiler is 
>>happy, so it does not appear to be a needed header file if you do not 
>>have such a facility.
>>
>>I can use the empty syslog.h, but I was hoping that this could be a 
>>CONFIGURE option, so if and when OpenVMS adds a SYSLOG type facility, it 
>>would pick it up with out the local syslog.h file causing a problem.
> 
> 
> Making it something autoconf detects would be reasonable
> setting a HAVE_SYSLOG.
> 
> 
>>>If you don't have a syslog facility i'd expect you to be
>>>getting link errors.
>>
>>I have not seen any that I could attribute to that.  The only one I am 
>>seeing is for getpass() being missing and I know how to fix that.
> 
> 
> I'm surprised at that.  What about the calls to syslog() and
> openlog() in log.c?

I found out that I was running an edit macro to condionally compile them 
out when LOG_SYSLOG was not defined.  I had forgotten about that.
I am using an editor macro to put the same conditional around the include.

Apparently before the #include was in log.c and not rsync.h.


The MACRO LOG_SYSLOG is being used in the LOADPARAM.C module.

I can probably build a stub to implement a SYSLOG module after I get the 
file transfer working.

>>There does not appear to be any recent CVS snapshots available for 
>>download, so I am going with the 2.5.6 release as a base.
>  
> For a long-term project that may be fairly safe but the
> resulting code would have to be brought up-to-date with CVS
> for patches to be accepted.  Given the diff between 2.5.6
> and CVS head i'd suggest setting yourself use CVS head and
> keep fairly up-to-date.

I am making any of my patches through editor macros, so I can move to 
more upto date snapshots easily.  I expect that 2.5.6 is close enough 
for me to verify simple functinality.

And I can pull down individual modules from CVS before submitting things.

The RSYNC web page implies that the CVS snapshots should be more 
frequent then they are, and this indicates that some automatic process 
is broken.

I am basically down to one unresolved compilier diagnostic.

The HP/COMPAQ/DEC C compiler is concerned about this line in TOKEN.C

    4   22136                   temp_byte = (char) n >> 8;
       ........................................1
    %CC-I-RIGHTSHIFTOVR, (1) In this statement, the right shift count
    "8" is greater than or equal to the size of the unpromoted operand
     "(char)n".


If I am interpreting this right, the value n is an integer, and is being 
cast to be a 8 bit size.  And this results in all the higher bits being 
discarded.  So the >> should shift out all 8 remaining significant bits.

Is this really what is intended?  Or should there be parenthesis around 
(n >> 8) to make sure that it happens first.

The actual assembly code generated is:

        LDL     R10, n           ; R10, 16(FP)
        SLL     R10, 56, R10
        SRA     R10, 63, R10
        STQ     R10, temp_byte   ; R10, 8(FP)

-John
wb8tyw at qsl.network
Personal Opinion Only