Subject: Re: some unusual errors
From: [email-masked] (J. J. Farrell)

22 Sep 1998 12:09:21 -0700
Message-ID: <[email-masked]>
References: <[email-masked]>
Content-Type: text
To: [email-masked]
Cc: [email-masked], [email-masked]

> From [email-masked]  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
"[email-masked]" with one line of text: "help".