Is there any GENRIC MACROS in c for INTEGERS,CHARAC TERS ?

[Durgesh Sharma]

I want to use strrchar(source _string,last_ch ar ) function from
string.h header file,to find out the last occurrence of the NON SPACE
Alphanumeric Character.

Then i will put a NULL CHAR after incrementing that position,receiv ed
by strrchar() function by 1.

This is my idea of Trimming a string from right .

According to the definition of the strrchar function,i am supposed to
provide the string and that character that has to be checked for the
last occurrence.But i want to device a way to check the last
occurrence of a "GENRIC ALPHANUMERIC CHARACTER",rath er than any
specific character.

Have we got any GENERIC Predefined Macro in C ,for
INTEGERS,CHARAC TERS...etc.

Is there any better and fast solution for Right Trimming a Big string
?

Thanks in Advance.

Regards,
shamdurgs

[Bas Wassink]

You can use the functions in "ctype.h" for that:
There's a function called "isalnum" which takes a char as input and
returns an int. It returns non-zero if the char is alphanumeric and zero
otherwise.

Hope this helps..

[Joe Wright]

Durgesh Sharma wrote:

I want to use strrchar(source _string,last_ch ar ) function from
string.h header file,to find out the last occurrence of the NON SPACE
Alphanumeric Character.

Then i will put a NULL CHAR after incrementing that position,receiv ed
by strrchar() function by 1.

This is my idea of Trimming a string from right .

According to the definition of the strrchar function,i am supposed to
provide the string and that character that has to be checked for the
last occurrence.But i want to device a way to check the last
occurrence of a "GENRIC ALPHANUMERIC CHARACTER",rath er than any
specific character.

Have we got any GENERIC Predefined Macro in C ,for
INTEGERS,CHARAC TERS...etc.

Is there any better and fast solution for Right Trimming a Big string
?

Thanks in Advance.

Regards,
shamdurgs

Use mine ..

char * rtrim(char *str) {
char *s, *p; int c;
s = p = str;
while ((c = *s++)) if (!isspace(c)) p = s;
*p = '\0';
return str;
}

--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[infobahn]

Bas Wassink wrote:

You can use the functions in "ctype.h" for that:
There's a function called "isalnum" which takes a char as input and

Actually, like all the functions prototyped in <ctype.h>, isalnum
takes an int, not a char.

The Standard says:

4.3.1.1 The isalnum function

Synopsis

#include <ctype.h>
int isalnum(int c);

Description

The isalnum function tests for any character for which isalpha or
isdigit is true.

[Eric Sosman]

Joe Wright wrote:

Durgesh Sharma wrote:

I want to use strrchar(source _string,last_ch ar ) function from
string.h header file,to find out the last occurrence of the NON SPACE
Alphanumeric Character.

Then i will put a NULL CHAR after incrementing that position,receiv ed
by strrchar() function by 1.

This is my idea of Trimming a string from right .

According to the definition of the strrchar function,i am supposed to
provide the string and that character that has to be checked for the
last occurrence.But i want to device a way to check the last
occurrence of a "GENRIC ALPHANUMERIC CHARACTER",rath er than any
specific character.

Have we got any GENERIC Predefined Macro in C ,for
INTEGERS,CHARAC TERS...etc.

Is there any better and fast solution for Right Trimming a Big string
?

Thanks in Advance.

Regards,
shamdurgs

Use mine ..

char * rtrim(char *str) {
char *s, *p; int c;
s = p = str;
while ((c = *s++)) if (!isspace(c)) p = s;

while ((c = *s++)) if (!isspace((unsi gned char)c)) p = s;

.... or else you can be in deep trouble if `char' is signed.
*p = '\0';
return str;
}

--
Eric Sosman
es*****@acm-dot-org.invalid

[Malcolm]

"Eric Sosman" <es*****@acm-dot-org.invalid> wrote

while ((c = *s++)) if (!isspace(c)) p = s;

while ((c = *s++)) if (!isspace((unsi gned char)c)) p = s;

... or else you can be in deep trouble if `char' is signed.

Personally I regard this as a bug in the standard. It is unacceptable that
the former code is not conforming.

[Joe Wright]

Eric Sosman wrote:

Joe Wright wrote:

[ snip ]

Use mine ..

char * rtrim(char *str) {
char *s, *p; int c;
s = p = str;
while ((c = *s++)) if (!isspace(c)) p = s;

while ((c = *s++)) if (!isspace((unsi gned char)c)) p = s;

... or else you can be in deep trouble if `char' is signed.

*p = '\0';
return str;
}

From N869 ..

#include <ctype.h>
int isspace(int c);

Description

[#2] The isspace function tests for any character that is a
standard white-space character or is one of a locale-
specific set of characters for which isalnum is false. The
standard white-space characters are the following: space
(' '), form feed ('\f'), new-line ('\n'), carriage return
('\r'), horizontal tab ('\t'), and vertical tab ('\v'). In
the "C" locale, isspace returns true only for the standard
white-space characters.

The descriptions of the ctype functions all take int values. I know
that char is converted to int in this case and that if char is
signed and negative, the result is probably a negative int.

So what? Clearly -50 is not space or form feed, tab, etc. and the
expression (isspace(-50) == 0) is true.

What is the case for casting this otherwise negative int to unsigned
char? What 'deep trouble' could happen if I didn't? Why wouldn't the
function be written so as to take any int as advertised?

--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Eric Sosman]

Joe Wright wrote:

Eric Sosman wrote:

Joe Wright wrote:

while ((c = *s++)) if (!isspace(c)) p = s;
while ((c = *s++)) if (!isspace((unsi gned char)c)) p = s;

... or else you can be in deep trouble if `char' is signed.

From N869 ..

#include <ctype.h>
int isspace(int c);

Description

[#2] The isspace function tests for any character that is a
standard white-space character or is one of a locale-
specific set of characters for which isalnum is false. The
standard white-space characters are the following: space
(' '), form feed ('\f'), new-line ('\n'), carriage return
('\r'), horizontal tab ('\t'), and vertical tab ('\v'). In
the "C" locale, isspace returns true only for the standard
white-space characters.

The descriptions of the ctype functions all take int values. I know that
char is converted to int in this case and that if char is signed and
negative, the result is probably a negative int.

... but they don't take "just any" int values; the
argument must be in a restricted range. 7.4, paragraph 1
(I don't have N869 so this is from ISO/IEC 9899:1999,
which is very nearly as good):

"In all cases the argument is an int, the value of
which shall be representable as an unsigned char or
shall equal the value of the macro EOF. If the
argument has any other value, the behavior is
undefined."
So what? Clearly -50 is not space or form feed, tab, etc. and the
expression (isspace(-50) == 0) is true.
isspace(-50) produces undefined behavior unless EOF==-50.
What is the case for casting this otherwise negative int to unsigned
char? What 'deep trouble' could happen if I didn't? Why wouldn't the
function be written so as to take any int as advertised?

Well, "deep trouble" may have been an overstatement on my
part. Undefined behavior, by its very undefinedness, can be
beneficial rather than harmful. Who knows? The experience of
having demons fly out of your nose may be pleasant. ;-)

As to why the functions require a restricted range, I can
think of two likely reasons:

- For speed, the functions are frequently implemented as
macros that do simple array references. isspace() and its
kin just take the argument value, subtract EOF, and use the
difference as an index to an array containing the precomputed
answer. If the argument range were unrestricted, you'd need
an array with INT_MAX-INT_MIN+1 elements, which even with
today's enormous memories would be excessive. A range check
could be introduced, but this is difficult to do in a macro.

- Even with a different implementation strategy you face an
ambiguity when the argument equals EOF: Is it end-of-file or
a legitimate character (e.g., 0xFF on many systems)? Given
the value alone there is no way to tell. The Standard requires
that the legitimate characters be passed as non-negative values
so they can be distinguished from the negative value EOF.

IMHO this is one of those unpleasant little corners in the
language. It seems to me things would have been simpler had
`char' been synonymous with `unsigned char' right from the
start. However, machines disagree on just what should happen
when a byte is fetched from memory into a wider CPU register
for further manipulation: Some machines widen by sign-extending,
some by zero-extending, and some by leaving the pre-existing
high-order register contents unchanged. Requiring `unsigned char'
on all these types of machines (and on others I haven't thought
of) would have imposed a burden of extra instructions on at
least some of them.

And even a universal `unsigned char' would be no panacea.
I have heard tell of machines with 32-bit characters and 32-bit
integers, and I imagine the proper choice of an EOF value on such
machines must involve ugly compromises.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Joe Wright]

Eric Sosman wrote:

Joe Wright wrote:

Eric Sosman wrote:

Joe Wright wrote:

while ((c = *s++)) if (!isspace(c)) p = s;
while ((c = *s++)) if (!isspace((unsi gned char)c)) p = s;

... or else you can be in deep trouble if `char' is signed.

From N869 ..

#include <ctype.h>
int isspace(int c);

Description

[#2] The isspace function tests for any character that is a
standard white-space character or is one of a locale-
specific set of characters for which isalnum is false. The
standard white-space characters are the following: space
(' '), form feed ('\f'), new-line ('\n'), carriage return
('\r'), horizontal tab ('\t'), and vertical tab ('\v'). In
the "C" locale, isspace returns true only for the standard
white-space characters.

The descriptions of the ctype functions all take int values. I know
that char is converted to int in this case and that if char is signed
and negative, the result is probably a negative int.

... but they don't take "just any" int values; the
argument must be in a restricted range. 7.4, paragraph 1
(I don't have N869 so this is from ISO/IEC 9899:1999,
which is very nearly as good):

"In all cases the argument is an int, the value of
which shall be representable as an unsigned char or
shall equal the value of the macro EOF. If the
argument has any other value, the behavior is
undefined."

So what? Clearly -50 is not space or form feed, tab, etc. and the
expression (isspace(-50) == 0) is true.

isspace(-50) produces undefined behavior unless EOF==-50.

What is EOF for in this context? I'm not overly afraid of 'Undefined
Behavior'. isspace(c) is required to return 0 if c (now converted to
int) is not among the 'space' characters. Clearly EOF is not among
the 'space' characters and so 0 must be the result. Right?

What is the case for casting this otherwise negative int to unsigned
char? What 'deep trouble' could happen if I didn't? Why wouldn't the
function be written so as to take any int as advertised?

Well, "deep trouble" may have been an overstatement on my
part. Undefined behavior, by its very undefinedness, can be
beneficial rather than harmful. Who knows? The experience of
having demons fly out of your nose may be pleasant. ;-)

As to why the functions require a restricted range, I can
think of two likely reasons:

- For speed, the functions are frequently implemented as
macros that do simple array references. isspace() and its
kin just take the argument value, subtract EOF, and use the
difference as an index to an array containing the precomputed
answer. If the argument range were unrestricted, you'd need
an array with INT_MAX-INT_MIN+1 elements, which even with
today's enormous memories would be excessive. A range check
could be introduced, but this is difficult to do in a macro.

No, you don't. EOF is a non-event (must return 0) and (c && 0xff)
will give you the index into a 256-byte array of answers to the
questions.
- Even with a different implementation strategy you face an
ambiguity when the argument equals EOF: Is it end-of-file or
a legitimate character (e.g., 0xFF on many systems)? Given
the value alone there is no way to tell. The Standard requires
that the legitimate characters be passed as non-negative values
so they can be distinguished from the negative value EOF.

The Standard requirements for non-negative notwithstanding , having
checked the value for EOF and finding that it is not, mask the value
with 0xff and carry on. Surely.
IMHO this is one of those unpleasant little corners in the
language. It seems to me things would have been simpler had
`char' been synonymous with `unsigned char' right from the
start. However, machines disagree on just what should happen
when a byte is fetched from memory into a wider CPU register
for further manipulation: Some machines widen by sign-extending,
some by zero-extending, and some by leaving the pre-existing
high-order register contents unchanged. Requiring `unsigned char'
on all these types of machines (and on others I haven't thought
of) would have imposed a burden of extra instructions on at
least some of them.

The Standard's mention of 'unsigned char' in this context is
unfortunate. We are talking about values of an int.
And even a universal `unsigned char' would be no panacea.
I have heard tell of machines with 32-bit characters and 32-bit
integers, and I imagine the proper choice of an EOF value on such
machines must involve ugly compromises.

I think it's a question of domains within a range. For 32-bit
unsigned integers, the range of values is 0..4,294,967,29 5. NULL
defined as 0 is within the domain of pointers and EOF as -1 is
outside the domain of characters. Good choices.

--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Eric Sosman]

Joe Wright wrote:

Eric Sosman wrote:

Joe Wright wrote:

[...]
The descriptions of the ctype functions all take int values. I know
that char is converted to int in this case and that if char is signed
and negative, the result is probably a negative int.
... but they don't take "just any" int values; the
argument must be in a restricted range. 7.4, paragraph 1
(I don't have N869 so this is from ISO/IEC 9899:1999,
which is very nearly as good):

"In all cases the argument is an int, the value of
which shall be representable as an unsigned char or
shall equal the value of the macro EOF. If the
argument has any other value, the behavior is
undefined."

So what? Clearly -50 is not space or form feed, tab, etc. and the
expression (isspace(-50) == 0) is true.

isspace(-50) produces undefined behavior unless EOF==-50.

What is EOF for in this context?

EOF is a macro defined in <stdio.h>. Its expansion is
a negative integer constant (usually -1, although the Standard
does not require this). Various I/O functions return EOF to
indicate that something unusual (e.g., end-of-file or I/O
error) has happened.

The <ctype.h> functions accept EOF as an argument value
in addition to all the (non-negative) values of legitimate
characters, presumably because somebody once thought it would
be convenient to do things like

int ch;
/* skip leading spaces */
while (isspace(ch = getchar()))
;
if (ch == EOF)
/* end-of-file or error */ ;
else
/* found a non-space character */ ;

If isspace() didn't accept EOF, you'd need to write

int ch;
/* skip leading spaces */
while ((ch = getchar()) != EOF) {
if (! isspace(ch))
break;
}
if (ch == EOF)
/* end-of-file or error */ ;
else
/* found a non-space character */ ;

Observe that this loop makes two tests per character instead
of the first form's single test. The original inventors of
<ctype.h> were, I guess, offended by the inefficiency of a
two-test loop and saw a way to define the functions so as to
eliminate half the testing. In hindsight, it looks like this
worship of The Little Tin God may have been misplaced -- but
the ANSI committee was asked to codify existing practice, and
they took the bitter with the sweet.
I'm not overly afraid of 'Undefined
Behavior'.
You need not be "overly afraid," just "afraid enough."
isspace(c) is required to return 0 if c (now converted to
int) is not among the 'space' characters.
... and if c is among the permitted values.
Clearly EOF is not among the
'space' characters and so 0 must be the result. Right?
Right.

- For speed, the functions are frequently implemented as
macros that do simple array references. isspace() and its
kin just take the argument value, subtract EOF, and use the
difference as an index to an array containing the precomputed
answer. If the argument range were unrestricted, you'd need
an array with INT_MAX-INT_MIN+1 elements, which even with
today's enormous memories would be excessive. A range check
could be introduced, but this is difficult to do in a macro.

No, you don't. EOF is a non-event (must return 0) and (c && 0xff) will
give you the index into a 256-byte array of answers to the questions.

I don't understand what you mean by "a non-event." You
are right that isspace(EOF) must return zero, but it does not
follow that isspace(negativ e_value_not_equ al_to_EOF) must
return zero, or must even return at all.

Also, take another look at your `c && 0xff' (by which I
imagine you actually meant `c & 0xff'). Let's assume, as you
apparently have, a system with eight-bit characters and two's
complement arithmetic. Let's further assume EOF == -1, which
is the case for most implementations . Then `EOF & 0xff' gives
the value 255 -- but 255 is the code for some perfectly valid
character. If the current locale considers that character as
a space (or as an XXXX for the isXXXX() function), you have the
conflicting requirement that isXXXX(EOF) must return zero but
isXXXX(255) must return non-zero. If the function's first step
is to convert EOF to 255, the distinction can no longer be made.
The Standard requirements for non-negative notwithstanding , having
checked the value for EOF and finding that it is not, mask the value
with 0xff and carry on. Surely.
That would work (on a two's complement eight-bit system).
It is possible that `(unsigned char)c' does exactly this
masking. However, the cast will work on all systems while
your mask will work on only some. Also, on systems where
char is already unsigned, the cast presumably compiles to
a no-op while your cast generates unnecessary code. All
in all, the cast wins on both portability and efficiency.

IMHO this is one of those unpleasant little corners in the
language. It seems to me things would have been simpler had
`char' been synonymous with `unsigned char' right from the
start. However, machines disagree on just what should happen
when a byte is fetched from memory into a wider CPU register
for further manipulation: Some machines widen by sign-extending,
some by zero-extending, and some by leaving the pre-existing
high-order register contents unchanged. Requiring `unsigned char'
on all these types of machines (and on others I haven't thought
of) would have imposed a burden of extra instructions on at
least some of them.

The Standard's mention of 'unsigned char' in this context is
unfortunate. We are talking about values of an int.

Again, I'm not sure what you mean. By "unfortunat e" do you
mean "The Standard is wrong," or do you mean "It's too bad the
pre-Standard <ctype.h> worked this way so the Standard had to
adopt it?"

Note, too, that the int values in question are, specifically,
the value of EOF and the values of unsigned char.
I think it's a question of domains within a range. For 32-bit unsigned
integers, the range of values is 0..4,294,967,29 5. NULL defined as 0 is
within the domain of pointers and EOF as -1 is outside the domain of
characters. Good choices.

For the third time, I fail to understand what you are trying
to say -- but this time, I can't even begin to puzzle it out.

--
Eric Sosman
es*****@acm-dot-org.invalid