Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c

2004-10-07 Thread Allan Edwards 
Mladen Turk wrote:
[snip]
Both apr and libhttpd has more then 100 of those
when /Wp64 is used, so IMO we would just hide the problems under
carpet if just casting every 64-32 warning found.
Agreed, hiding underlying problems is not acceptable.
I am trying to address the many warnings that a
Win64 build spits out in the correct way, not just
for the sake of suppressing warnings.
For example inside http_protocol.c you have:
(i.e. in the current http_protocol.c code)
'int len = strlen(method)', that is wrong by all means, but I
wouldn't write that as 'int len = (int)strlen(method)' just to make
the compiler happy, but rather use 'size_t len = strlen(method)'.
Agreed. In the patch just posted you'll see mod_win32.c takes the
approach you suggest, as does a patch I have been working on that
addresses http_protocol.c and other warnings. I will be posting
this shortly.
Well, that one is probably OK. I was talking about the concept
of not casting just for the sake of making compiler happy.
Agree.
Thanks, Allan

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c

2004-10-06 Thread Mladen Turk 
[EMAIL PROTECTED] wrote:
ake 2004/10/06 06:33:29
  Modified:modules/arch/win32 mod_win32.c
   server/mpm/winnt service.c
   support/win32 ApacheMonitor.c
  Log:
  WIN64: fix some windows specific 64bit warnings
  -if (!WriteConsole(hConErr, msg, strlen(msg), result, NULL) || !result)
  +if (!WriteConsole(hConErr, msg, (int)strlen(msg), result, NULL) || !result)
  -if (!WriteConsole(hConErr, count, strlen(count), result, NULL) 
  +if (!WriteConsole(hConErr, count, (int)strlen(count), result, NULL) 
  -lstrcpyn(szBuf, szImagePath, sPos - szImagePath);
  +lstrcpyn(szBuf, szImagePath, (int)(sPos - szImagePath));
  -TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, strlen(szBuf)); 
  +TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, (int)strlen(szBuf)); 
Please do not do that any more. I'm sorry but I'm vetoing your patches.
Use the official API, it is well documented.
size_t != int.
Regards,
MT.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c

2004-10-06 Thread Jeff Trawick 
On Wed, 06 Oct 2004 15:52:43 +0200, Mladen Turk [EMAIL PROTECTED] wrote:
 
 
 [EMAIL PROTECTED] wrote:
  ake 2004/10/06 06:33:29
 
Modified:modules/arch/win32 mod_win32.c
 server/mpm/winnt service.c
 support/win32 ApacheMonitor.c
Log:
WIN64: fix some windows specific 64bit warnings
 
-if (!WriteConsole(hConErr, msg, strlen(msg), result, NULL) || !result)
+if (!WriteConsole(hConErr, msg, (int)strlen(msg), result, NULL) || !result)
-if (!WriteConsole(hConErr, count, strlen(count), result, NULL)
+if (!WriteConsole(hConErr, count, (int)strlen(count), result, NULL)
-lstrcpyn(szBuf, szImagePath, sPos - szImagePath);
+lstrcpyn(szBuf, szImagePath, (int)(sPos - szImagePath));
-TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, strlen(szBuf));
+TextOut(lpdis-hDC, XBITMAP + 6, y, szBuf, (int)strlen(szBuf));
 
 Please do not do that any more. I'm sorry but I'm vetoing your patches.
 Use the official API, it is well documented.

strlen() returns size_t, TextOut() requires int; somewhere a cast is
required, no?  what is a better solution?

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c

2004-10-06 Thread Mladen Turk 
Jeff Trawick wrote:
Please do not do that any more. I'm sorry but I'm vetoing your patches.
Use the official API, it is well documented.

strlen() returns size_t, TextOut() requires int; somewhere a cast is
required, no?  what is a better solution?

That's true, but the strlen can never be int (negative).
The API is DWORD meaning 32 bit unsigned integer, so either
cast to API or no cast.
MT.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c

2004-10-06 Thread Jeff Trawick 
On Wed, 06 Oct 2004 16:15:51 +0200, Mladen Turk [EMAIL PROTECTED] wrote:
 Jeff Trawick wrote:
 
 Please do not do that any more. I'm sorry but I'm vetoing your patches.
 Use the official API, it is well documented.
 
 
  strlen() returns size_t, TextOut() requires int; somewhere a cast is
  required, no?  what is a better solution?
 
 
 
 That's true, but the strlen can never be int (negative).
 The API is DWORD meaning 32 bit unsigned integer, so either
 cast to API or no cast.

I'm confused.  The only TextOut() doc I can find says int, not
DWORD.  Can you provide a link?  Here is where I looked:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/fontext_5yd0.asp

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c

2004-10-06 Thread Allan Edwards 
Mladen Turk wrote:
That's true, but the strlen can never be int (negative).
The API is DWORD meaning 32 bit unsigned integer, so either
cast to API or no cast.
You are correct that for WriteConsole the cast should
have been DWORD - I will fix that, thanks
For TextOut and lstrcpyn the parameter is in fact int
so we either have to cast to int and assmume the
string length will never by  2Gig (seems reasonable),
or we need to explicitly check for strlen  2Gig and
fail if it is, or use a different API (if there is one).
What do you suggest?
Allan

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c

2004-10-06 Thread Mladen Turk 
Allan Edwards wrote:
Mladen Turk wrote:
That's true, but the strlen can never be int (negative).
The API is DWORD meaning 32 bit unsigned integer, so either
cast to API or no cast.

You are correct that for WriteConsole the cast should
have been DWORD - I will fix that, thanks
Look, I'm sorry if you found my initial post offending cause
I've used the 'v' word, but the way you've headed would make
almost any CRT lib call casted, and that just doesn't make
sense to me. Both apr and libhttpd has more then 100 of those
when /Wp64 is used, so IMO we would just hide the problems under
carpet if just casting every 64-32 warning found.
For example inside http_protocol.c you have:
'int len = strlen(method)', that is wrong by all means, but I
wouldn't write that as 'int len = (int)strlen(method)' just to make
the compiler happy, but rather use 'size_t len = strlen(method)'.
 For TextOut and lstrcpyn the parameter is in fact int
 so we either have to cast to int and assmume the
 string length will never by  2Gig (seems reasonable),
 or we need to explicitly check for strlen  2Gig and
 fail if it is, or use a different API (if there is one).

Well, that one is probably OK. I was talking about the concept
of not casting just for the sake of making compiler happy.
Regards,
Mladen.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c ApacheMonitor.h ApacheMonitor.rc wintty.c

2004-01-02 Thread Ben Laurie 
[EMAIL PROTECTED] wrote:
nd  2004/01/01 05:26:26
  Log:
  update license to 2004.
Why? Unless the file changes in 2004, the copyright doesn't. And, in any 
case, the earliest date applies, so it gets us nowhere.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html   http://www.thebunker.net/
There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit. - Robert Woodruff

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c ApacheMonitor.h ApacheMonitor.rc wintty.c

2004-01-02 Thread Andr Malo 
* Ben Laurie [EMAIL PROTECTED] wrote:

 [EMAIL PROTECTED] wrote:
  nd  2004/01/01 05:26:26
Log:
update license to 2004.
 
 Why? Unless the file changes in 2004, the copyright doesn't. And, in any 
 case, the earliest date applies, so it gets us nowhere.

It was done for LICENSE 1.0 and 1.1 all the time for some reason. But I
don't know the american copyright rules that well, so I don't really know
the reason Anyone?

nd

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c ApacheMonitor.h ApacheMonitor.rc wintty.c

2004-01-02 Thread Sander Striker 
On Fri, 2004-01-02 at 13:32, Ben Laurie wrote:
 [EMAIL PROTECTED] wrote:
  nd  2004/01/01 05:26:26
Log:
update license to 2004.
 
 Why? Unless the file changes in 2004, the copyright doesn't. And, in any 
 case, the earliest date applies, so it gets us nowhere.

We seem to have this discussion every year.  I'm too lazy to extensively
dig in the archives, but:

http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=79209

Roy:
That would change a lot more, and a lot less, than we want.
 I've committed the change for 2.0 and will do 1.3 next.

Roy, care to explain what it is we want (and more importantly why)?
I promise to mold the answer into a developer FAQ.

Sander

RE: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c ApacheMonitor.h ApacheMonitor.rc wintty.c

2004-01-02 Thread Mladen Turk 
 

 -Original Message-
 From: André Malo [mailto:[EMAIL PROTECTED] 
  
  Why? Unless the file changes in 2004, the copyright 
 doesn't. And, in 
  any case, the earliest date applies, so it gets us nowhere.
 
 It was done for LICENSE 1.0 and 1.1 all the time for some 
 reason. But I don't know the american copyright rules that 
 well, so I don't really know the reason
 

Me neither.

Something like:

This file is covered by the Apache 1.1 license see
http://www.apache.org/licenses/LICENSE for details.

Should be IMHO enough for IQ = 90.
Don't know if the lawyers fall in the range :-).

MT.

Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c ApacheMonitor.h ApacheMonitor.rc wintty.c

2004-01-02 Thread Erik Abele 
On 02.01.2004, at 14:34, Sander Striker wrote:
On Fri, 2004-01-02 at 13:32, Ben Laurie wrote:
[EMAIL PROTECTED] wrote:
nd  2004/01/01 05:26:26
  Log:
  update license to 2004.
Why? Unless the file changes in 2004, the copyright doesn't. And, in  
any
case, the earliest date applies, so it gets us nowhere.
We seem to have this discussion every year.  I'm too lazy to  
extensively
dig in the archives, but:

http://nagoya.apache.org/eyebrowse/ReadMsg? 
[EMAIL PROTECTED]msgNo=79209

Roy:
That would change a lot more, and a lot less, than we want.
 I've committed the change for 2.0 and will do 1.3 next.
Roy, care to explain what it is we want (and more importantly why)?
I promise to mold the answer into a developer FAQ.
IANAL (nor am I Roy, of course) but after reading  
http://www.copyright.gov/circs/circ1.html (especially #noc and #hlc) it  
appears to me that basically the correct way is what Ben suggested  
(only bump year when file changes):

The notice for visually perceptible copies should contain all the  
following three elements:
...
2. The year of first publication of the work. In the case of  
compilations or derivative works incorporating previously published  
material, the year date of first publication of the compilation or  
derivative work is sufficient.
...

On the other hand I don't see any harm in doing the bump in all files  
in one go since one can argue that in the end it's a combined work of  
all the files and we're just stating this in every, single file. So,  
when one file changes, the combined work changes and we've to change  
every file to reflect this fact. Does this make sense?

just my 2c...

Cheers,
Erik