Re: how to shut up warnings about char-indexing

Discussion in 'C Programming' started by Eric Sosman, Apr 6, 2012.

  1. Eric Sosman

    Eric Sosman Guest

    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
     
    Eric Sosman, Apr 6, 2012
    #1
    1. Advertising

  2. Eric Sosman

    Eric Sosman Guest

    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, Apr 11, 2012
    #2
    1. Advertising

  3. Eric Sosman

    Tim Rentsch Guest

    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.
     
    Tim Rentsch, May 7, 2012
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. C
    Replies:
    0
    Views:
    503
  2. Steve
    Replies:
    0
    Views:
    459
    Steve
    Jan 31, 2006
  3. Emin
    Replies:
    4
    Views:
    411
    Paul McGuire
    Jan 12, 2007
  4. lovecreatesbeauty
    Replies:
    1
    Views:
    1,061
    Ian Collins
    May 9, 2006
  5. Harald van Dijk

    Re: how to shut up warnings about char-indexing

    Harald van Dijk, Apr 5, 2012, in forum: C Programming
    Replies:
    5
    Views:
    383
    Harald van Dijk
    Apr 10, 2012
Loading...

Share This Page