very much new to c need ur help

C

CBFalconer

santosh said:
Also the word "some" is indeed important. I can say that the
double sig is snipped out in it's entirety by KNode, Pan,
SeaMonkey and Thunderbird.

Also note that this is all launched by that notorious troll,
<[email protected]>. Just one of many Richards, but trouble.
 
C

Charlie Gordon

CBFalconer said:
No, this is an equality check, not a comparison. The evils never
arise.

For my definition of "evils", they do.
You just may have a point here. My argument is that the value is
known to be positive, and by definition the unsigned and int
representations of positive int values are identical. EOF is never
passed.

But it would be more efficient if it did: ``while (isdigit(ch = getc(fp)))
{ ... }'' uses a single test and will stop at EOF if ch is an int.
... snip ...
Consider for example the following classic implementation of isdigit:

#define EOF (-1)
extern unsigned char __ctype_flags[UCHAR_MAX + 2];
#define __C_DIGIT 1
#define isdigit(c) (__ctype_flags[(c) + 1] & __C_DIGIT)

On platforms where size_t is larger than unsigned int (both windows
and linux 64 bit), invoking isdigit with (unsigned)EOF will invoke
undefined behaviour.

But you forget that isdigit expects to receive an int, that EOF has
been removed, and that unsigned ints have the identical
representation as positive ints.

I do not forget this, I show an example of how isdigit((unsigned)EOF) could
fail. Your code does not invoke that.
NIT - I specifically use getc, so that it can be a macro invocation
and thus can be much quicker than a system function call.

It should be. Alas it often os not anymore because of thread support.
I'm not bothering to check it out now, but unsigned int is needed
for proper range checking. I think the only fault is the
replacement of > with <.


No problem with EOF, because if getc returned EOF the subtraction
(and addition) of '0' does not occur.

The problem with EOF is the overflow: (int)(unsigned)EOF causes integer
overflow.
Which is why I added the comment :)


I trust I have answered your objections. I think everything is
covered.

Not really.
 
P

pete

Joe said:
pete, Please expand on the case for INT_MAX == UINT_MAX.

It's the case where M equals N,
for the below quoted description of M and N from the standard.
I think that
int and unsigned int are the same width (in bits). The int must have a
single sign bit, not a value bit. Given a 32-bit int, int has 31 value
bits and unsigned int has 32.
UINT_MAX == (unsigned)INT_MAX*2+1 it would seem.

N869
6.2.6.2 Integer types
[#2] For signed integer types, the bits of the object
representation shall be divided into three groups: value
bits, padding bits, and the sign bit. There need not be any
padding bits; there shall be exactly one sign bit. Each bit
that is a value bit shall have the same value as the same
bit in the object representation of the corresponding
unsigned type (if there are M value bits in the signed type
and N in the unsigned type, then M<=N).
 
P

pete

pete said:
Joe said:
pete, Please expand on the case for INT_MAX == UINT_MAX.

It's the case where M equals N,
for the below quoted description of M and N from the standard.
I think that
int and unsigned int are the same width (in bits). The int must have a
single sign bit, not a value bit. Given a 32-bit int, int has 31 value
bits and unsigned int has 32.
UINT_MAX == (unsigned)INT_MAX*2+1 it would seem.

N869
6.2.6.2 Integer types
[#2] For signed integer types, the bits of the object
representation shall be divided into three groups: value
bits, padding bits, and the sign bit. There need not be any
padding bits; there shall be exactly one sign bit. Each bit
that is a value bit shall have the same value as the same
bit in the object representation of the corresponding
unsigned type (if there are M value bits in the signed type
and N in the unsigned type, then M<=N).

I suppose I could expand a little more.
If M equals N, and if INT_MIN != INT_MAX,
then signed int has twice the range of unsigned.
And in the case where signed int has twice the range of unsigned,
each unsigned value compares equal to two distinct signed values
which cannot be disambiguated by examining the unsigned value.

CHAR_BIT == 32
INT_MAX == 0xffffffff
UINT_MAX == INT_MAX
sizeof(int) == 2

If the above four conditions are true then:
Each of the unsigned int values, except 0u,
compares equal to two distinct signed int values.
If INT_MIN doesn't equal INT_MAX,
then 0u compares equal to 0
and 0u also compares equal to INT_MIN;
But if INT_MIN equals INT_MAX,
then 0u only compares equal to 0;

A fact that I memorized from having implemented itoa
as an academic exercize, is that INT_MAX
is the minumum guaranteed range of type unsigned.
 
P

pete

CBFalconer said:
If you look back at the original code the controlling expression is
approximately:

while (EOF != (ch = getc(f))) {
....
}

and everything you are talking about is within the .... where the
value of EOF can never arise.

That's the problem.
getc can return a positive value that compares equal to EOF
and the loop can stop before it's supposed to stop.

If these conditions are true:
CHAR_BIT == 32
sizeof(int) == 2
INT_MAX == 0xffffffff
UINT_MAX == INT_MAX
EOF == ('A' - 1 - (unsigned char)-1)
Then:
(unsigned)EOF compares equal to 'A'.
 
C

CBFalconer

pete said:
CBFalconer wrote:
.... snip ...


That's the problem.
getc can return a positive value that compares equal to EOF
and the loop can stop before it's supposed to stop.

This is ridiculous. You are going on about this and have totally
removed the original code. In passing, note (from N869):

7.19.7.5 The getc function

Synopsis

[#1]
#include <stdio.h>
int getc(FILE *stream);

Description

[#2] The getc function is equivalent to fgetc, except that
if it is implemented as a macro, it may evaluate stream more
than once, so the argument should never be an expression
with side effects.

Returns

[#3] The getc function returns the next character from the
input stream pointed to by stream. If the stream is at end-
of-file, the end-of-file indicator for the stream is set and
getc returns EOF. If a read error occurs, the error
indicator for the stream is set and getc returns EOF.
 
P

pete

CBFalconer said:
This is ridiculous. You are going on about this and have totally
removed the original code.

I didn't remove anything.
Your code was from another thread.
Charlie Gordon brought it up in this thread.

Anyhow, under the conditions that I stated previously
and which you snipped,
your loop will stop when getc(f) returns a value of 'A'.
You don't think that's a good way for the loop to operate,
do you?

Here's your code:

unsigned int rdvalue(FILE *f) {
unsigned int ch, value, err;


value = err = 0;
while (EOF != (ch = getc(f))) {
/* ch contains an int, which is the value of the char */
if (!isdigit(ch)) break; /* Only interested in digits */
ch = ch - '0'; /* form digit value */
if (((UINT_MAX - ch) / 10) > value) {
/* overflow detected, decide what to do */
ch = ch + '0'; /* restore char value */
break;
}
value = 10 * value + ch;
}
ungetc(ch, f); /* keep exit char for the user */
return err;



} /* untested - you check it out */

Here's the conditions under which your loop will stop
when getc(f) returns a value of 'A':

CHAR_BIT == 32
sizeof(int) == 2
INT_MAX == 0xffffffff
UINT_MAX == INT_MAX
EOF == ('A' - 1 - (unsigned char)-1)
 
C

CBFalconer

pete said:
CBFalconer wrote:
.... snip ...


I didn't remove anything. Your code was from another thread.
Charlie Gordon brought it up in this thread.

Anyhow, under the conditions that I stated previously and which you
snipped, your loop will stop when getc(f) returns a value of 'A'.
You don't think that's a good way for the loop to operate, do you?

Yes I do. The routine is one to read an integer value from a text
stream. Alpha chars don't belong in that.
Here's your code:

unsigned int rdvalue(FILE *f) {
unsigned int ch, value, err;

value = err = 0;
while (EOF != (ch = getc(f))) {
/* ch contains an int, which is the value of the char */
if (!isdigit(ch)) break; /* Only interested in digits */
ch = ch - '0'; /* form digit value */
if (((UINT_MAX - ch) / 10) > value) {
/* overflow detected, decide what to do */
ch = ch + '0'; /* restore char value */
break;
}
value = 10 * value + ch;
}
ungetc(ch, f); /* keep exit char for the user */
return err;
} /* untested - you check it out */

Here's the conditions under which your loop will stop
when getc(f) returns a value of 'A':

Good. That's what is desired. Now fix it to return value, and set
a passed err flag.
 
P

pete

CBFalconer said:
Yes I do. The routine is one to read an integer value from a text
stream. Alpha chars don't belong in that.


Good. That's what is desired. Now fix it to return value, and set
a passed err flag.

It can also stop if getc(f) returns '9'.
You don't think that's a good way for the loop to operate, do you?

Here's the conditions under which your loop will stop
when getc(f) returns a value of '9':

CHAR_BIT == 32
sizeof(int) == 2
INT_MAX == 0xffffffff
UINT_MAX == INT_MAX
EOF == ('9' - 1 - (unsigned char)-1)
 
D

David Thompson

N869
6.2.6.2 Integer types
[#2] For signed integer types, the bits of the object
representation shall be divided into three groups: value
bits, padding bits, and the sign bit. There need not be any
padding bits; there shall be exactly one sign bit. Each bit
that is a value bit shall have the same value as the same
bit in the object representation of the corresponding
unsigned type (if there are M value bits in the signed type
and N in the unsigned type, then M<=N).

I suppose I could expand a little more.
If M equals N, and if INT_MIN != INT_MAX,

YM INT_MIN != - INT_MAX.
Or more precisely INT_MIN == - INT_MAX - 1.
(The 'natural' case for 2's complement.)
then signed int has twice the range of unsigned.
And in the case where signed int has twice the range of unsigned,
each unsigned value compares equal to two distinct signed values
which cannot be disambiguated by examining the unsigned value.
Even when INT_MIN == - INT_MAX (for 1sC, S&M, or 2sC with a trap
representation) all but one unsigned value matches 2 signed values.

- formerly david.thompson1 || achar(64) || worldnet.att.net
 
P

pete

David said:
N869
6.2.6.2 Integer types
[#2] For signed integer types,
the bits of the object
representation shall be divided into three groups:
value
bits, padding bits, and the sign bit.
There need not be any
padding bits; there shall be exactly one sign bit. Each
bit
that is a value bit shall have the same value as the
same
bit in the object representation of the
corresponding
unsigned type (if there are M value bits in the signed
type
and N in the unsigned type, then M<=N).

I suppose I could expand a little more.
If M equals N, and if INT_MIN != INT_MAX,

YM INT_MIN != - INT_MAX.

Yes I do.
Thank you.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,755
Messages
2,569,534
Members
45,008
Latest member
Rahul737

Latest Threads

Top