[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Feature Branch - Windows Build Broken 4-Sep-2004
From: |
Derek Robert Price |
Subject: |
Re: CVS Feature Branch - Windows Build Broken 4-Sep-2004 |
Date: |
Sat, 04 Sep 2004 20:53:00 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 |
-----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-----