From: jjf AT bcs DOT org DOT uk (J. J. Farrell) Subject: Re: some unusual errors 22 Sep 1998 12:09:21 -0700 Message-ID: <199809212009.NAA00026.cygnus.gnu-win32@aleph.ssd.hal.com> References: <9809211418 DOT AA12875 AT vviuh221 DOT vvi DOT com> Content-Type: text To: dyoung AT vviuh221 DOT vvi DOT com Cc: mcr AT solidum DOT com, gnu-win32 AT cygnus DOT com > From dyoung AT vviuh221 DOT vvi DOT com Mon Sep 21 07:09:45 1998 > > > isspace() takes an int whose value must be in the range 0 to > > ... > > it should be casting the parameter to int so it will ... > > ACK! > > Doesn't the ANSI isspace() prototype definition take type char ? > > Why be non-ANSI compliant? > Instead of changing the macro, why not change the function prototype itself. I think you've misunderstood something - my apologies if I was unclear. A Standard C library is required to include a function implementation of all its interfaces, and may optionally also provide a macro version. The caller was passing a char to isspace() and receiving complaints from the compiler which seemed to be due to this char being used as an array subscript in the macro expansion. isspace() is prototyped as isspace(int); if the caller were using the function version (either by doing an '#undef isspace' before calling it, or calling it in a way which suppresses the macro expansion, such as (isspace)(whatever)), then the prototype would be effective, and the char would have been silently and correctly widened to an int. He used the macro version, so the function prototype isn't relevant, and it seems that this version of the macro doesn't do the conversion to int which would have been done if he had used the function version. After a brief look, I can't find any wording in the Standard that requires a macro implementation to convert its parameters in the same way that the function version does; and a look at another implementation shows that it doesn't cast the parameter either. However, as a Quality of Implementation issue, I think that the macro implementations should do all they reasonably can to behave in the same way as the function implementations, and it is trivial in this case for the macro to cast its parameter to an int. This is particularly true when the compiler can be made to issue entirely spurious warnings about a char being used as an array subscript! - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".