Re: CVS Feature Branch - Windows Build Broken 4-Sep-2004

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark D. Baushke wrote:

>>Best regards
>>
>>Conrad Pino
>>
>>--------------------Configuration: cvsnt - Win32
Debug--------------------
>>Compiling...
>>add.c
>>admin.c
>>annotate.c
>>buffer.c
>>H:\Conrad\Projects\cvs-1.12\src\buffer.c(2032) : warning C4013:
'fcntl' undefined; assuming extern returning int
>>H:\Conrad\Projects\cvs-1.12\src\buffer.c(2032) : error C2065:
'F_GETFL' : undeclared identifier
>>H:\Conrad\Projects\cvs-1.12\src\buffer.c(2037) : error C2065:
'O_NONBLOCK' : undeclared identifier
>>H:\Conrad\Projects\cvs-1.12\src\buffer.c(2041) : error C2065:
'F_SETFL' : undeclared identifier
>
>
>I don't know how the windows API handles controling stdio for blocking
>versus non-blocking mode. However, all of the fcntl() calls should be
>protected with HAVE_FCNTL macros and the buffer.c.
>
>You might see what happens if you '#define TRUST_OS_FILE_CACHE 1'
>in windows-NT/config.h


Yeah.

>>checkin.c
>>checkout.c
>>classify.c
>>client.c
>>H:\Conrad\Projects\cvs-1.12\src\client.c(3359) : warning C4133:
'function' : incompatible types - from 'struct sockaddr_in *' to
>>'const struct sockaddr *'
>
>
>On some (all?) platforms sockaddr_in and sockaddr may be placed in union
>with each other.
>
>struct sockaddr_in {
>    u_char    sin_len;
>    u_char    sin_family;
>    u_short    sin_port;
>    struct    in_addr sin_addr;
>    char    sin_zero[8];
>};
>
>typedef u_char        sa_family_t;
>typedef    u_int32_t    in_addr_t;    /* base type for internet
address */
>struct in_addr {
>    in_addr_t s_addr;
>};
>struct sockaddr {
>    u_char        sa_len;        /* total length */
>    sa_family_t    sa_family;    /* address family */
>    char        sa_data[14];    /* actually longer; address value */
>};
>
>
>So, it is possible that to clean up this warning, a cast or a union
>should be used.


Is there a header available on Windows that takes care of this?

>>commit.c
>>create_adm.c
>>cvsrc.c
>>diff.c
>>edit.c
>>entries.c
>>error.c
>>exithandle.c
>>H:\Conrad\Projects\cvs-1.12\src\exithandle.c(47) : warning C4028:
formal parameter 1 different from declaration
>>H:\Conrad\Projects\cvs-1.12\src\exithandle.c(47) : warning C4024:
'signals_register' : different types for formal and actual
>>parameter 1
>
>
>My FreeBSD compiler also has this warning. The right way to do it is to
>ensure that there are two forms of cleanup, one for the signal handlers
>and one for atexit. This would make the OpenBSD folks happy as more than
>one has complained that we really need to do things correctly to allow
>for things like "StackGuard" and/or ProPolice to work properly. Having
>separate stub functions would not be that difficult to do if you have
>the energy.


Yeah.  I think the Right Way (tm) to do this may be simply to register
a single signal routine that simply calls exit(), add a signal block
call first thing at the beginning ofeach atexit() handler, then let
the atexit() handler handle everything.  I've been keeping this in
mind and will fix it shortly - I think you are only getting a warning
from this anyhow?  It's been in there awhile.

>>expand_path.c
>>fileattr.c
>>filesubr.c
>>find_names.c
>>hash.c
>>history.c
>>ignore.c
>>import.c
>>H:\Conrad\Projects\cvs-1.12\src\import.c(1627) : warning C4018: '!='
: signed/unsigned mismatch
>>lock.c
>>log-buffer.c
>>H:\Conrad\Projects\cvs-1.12\src\log-buffer.c(174) : warning C4552:
'!=' : operator has no effect; expected operator with side-effect
>
>
>Derek will need to comment, but it appears to me that the second and
third
>clauses of the for loop:
>
>    for (data = buf->data; data = data->next; data != NULL)
>
>are reversed...


Whoops.  Yes.  That code needs to be removed anyhow, I think.  I'll
get to it shortly, but reversing the args should do for now.

>>rcscmds.c
>>recurse.c
>>release.c
>>remove.c
>>repos.c
>>root.c
>>rsh-client.c
>>run.c
>>scramble.c
>>server.c
>>sockerror.c
>>socket-client.c
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(91) : warning C4047:
'function' : 'unsigned int ' differs in levels of indirection
>>from 'int (__cdecl *)(void *,char *,int ,int ,int *)'
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(91) : warning C4024:
'buf_initialize' : different types for formal and actual
>>parameter 1
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(92) : warning C4047:
'function' : 'unsigned int ' differs in levels of indirection
>>from 'int (__cdecl *)(void *,const char *,int ,int *)'
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(92) : warning C4024:
'buf_initialize' : different types for formal and actual
>>parameter 2
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(93) : warning C4113:
'int (__cdecl *)(void *)' differs in parameter lists from 'int
>>(__cdecl *)(void *,char *,int ,int ,int *)'
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(96) : warning C4113:
'void (__cdecl *)(struct buffer *)' differs in parameter lists
>>from 'int (__cdecl *)(void *,int )'
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(96) : warning C4133:
'function' : incompatible types - from 'void (__cdecl *)(struct
>>buffer *)' to 'int (__cdecl *)(void *,int )'
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(97) : warning C4047:
'function' : 'int (__cdecl *)(void *)' differs in levels of
>>indirection from 'struct socket_buffer *'
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(97) : warning C4024:
'buf_initialize' : different types for formal and actual
>>parameter 7
>>H:\Conrad\Projects\cvs-1.12\src\socket-client.c(97) : error C2198:
'buf_initialize' : too few actual parameters
>
>
>Hmmm... this is bad. Derek probably needs to lend a hand.


I'll take a look soon.

Cheers,

Derek

- --
                *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBOmNrLD1OTBfyMaQRAhScAJ9A/RrCsob49igyX+vOCAjE3UHmIgCePFc6
8VeFOdAICWSXtLM8xFqLZ/o=
=2r38
-----END PGP SIGNATURE-----