delorie.com/archives/browse.cgi | search |
Mailing-List: | contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm |
Sender: | cygwin-owner AT sourceware DOT cygnus DOT com |
Delivered-To: | mailing list cygwin AT sourceware DOT cygnus DOT com |
Message-Id: | <199906090134.SAA07555@aleph.ssd.hal.com> |
Subject: | Re: tolower function |
To: | cygwin AT sourceware DOT cygnus DOT com |
Date: | Tue, 8 Jun 1999 18:34:50 -0700 (PDT) |
In-Reply-To: | <001401beb20e$c71e4a90$e145ce84@ECE.McGill.CA> from "Peter Kabal" at Jun 8, 99 08:26:55 pm |
From: | "J. J. Farrell" <jjf AT bcs DOT org DOT uk> |
X-Mailer: | ELM [version 2.4 PL23] |
> From: "Peter Kabal" <kabal AT ece DOT mcgill DOT ca> > > In an early version of a function to convert a string to lowercase, I did > not properly convert the input (signed) characters to unsigned before > handing them off to the tolower function. I discovered that tolower behaves > oddly for negative input values. For instance tolower(-32) returns zero, > while tolower(-31) returns -31. > > Perhaps tolower should be fixed to behave "properly" for "improper" inputs. That's easily done by defining it's current behaviour as proper, as an extension to C! The value of the parameter to the ctype functions must be representable as an unsigned char, or must be EOF. Any other value results in undefined behavior. Contributors efforts are probably better spent enhancing the functionality rather than extending standard interfaces to make incorrect code behave in some predictable way. -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |