bug-cvs
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]