[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CVS Feature Branch - Problem File - src/server.c
From: |
Conrad T. Pino |
Subject: |
RE: CVS Feature Branch - Problem File - src/server.c |
Date: |
Wed, 8 Sep 2004 15:36:54 -0700 |
Another two (2) cents follows in line below:
> -----Original Message-----
> From: bug-cvs-bounces+conrad=pino.com@gnu.org
> [mailto:bug-cvs-bounces+conrad=pino.com@gnu.org]On Behalf Of Derek
> Robert Price
> Sent: Wednesday, September 08, 2004 12:05
> To: Mark D. Baushke
> Cc: Bug CVS; Conrad T. Pino
> Subject: Re: CVS Feature Branch - Problem File - src/server.c
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark D. Baushke wrote:
>
> > Conrad T. Pino <Conrad@Pino.com> writes:
> >
> > >Look line file "src/server.c" is "broken" in a way that's not clear.
> > >The "blank line" problem I attempted to fix appears to be back.
> >
> > >Out of time, have an appointment, will report more later.
> >
> >
> > Hmmm... there are no such characters in the file on UNIX boxen
> > checkouts. Just the standard 0x0a newline at the end of the line:
> >
> > #if defined(SERVER_SUPPORT) || defined(CLIENT_SUPPORT)
> >
> > Could it be that the compiler does not like the #if line itself to have
> > multiple defined lines? Are we looking at a different problem in the cvs
> > client used for checkout?
>
>
> That's certainly an odd place to be seeing a new error. According to
> `cvs annotate', that line has been around since 1995. Could another
> error be cascading? Could something about your setup have added the
> bad character? Could some #define change have allowed new sections of
> the code to be compiled on Windows when they weren't before?
>
> It sounds like maybe your compiler was expecting a Windows EOL (\r\n)
> and found a UNIX one (\n, or 0x0a). Is your client set to check out
> with UNIX EOLs (WinCVS and the stock CVS client compiled under Cygnus
> of MKS is capable of this, but the stock CVS client compile Win32 will
> not do this)? Perhaps the UNIX-like diff tool you used is a little
> too UNIX-like and converted your line endings to \n while it was working?
I believe the VC6 compile is lying about the "0xA0" character. My hexadecimal
dump utility says the alleged character just isn't there:
022F00: 5F 63 6C 6F 73 65 6C 6F - 67 20 28 70 72 6F 78 79 _closelog (proxy
022F10: 5F 6C 6F 67 29 3B 0D 0A - 09 6C 6F 67 5F 62 75 66 _log);...log_buf
022F20: 66 65 72 5F 63 6C 6F 73 - 65 6C 6F 67 20 28 70 72 fer_closelog (pr
022F30: 6F 78 79 5F 6C 6F 67 5F - 6F 75 74 29 3B 0D 0A 09 oxy_log_out);...
022F40: 70 72 6F 78 79 5F 6C 6F - 67 20 3D 20 4E 55 4C 4C proxy_log = NULL
022F50: 3B 0D 0A 20 20 20 20 7D - 0D 0A 23 65 6E 64 69 66 ;.. }..#endif
022F60: 20 2F 2A 20 50 52 4F 58 - 59 5F 53 55 50 50 4F 52 /* PROXY_SUPPOR
022F70: 54 20 2A 2F 0D 0A 7D 0D - 0A 0D 0A 0D 0A 0D 0A 73 T */..}........s
022F80: 74 61 74 69 63 20 76 6F - 69 64 20 73 65 72 76 65 tatic void serve
022F90: 5F 76 61 6C 69 64 5F 72 - 65 71 75 65 73 74 73 20 _valid_requests
022FA0: 28 63 68 61 72 20 2A 61 - 72 67 29 3B 0D 0A 0D 0A (char *arg);....
022FB0: 23 65 6E 64 69 66 20 2F - 2A 20 53 45 52 56 45 52 #endif /* SERVER
022FC0: 5F 53 55 50 50 4F 52 54 - 20 2A 2F 0D 0A 23 69 66 _SUPPORT */..#if
^^^^^^^^^^^^^^
022FD0: 20 64 65 66 69 6E 65 64 - 28 53 45 52 56 45 52 5F defined(SERVER_
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
022FE0: 53 55 50 50 4F 52 54 29 - 20 7C 7C 20 64 65 66 69 SUPPORT) || defi
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
022FF0: 6E 65 64 28 43 4C 49 45 - 4E 54 5F 53 55 50 50 4F ned(CLIENT_SUPPO
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
023000: 52 54 29 0D 0A 2F 2A 0D - 0A 20 2A 20 50 61 72 74 RT)../*.. * Part
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
023010: 73 20 6F 66 20 74 68 69 - 73 20 74 61 62 6C 65 20 s of this table
023020: 61 72 65 20 73 68 61 72 - 65 64 20 77 69 74 68 20 are shared with
023030: 74 68 65 20 63 6C 69 65 - 6E 74 20 63 6F 64 65 2C the client code,
023040: 0D 0A 20 2A 20 62 75 74 - 20 74 68 65 20 63 6C 69 .. * but the cli
023050: 65 6E 74 20 64 6F 65 73 - 6E 27 74 20 6E 65 65 64 ent doesn't need
023060: 20 74 6F 20 6B 6E 6F 77 - 20 61 62 6F 75 74 20 74 to know about t
023070: 68 65 20 68 61 6E 64 6C - 65 72 0D 0A 20 2A 20 66 he handler.. * f
023080: 75 6E 63 74 69 6F 6E 73 - 2E 0D 0A 20 2A 2F 0D 0A unctions... */..
023090: 0D 0A 73 74 72 75 63 74 - 20 72 65 71 75 65 73 74 ..struct request
0230A0: 20 72 65 71 75 65 73 74 - 73 5B 5D 20 3D 0D 0A 7B requests[] =..{
0230B0: 0D 0A 23 69 66 64 65 66 - 20 53 45 52 56 45 52 5F ..#ifdef SERVER_
0230C0: 53 55 50 50 4F 52 54 0D - 0A 23 64 65 66 69 6E 65 SUPPORT..#define
0230D0: 20 52 45 51 5F 4C 49 4E - 45 28 6E 2C 20 66 2C 20 REQ_LINE(n, f,
0230E0: 73 29 20 7B 6E 2C 20 66 - 2C 20 73 7D 0D 0A 23 65 s) {n, f, s}..#e
0230F0: 6C 73 65 0D 0A 23 64 65 - 66 69 6E 65 20 52 45 51 lse..#define REQ
> Cheers,
>
> Derek
I'm rebooting the development system. With Windoz you never know what that
might fix.
I've got another appoitment, gotta run.
Conrad