Re: cvs commit: httpd-2.0/support/win32 ApacheMonitor.c
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
[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
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
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
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
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
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
[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
* 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
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
-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
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