Mailing List Archive

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From spamassassin-contrib@msquadrat.de 2004-05-31 12:21 -------
I looked at the warning in spamc.c:240 -- the issue the compiler doesn't like
is that transport.port is unsigned short while atoi() returns int. What's the
correct way to fix this? casting to (unsigned short) explicitly?

To get rid of the libspamc.c:8xx we should probably use size_t instead of int
-- is that portable?

libspamc.c:947 isn't avoidable as we need an "endless" loop there.

The other warnings seem to be caused by missing #includes on Windows and some
weird stuff in getop.c at which I didnÄt want to look at ;-)

To avoid the conversion stuff, maybe /W3 is enough?




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From sidney@sidney.com 2004-05-31 14:25 -------
I think the cast to (unsigned short) is correct. It states that we aren't going
to tell the user of their error if they pass in too large a number, but the
resulting behavior is still safe.

size_t is portable and is meant to be used for lengths of buffers, so it is the
right thing to use in these cases. I managed to fix that up on my commute in to
work today instead of studying for my final exam tomorrow (sigh) along with some
cascade effects of other variables that then had to be unsigned.

The missing #includes are just that Windows uses a different #include for read
and write, so I just have to insert that one line in two places that already
have a #ifdef _WIN32 section.

I also took care of some of the getopt.c stuff ... It wasn't that bad.

What's left though, I'm not sure about. There's a library #include that
generates a warning (thank you, Microsoft!). Maybe I should find the compiler
option to exclude that warning. And then there are a number of warnings that a
formal parameter (argument to a function) is never used in the body of the function.

What's the C idiom for saying to not generate a warning for an unused variable?
My brain is too full of languages at the moment to remember. In Lisp it is
(declare (ignore variablename)). Do I have to set the switch to suppress this
warning?






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From sidney@sidney.com 2004-05-31 14:44 -------
Ok, I checked in fixes for all the warnings that I mentioned above that I knew
what to do with. I did not enable the warnings compiler switch in config.pl yet
and I didn't deal with the library #include file that generates a warning or the
unused formal parameter, or the warning generated by the while (1) statement
about using a constant in a conditional (duh -- well, how about a language with
a decent loop syntax!).





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From sidney@sidney.com 2004-05-31 14:48 -------
FYI, /W3 now produces no warnings, so that is an option rather than "fix" any of
the remaining ones.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452

sidney@sidney.com changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED



------- Additional Comments From sidney@sidney.com 2004-05-31 15:50 -------
It looks like the remaining warnings are ones that people generally just disable
using a #pragma. There are command line switches for it in Visual Studio.NET,
but not in VC++ 6.0 so I used the pragmas.

I checked in the changes and the the compiler switch /W4 to compile with
warnings on. I confirmed that it compiles with no warnings under VC++ 6.0 under
Windows XP and under gcc 3.3.1-3 in Cygwin.

I referred to the wrong bug number in the svn log message in both this checkin
and the previous one. The log says 3433 instead of 3452. Whoops.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From spamassassin-contrib@msquadrat.de 2004-05-31 16:13 -------
Good luck with your exams :)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From jm@jmason.org 2004-05-31 17:03 -------
>What's the C idiom for saying to not generate a warning for an unused variable?

(void) varname;



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From sidney@sidney.com 2004-05-31 17:53 -------
I checked in to revision 20723 changes to remove the #pragma for the
unreferenced formal parameter warning and to use the idiom Justin said instead.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From lwilton@earthlink.net 2004-05-31 18:30 -------
Subject: Re: New: compiler warnings in VC++ (Windows) spamc build

> Here is what I get when I add a /W4 switch to the VC++ 5.0 options in
spamc

I'll assume/hope you meant VC 6.0; 5.0 is ancient. Error/warning detection
is considerably better in 6.0 than 5.0.


> replace\getopt.c(36) : warning C4100: 'optstr' : unreferenced formal
parameter
> replace\getopt.c(36) : warning C4100: 'argc' : unreferenced formal
parameter

I would suggest turning this warning off with an appropriate command line
option or pragma. Alternately the approved MS tradition is to use

UNREFERENCED_PARAMETER (argc);

to get around this. Of course that only works if you include "windows.h",
which you may not be doing.

> utils.c(75) : warning C4013: 'read' undefined; assuming extern returning
int
> utils.c(212) : warning C4013: 'write' undefined; assuming extern returning
int

Assuming those aren't local functions, something needs an include of "io.h".

Loren





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From sidney@sidney.com 2004-05-31 18:46 -------
Loren wrote:
> 5.0 is ancient

Yes, as you assumed, "VC++ 5.0" was a typo in the comment, I did mean 6.0.

> UNREFERENCED_PARAMETER (argc);

I ended up using Justin's suggestion of (void) argc; which I think is fine now
that it is in there.

> io.h

Yes, that is what I did for those.

Thanks for looking this over with your Win32-experienced eye.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From lwilton@earthlink.net 2004-05-31 18:50 -------
Subject: Re: compiler warnings in VC++ (Windows) spamc build

> I looked at the warning in spamc.c:240 -- the issue the compiler doesn't
like
> is that transport.port is unsigned short while atoi() returns int. What's
the
> correct way to fix this? casting to (unsigned short) explicitly?

That would be the traditional way to do it, since this is C rather than C++.
If the target is defined as unsigned short in the local code, yes, that is
exactly the right way. If the target is a system-defined function, it is
better to cast to the typedef used for the parameter, if one was used.
Often with Unix-based functions no typedef is used, so (unsigned short) is
the correct answer.


> To get rid of the libspamc.c:8xx we should probably use size_t instead
of int
> -- is that portable?

Yes. At least it should be.


> To avoid the conversion stuff, maybe /W3 is enough?

W3 is usually pretty good, but the couple of casts required in this case for
W4 might be worthwhile. W4 is largely annoying, but it can uncover a few
actual silent errors in code.

Loren





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From lwilton@earthlink.net 2004-05-31 19:00 -------
Subject: Re: compiler warnings in VC++ (Windows) spamc build

> What's left though, I'm not sure about. There's a library #include that
> generates a warning (thank you, Microsoft!). Maybe I should find the
compiler
> option to exclude that warning. And then there are a number of warnings
that a
> formal parameter (argument to a function) is never used in the body of the
function.
>
> What's the C idiom for saying to not generate a warning for an unused
variable?
> My brain is too full of languages at the moment to remember. In Lisp it is
> (declare (ignore variablename)). Do I have to set the switch to suppress
this
> warning?

If you have the right header file included (some subfile included in
windows.h, I don't recall what, you can use

UNREFERENCED_PARAMETER (foo);

C/C++ has no specific syntax for "unreferenced variable" or "unreferenced
parameter". Often you can do something like "if (var);", but that can
generate a warning in itself. "var = var;" is another possibility, as is
simply "var;". All of these might end up generating warnings of their own
however.

A MS-specific choice is to disable the warning:

#pragma warning (<number>:disable)

Where <number> is the warning number in question. If the message says
"C2053: blah", the warning number is 2053, NOT C2053.

Loren






------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From lwilton@earthlink.net 2004-05-31 19:11 -------
Subject: Re: compiler warnings in VC++ (Windows) spamc build

> > UNREFERENCED_PARAMETER (argc);
>
> I ended up using Justin's suggestion of (void) argc; which I think is fine
now
> that it is in there.

Should be fine practically everywhere I suspect. Has the advantage that it
doesn't need to be in compiler-dependent code, so you can just code it in
the clear. (Which you probably did, I assume.)

Loren

> Thanks for looking this over with your Win32-experienced eye.

No problem. Maybe someday I'll figure out how to read perl. :-)

Loren





------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From spamassassin-contrib@msquadrat.de 2004-06-01 00:53 -------
In utils.h we have a macro UNUSED_VARIABLE which does the (void) trick but a
bit more elegant :)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

http://bugzilla.spamassassin.org/show_bug.cgi?id=3452





------- Additional Comments From sidney@sidney.com 2004-06-01 01:26 -------
Malte said:
> we have a macro UNUSED_VARIABLE

I think I need to study for my final exam tomorrow more than I need to do any
more yak shaving, so I'll leave it to you to change the (void)foo instances to
UNUSED_VARIABLE(foo) :-)

(see http://www.ai.mit.edu/lab/gsb/gsb-archive/gsb2000-02-11.html for the
definition of yak shaving, or its reprise in any copy of jargon.txt, The
Hacker's Dictionary)



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.