«

On 4/5/2012 12:11 PM, Antoine Leca wrote:
> Hi all,
>
> Nowadays several compilers are issuing warnings when one uses char-typed
> objects as operand of []. While I understand the point behind it with
> respect to char being possible signed, it also annoys me because many
> use of the<ctype.h> functions raise such a warning (through the common
> implementation using the _ctype_ biased array.)
>
> A colleague went on shutting off the warning, by replacing
> #define islower(c) ((int)((_ctype_ + 1)[(c)]& _L))
> with
> #define islower(c) ((int)((_ctype_+1)[(unsigned char)(c)]& _L))
> but I really dislike the fact this is going away from conformance to the
> C Standard, even if using EOF as parameter to an isxxx() macro is "not
> supposed to happen in [our] actual code."

Tell your colleague it's a Very Bad Idea to mask a standardized
library function with a replacement that behaves differently, even if
the difference is oh! so very slight and oh! so very unlikely ever to
be of importance. People rely on printf() to behave in a certain way,
people expect getenv() to behave in a certain way, and people expect
islower() to behave in a certain way. Change that behavior, however
slightly, and you're just begging for a visit from Murphy's minions.

> Do you have better options (in the real world)?

#include <ctype.h>
#define local_islower(x) islower((unsigned char)(x))

Takes care of the transformation your colleague wants, but also (1)
works even on systems where _ctype_ and _L are missing or different,
and (2) alerts the user to the fact that he's using a variant whose
behavior might not be identical to that of the real islower().

--
Eric Sosman
d

On 4/10/2012 1:19 PM, Antoine Leca wrote:
> Eric Sosman wrote in<news:jllkpe$pkg$>:
>> On 4/5/2012 12:11 PM, Antoine Leca wrote:
>>> A colleague went on shutting off the warning, by replacing
>>> #define islower(c) ((int)((_ctype_ + 1)[(c)]& _L))
>>> [...]
>>> Do you have better options (in the real world)?
>>
>> #include<ctype.h>
>> #define local_islower(x) islower((unsigned char)(x))
>>
>> Takes care of the transformation your colleague wants,
>
> Sorry, a detail here is missed; my colleague does not want to transform
> the meaning of the source (which neither him nor I control), he merely
> wanted to shut the compiler up in a quick way.

"That's -- Your -- Funeral!" -- Mr. and Mrs. Sowerberry

You and your colleague take the batteries out of the smoke alarms
at your peril. You may well survive, and snigger at doomsayers like
me, and say "What an old fussbudget!"

Three facts about Cassandra: (1) She invariably prophesied disaster,
(2) nobody ever believed her, and (3) she was always right.

> Tim Rentsch wrote<news:>:
>> Assuming you really want to allow such code and have it not give
>> a warning, I expect
>>
>> #define islower(c) ((int)((_ctype_ + 1)[(c)+0]& _L))
>>
>> would eliminate the warning without changing the semantics.

This is likely to silence the compiler (not certain to, as the
compiler is free to emit any warnings it cares to -- indeed, the very
warning you're fretting over is not required by the Standard). It
does not, however, fix the underlying problem: If the value of `c' is
less than -1, the macro will misbehave. (Replacing `+1' with `-EOF'
would let you imagine you're writing portable code, but it would still
be only an illusion.)

But, hey: "That's -- Your -- Funeral!"

--
Eric Sosman
d

Eric Sosman <> writes:

> On 4/10/2012 1:19 PM, Antoine Leca wrote:
>> Eric Sosman wrote in<news:jllkpe$pkg$>:
>>> On 4/5/2012 12:11 PM, Antoine Leca wrote:
>>>> A colleague went on shutting off the warning, by replacing
>>>> #define islower(c) ((int)((_ctype_ + 1)[(c)]& _L))
>>>> [...]
>>>> Do you have better options (in the real world)?
>>>[snip]
>>
>> Tim Rentsch wrote<news:>:
>>> Assuming you really want to allow such code and have it not give
>>> a warning, I expect
>>>
>>> #define islower(c) ((int)((_ctype_ + 1)[(c)+0]& _L))
>>>
>>> would eliminate the warning without changing the semantics.
>
> This is likely to silence the compiler (not certain to, as the
> compiler is free to emit any warnings it cares to -- indeed, the very
> warning you're fretting over is not required by the Standard). It
> does not, however, fix the underlying problem: If the value of `c' is
> less than -1, the macro will misbehave. (Replacing `+1' with `-EOF'
> would let you imagine you're writing portable code, but it would still
> be only an illusion.) [snip]

It bothers me that you offer a criticism about risk when the
example carries an explicit assumption about being willing
to allow the code in question. However, ignoring that, two
other comments.

1. Clearly the macro definition (both the original and the
replacement) is meant to be implementation dependent. Saying it
isn't portable when it's pretty obviously implementation-specific
seems rather pointless.

2. The statement that the macro will misbehave is wrong.
Certainly it _might_ misbehave, but whether it does depends on
the definition of _ctype_ (even in cases where EOF != -1). (I'm
ignoring the issue of using a reserved identifier since it is not
germane to the central issue and in any case easily avoided.)

It isn't always wrong to write code that is implementation
dependent or implementation specific. Since the OP seems intent
on doing that, it seems better to give advice about how one might
do that successfully, even if also including warnings about the
dangers of doing so. This path also reflects enlightened
self-interest - it's far more likely to people to adopt more
portable techniques if they are shown both methods and arguments
for each, rather than just repeating the "only strictly portable
code" drumbeat.