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

[Joe Wright]

Eric Sosman wrote:

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.

OK, the function prototype looks like ..

int isspace(int c);

... and is described as returning 0 unless c is among the 'space'
characters, otherwise non-zero.

I can read. The Standard's requirement that c, if not EOF be
positive in the range of unsigned char is unnecessary. If the value
of c is not one of 'white-space' characters the function must return
0. It is onerous to require (unsigned char) cast to c. The Standard
should remove the requirement. P.J. and I can take care of it. :-)

About NULL and EOF.
It is interesting and useful to have a pointer value which can be
known to be 'invalid'. What would you pick that value to be? A
pointer value is usually a memory address and we can't know how much
memory the host machine will have. Zero is a good choice.

If we need an EOF value outside the domain of any character, -1 is
perfect.

I mean that within the range of 32-bits, NULL is in the pointer
domain, as it should be, and EOF is out of the character domain as
it should be.

Whether you agree or not, surely you understand. ?
--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

Joe Wright <jo********@com cast.net> writes:
[...]

OK, the function prototype looks like ..

int isspace(int c);

.. and is described as returning 0 unless c is among the 'space'
characters, otherwise non-zero.

I can read. The Standard's requirement that c, if not EOF be positive
in the range of unsigned char is unnecessary. If the value of c is not
one of 'white-space' characters the function must return 0. It is
onerous to require (unsigned char) cast to c. The Standard should
remove the requirement. P.J. and I can take care of it. :-)

isspace() invokes undefined behavior for arguments other than EOF and
values within the range of unsigned char. This allows it to be
implemented as a simple array lookup (after adding 1 to the argument,
assuming EOF==-1). Take a look at your system's <ctype.h> header
(assuming it's implemented as a file).

Requiring isspace() to return 0 for all other arguments, rather than
invoking undefined behavior, would require an addition test before the
array indexing operation. This would hurt performance (marginally)
for all the existing programs that use isspace() properly. The only
benefit would be avoidance of undefined behavior for programs passing
nonsensical values to isspace().

On the other hand, it would make more sense (IMHO) for isspace() to
take an argument of type char, and to drop the wording about EOF. But
isspace() was designed before the invention of prototypes, so a char
argument was promoted to int anyway. And making this kind of change
now would break existing code.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

Keith Thompson <ks***@mib.or g> wrote:

On the other hand, it would make more sense (IMHO) for isspace() to
take an argument of type char, and to drop the wording about EOF. But
isspace() was designed before the invention of prototypes, so a char
argument was promoted to int anyway. And making this kind of change
now would break existing code.

There's another reason: isspace() and friends take the same kind of
argument (int, with a value of unsigned char or EOF) that getchar()
returns. I can't help but think that this is intentional. It can
certainly be very useful.

Richard

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Keith Thompson <ks***@mib.or g> wrote:

On the other hand, it would make more sense (IMHO) for isspace() to
take an argument of type char, and to drop the wording about EOF. But
isspace() was designed before the invention of prototypes, so a char
argument was promoted to int anyway. And making this kind of change
now would break existing code.

There's another reason: isspace() and friends take the same kind of
argument (int, with a value of unsigned char or EOF) that getchar()
returns. I can't help but think that this is intentional. It can
certainly be very useful.

The only case I can think of where it makes a real difference is
isspace(EOF), which I don't find particularly useful. (And of course
all this applies equally to the rest of the is*() functions.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Eric Sosman]

Keith Thompson wrote:

isspace() invokes undefined behavior for arguments other than EOF and
values within the range of unsigned char. This allows it to be
implemented as a simple array lookup (after adding 1 to the argument,
assuming EOF==-1). Take a look at your system's <ctype.h> header
(assuming it's implemented as a file).

A "tolerant" implementation on a system where `char'
is signed might define EOF as CHAR_MIN-1 instead of the
traditional -1. It could then duplicate half of each
array used by the <ctype.h> functions so as to deliver
the right answer even when handed an unconverted (and
possibly negative) `char' value as an argument. For
example, on a system with 8-bit `char' and two's
complement arithmetic,

array[0] : value for EOF (-129)
array[1-128] : values for 0x80,0x81,...,0 xFF
array[129-256] : values for 0x00,0x01,...,0 x7F
array[257-368] : values for 0x80,0x81,...,0 xFF

The Standard does not require this, but it might be
a "friendly gesture" on machines with character sets that
are not too large. Is anyone aware of an implementation
that uses such a trick?

--
Er*********@sun .com

[Keith Thompson]

Eric Sosman <er*********@su n.com> writes:

Keith Thompson wrote:

isspace() invokes undefined behavior for arguments other than EOF and
values within the range of unsigned char. This allows it to be
implemented as a simple array lookup (after adding 1 to the argument,
assuming EOF==-1). Take a look at your system's <ctype.h> header
(assuming it's implemented as a file).

A "tolerant" implementation on a system where `char'
is signed might define EOF as CHAR_MIN-1 instead of the
traditional -1. It could then duplicate half of each
array used by the <ctype.h> functions so as to deliver
the right answer even when handed an unconverted (and
possibly negative) `char' value as an argument. For
example, on a system with 8-bit `char' and two's
complement arithmetic,

array[0] : value for EOF (-129)
array[1-128] : values for 0x80,0x81,...,0 xFF
array[129-256] : values for 0x00,0x01,...,0 x7F
array[257-368] : values for 0x80,0x81,...,0 xFF

The Standard does not require this, but it might be
a "friendly gesture" on machines with character sets that
are not too large. Is anyone aware of an implementation
that uses such a trick?

I don't know, but I mistrust such "friendly" gestures. Generating
meaningful results for code that will break on other implementations
isn't what I call friendly. It makes it more difficult to detect
non-portable code.

If the <ctype.h> facility could be redesigned *in the standard* to be
less error-prone, that would be fine. The problem is when a single
implementation does this.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Joe Wright]

Keith Thompson wrote:

Joe Wright <jo********@com cast.net> writes:
[...]

OK, the function prototype looks like ..

int isspace(int c);

.. and is described as returning 0 unless c is among the 'space'
characters, otherwise non-zero.

I can read. The Standard's requirement that c, if not EOF be positive
in the range of unsigned char is unnecessary. If the value of c is not
one of 'white-space' characters the function must return 0. It is
onerous to require (unsigned char) cast to c. The Standard should
remove the requirement. P.J. and I can take care of it. :-)

isspace() invokes undefined behavior for arguments other than EOF and
values within the range of unsigned char. This allows it to be
implemented as a simple array lookup (after adding 1 to the argument,
assuming EOF==-1). Take a look at your system's <ctype.h> header
(assuming it's implemented as a file).

Thank you for making me do just that.
Requiring isspace() to return 0 for all other arguments, rather than
invoking undefined behavior, would require an addition test before the
array indexing operation. This would hurt performance (marginally)
for all the existing programs that use isspace() properly. The only
benefit would be avoidance of undefined behavior for programs passing
nonsensical values to isspace().

On the other hand, it would make more sense (IMHO) for isspace() to
take an argument of type char, and to drop the wording about EOF. But
isspace() was designed before the invention of prototypes, so a char
argument was promoted to int anyway. And making this kind of change
now would break existing code.

Now that I think about it (thanks for telling me what to think) I
don't have a problem with the Standard's UB warning.

But, is*(int c) makes it possible to accept EOF outside the
character domain and characters as well. But the macro ..

#define is*(c) (ctype[((c)&255)+1] & *)

... limits the index 0..256 regardless the int value of c.

So, my original point, casting the argument to is*() to unsigned
char serves no purpose. You don't need to do it. Ever.

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

[Keith Thompson]

Joe Wright <jo********@com cast.net> writes:
[...]

But, is*(int c) makes it possible to accept EOF outside the character
domain and characters as well. But the macro ..

#define is*(c) (ctype[((c)&255)+1] & *)

.. limits the index 0..256 regardless the int value of c.
Sure, if that's the way your implementation defines it.
So, my original point, casting the argument to is*() to unsigned char
serves no purpose. You don't need to do it. Ever.

I think the example we were talking about upthread involved passing
characters extracted from a string to one of the is*() functions.
Here's a little program I just threw together. It's intended to print
the number of digits in each of its command-line arguments.

#include <stdio.h>
#include <ctype.h>

static int count_digits(ch ar *s)
{
int result = 0;
int i;
for (i = 0; s[i] != '\0'; i ++) {
if (isdigit(s[i])) { /* PROBLEM HERE */
result ++;
}
}
return result;
}

int main(int argc, char **argv)
{
int i;

for (i = 1; i < argc; i ++) {
printf("\"%s\" has %d digit(s)\n",
argv[i],
count_digits(ar gv[i]));
}
return 0;
}

Let's assume CHAR_BIT==8, and plain char is signed. Suppose one of
the arguments contains the character '\xe9' (233 decimal). As a
signed character, its value is -23. isdigit(-23) invokes undefined
behavior. (A given implementation may define isdigit() in such a way
that it doesn't cause any problems, but it's still undefined behavior.)

Changing the condition
isdigit(s[i])
to either
isdigit((unsign ed char)s[i])
or
isdigit((unsign ed)s[i])
avoids the undefined behavior.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[pete]

Joe Wright wrote:

So, my original point, casting the argument to is*() to unsigned
char serves no purpose. You don't need to do it. Ever.

If you have a negative integer value, like

#define NEG_5 ('5' - 1 - (unsigned char)-1)

then
isdigit((unsign ed char)NEG_5)
will return true, as it should, since
putchar(NEG_5)
will return '5'.

--
pete

[Thomas Stegen]

Eric Sosman wrote:

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. ;-)

Well, a succubus is a type of demon. I am just speculating of
course. ;)

--
Thomas.