I think this is an impossible assignment...could you help?

[BartC]

#include
#define INVALID 0x80000000 [...]
{long num, i; [...]
{ if (num == INVALID)

If long is 32 bits, then 0x80000000 is outside the range of long.
How about

#define INVALID LONG_MIN
?

I always think of 'long' as unsigned (because outside C, that's how I use
it), and I didn't see that. Similarly when I saw LONG_MIN I immediately
thought zero!

But yes that would be a better signalling value.

 

[BartC]

"May or may not" indeed. Sort of a here. Some instructors
respond better than others to students "improving" (or actually
improving) their code.

The OP will know their instructor better than we do. However the original
code looked more like it had been written by a student..

IMO changing the prompt to include the stop value is quite an
improvement, and I wonder why the original program didn't!

This is necessary otherwise the 'user' will have no idea how to stop the
program.

Perhaps ++i here (or start i at 1), as the original counted from 1.

 

[Keith Thompson]

#include
#define INVALID 0x80000000 [...]
{long num, i; [...]
{ if (num == INVALID)

If long is 32 bits, then 0x80000000 is outside the range of long.
How about

#define INVALID LONG_MIN
?

I always think of 'long' as unsigned (because outside C, that's how I
use it), and I didn't see that. Similarly when I saw LONG_MIN I
immediately thought zero!

But yes that would be a better signalling value.

(You know about "unsigned long", right?)

 

[Eric Sosman]

Sure. But if you're reading keyboard input and you don't differentiate
between newline and other kinds of whitespace, how would you ever know
that the user pressed Enter thus signaling end-of-input?

The original problem statement is somewhat vague, but I think
it's pretty clear that "white space" -- any "white space" -- is to
be taken as a terminator.

Unfortunately, "white space" is left undefined. One might appeal
to isspace() from <ctype.h>, but the problem statement forbids using
it, so the position that isspace() encapsulates the definition of
"white space" is hard to sustain. Under the circumstances, I think
the problem-solver would be justified in considering "white space" to
be any of the characters ' ', '\t', '\n', '\v', '\r', '#', 'W', and 'q'.
Justified, but probably ill-advised since the sloppy problem-setter is
unlikely to give points to a solution that points out his sloppiness.

 

[James Kuyper]

On 08/31/2011 09:15 PM, Eric Sosman wrote:
....

The original problem statement is somewhat vague, but I think
it's pretty clear that "white space" -- any "white space" -- is to
be taken as a terminator.

Unfortunately, "white space" is left undefined. One might appeal
to isspace() from <ctype.h>, but the problem statement forbids using
it, so the position that isspace() encapsulates the definition of
"white space" is hard to sustain.

Section 6.4p3 defines both "white space" and "white-space characters",
independently of the C standard library in general, or isspace() in
particular. I don't think there's any justification for suggesting that
any alternative definition of those terms was intended. The definition
of isspace() is based upon the definition of white-space character in
6.4p3. While the instructor said "white space", I suspect he meant
"white-space characters" - I doubt that he intended that the programs
should parse and skip C-style comments.

The problem statement specified that scan_int() would approximate
scanf("%d",&x). The standard's definition of the behavior of scanf()
explicitly says that white-space characters are skipped, and cites
isspace() as defining what that means. Lacking permission to call any
standard library function other than getchar(), scan_int() cannot
emulate the locale-dependence of isspace(), but it can at least match
it's behavior in the "C" locale, and I think it's clear that the
instructor intended it to do so.

... Under the circumstances, I think
the problem-solver would be justified in considering "white space" to
be any of the characters ' ', '\t', '\n', '\v', '\r', '#', 'W', and 'q'.

I can't see any basis for including any of those last three.

 

[blmblm]

[ snip ]

[ snip ]

Another problem with the specification, IMO anyway, is that it
disallows a legitimate "int" value, namely -2147483648 (0x8000000).
Then again, a function that takes no arguments and returns an int --
well, the options for signalling that an error has occurred do seem
kind of limited.

Correction:

First, why am I talking about int values when this function returns
a long? (What was I thinking.)

Also, 0x8000000 might be valid long on some systems, but that's not
guaranteed. (I'm not sure I'd have known that, but someone else
pointed it out, and I looked up the standard, and indeed the lower
end of the required range for longs is -(2**31-1), not -2**31 as
I thought.)

 

[blmblm]

Sure. But if you're reading keyboard input and you don't differentiate
between newline and other kinds of whitespace, how would you ever know
that the user pressed Enter thus signaling end-of-input?

Say what? If you're reading from the standard input stream, you won't
get *any* input until the user presses "Enter", will you?

 

[blmblm]

#include
#define INVALID 0x80000000 [...]
{long num, i; [...]
{ if (num == INVALID)

If long is 32 bits, then 0x80000000 is outside the range of long.
How about

#define INVALID LONG_MIN
?

And then you disallow one legitimate input .... Well, I guess
the options for signalling errors are limited. <shrug>?

 

[blmblm]

The OP will know their instructor better than we do. However the original
code looked more like it had been written by a student..

To me the original code for main appeared to be part of the
assignment -- it's introduced by that assignment-speak phrase
"Consider the following implementation of main". That doesn't
preclude its being written by some student, but I'm guessing the
author is not the OP.

This is necessary otherwise the 'user' will have no idea how to stop the
program.
Exactly.


Perhaps ++i here (or start i at 1), as the original counted from 1.

Yes. Good catch (of a mistake in your revision?).

 

[blmblm]

The original problem statement is somewhat vague, but I think
it's pretty clear that "white space" -- any "white space" -- is to
be taken as a terminator.

Unfortunately, "white space" is left undefined. One might appeal
to isspace() from <ctype.h>, but the problem statement forbids using
it, so the position that isspace() encapsulates the definition of
"white space" is hard to sustain. Under the circumstances, I think
the problem-solver would be justified in considering "white space" to
be any of the characters ' ', '\t', '\n', '\v', '\r', '#', 'W', and 'q'.
Justified, but probably ill-advised since the sloppy problem-setter is
unlikely to give points to a solution that points out his sloppiness.

You never know -- I mean, there *are* instructors who are glad
to have mistakes pointed out, especially if it's done reasonably
diplomatically -- but that might not be the way to bet. ?

 

[John Gordon]

Say what? If you're reading from the standard input stream, you won't
get *any* input until the user presses "Enter", will you?

Good point! Not sure what I was thinking.

 

[Keith Thompson]

Also, 0x8000000 might be valid long on some systems, but that's not
guaranteed. (I'm not sure I'd have known that, but someone else
pointed it out, and I looked up the standard, and indeed the lower
end of the required range for longs is -(2**31-1), not -2**31 as
I thought.)

0x80000000 is a positive value, equal to 2**31. It's not a valid
long value on any system where long is 32 bits (and LONG_MAX is at
most 2**31-1).

It commonly *converts* to a valid long value, -2**31 (ULONG_MIN),
but the result of the conversion is implementation-defined.

 

[Keith Thompson]

#include
#define INVALID 0x80000000 [...]
{long num, i; [...]
{ if (num == INVALID)

If long is 32 bits, then 0x80000000 is outside the range of long.
How about

#define INVALID LONG_MIN
?

And then you disallow one legitimate input .... Well, I guess
the options for signalling errors are limited. <shrug>?

So I can't enter -2147483648. Oh, darn. }

In real life, checking for end-of-file would make a lot more sense, but
this is a beginner's assignment.

 

[BartC]

So I can't enter -2147483648. Oh, darn. }

In real life, checking for end-of-file would make a lot more sense, but
this is a beginner's assignment.

I think he meant the -999 that is used to stop the program...

(If it was my specification, I might have just used an empty line to end.
However this is after all just an exercise.)

 

[Joe Pfeiffer]

COMSC 1613 Programming I (C) Programming Assignment
3

In this assignment, you will write a 'C' function that will approximate
the action of the command scanf("%d",&x); namely, to read ASCII
character
digits from the standard input stream and convert/interpret the sequence
into a binary integer.

Since the author of scanf() did it, you *know* it's not impossible.

 

[James Kuyper]

Since the author of scanf() did it, you *know* it's not impossible.

Your conclusion is correct, but your argument is faulty. There's no
requirement that standard library functions be written in C, and in fact
many of them are standard library functions precisely because they do
things that can't be done using just the C language. They're either
written in some other language (often assembler) or they call
OS-specific functions which are themselves written in some other language.

scanf() doesn't happen to be one of those functions; the required
behavior for scanf() can be implemented entirely in C code that calls
other C standard library functions, without using any of the other
members of the scanf() family. But if your argument were valid, it would
also apply to fgetc().

 

[sandeep]

scanf() doesn't happen to be one of those functions; the required
behavior for scanf() can be implemented entirely in C code that calls
other C standard library functions, without using any of the other
members of the scanf() family. But if your argument were valid, it would
also apply to fgetc().

I believe the following to be a conforming implementation of fgetc,
entirely in C code:

int fgetc(FILE *stream)
{
errno = EIO;
return EOF;
}

 

[Joe Pfeiffer]

Your conclusion is correct, but your argument is faulty. There's no
requirement that standard library functions be written in C, and in fact
many of them are standard library functions precisely because they do
things that can't be done using just the C language. They're either
written in some other language (often assembler) or they call
OS-specific functions which are themselves written in some other language.

Sorry, "Since the author of scanf() did it in C, you *know* it's not
impossible."

scanf() doesn't happen to be one of those functions; the required
behavior for scanf() can be implemented entirely in C code that calls
other C standard library functions, without using any of the other
members of the scanf() family. But if your argument were valid, it would
also apply to fgetc().

Actually, I was unaware that fgetc() had any non-C code in it -- what
does it do that requires assembler?

 

[Keith Thompson]

Actually, I was unaware that fgetc() had any non-C code in it -- what
does it do that requires assembler?

fgetc() cannot be written in *portable* C.

 

[Joe Pfeiffer]

fgetc() cannot be written in *portable* C.

What in it requires non-portable C?