Print lines longer than 80 chars

[rajash]

Thanks to everyone on this forum for their helpful comments, now here
is my solution to Exercise 1.17, pretty short and neat!


// print lines longer than 80 chars

char x[160]; // allocate buffer

void main()
{
while(! feof(stdin)) {
gets((char *) &x);
if(strlen(x)>80)
printf("%s", x);
else
printf("");
}
}

 

[Ian Collins]

Thanks to everyone on this forum for their helpful comments, now here
is my solution to Exercise 1.17, pretty short and neat!


// print lines longer than 80 chars

char x[160]; // allocate buffer

You've already been told bout globals

void main()

and void main()

{
while(! feof(stdin)) {

and feof

gets((char *) &x);
if(strlen(x)>80)
printf("%s", x);

and including headers.

 

[CBFalconer]

Thanks to everyone on this forum for their helpful comments, now
here is my solution to Exercise 1.17, pretty short and neat!

// print lines longer than 80 chars
char x[160]; // allocate buffer

void main()
{
while(! feof(stdin)) {
gets((char *) &x);
if(strlen(x)>80)
printf("%s", x);
else
printf("");
}
}

You didn't fix the last, and you are making the same silly errors.
Do one job at a time, and do it properly.

 

[santosh]

Thanks to everyone on this forum for their helpful comments, now here
is my solution to Exercise 1.17, pretty short and neat!


// print lines longer than 80 chars

char x[160]; // allocate buffer

void main()

Use int main(void)

{
while(! feof(stdin)) {

Test with feof() *after* a read operation returns EOF. That's the way it
must be done in C, whether it's intuitive or not.

gets((char *) &x);

*Never* use gets(). fgets() is almost as easy to use. Also note that the
array name 'x', by itself decays to a pointer to the start of the array
under most conditions. So '&x' is unnecessary, as in the cast.

if(strlen(x)>80)
printf("%s", x);
else
printf("");
}
}

Do like:

#include <stdio.h>
#include <stdlib.h> /* for EXIT_FAILURE */

#define LINE_LENGTH 1024

int main(void) {
char line[LINE_LENGTH];

while (fgets(line, sizeof line, stdin) != NULL) {
if (strlen(line) > 80) fputs(line, stdout);
}
return feof(stdin) : 0 ? EXIT_FAILURE;
}

 

[Bart]

... Also note that the
array name 'x', by itself decays to a pointer to the start of the array
under most conditions. So '&x' is unnecessary

To me &x is easier to read and conveys more information; x by itself
could be anything, while &x is likely (in a function with 'get' in the
name) to be a reference to some data destination.

C seems to have a somewhat arbitrary distinction between variables
that can be passed by value, and variables that can only be passed by
reference (arrays and structs, even if they are only as big as an int
for example).

Although it's never going to happen now, if arrays and structs were
ever allowed to be passed by value, then all those missing &'s are
going to be a problem!

So allowing this kind of lazy coding (letting x and &x mean the same
thing
-- sometimes!) may well have impeded development of the language.

Bart C

 

[santosh]

To me &x is easier to read and conveys more information; x by itself
could be anything, while &x is likely (in a function with 'get' in the
name) to be a reference to some data destination.

C seems to have a somewhat arbitrary distinction between variables
that can be passed by value, and variables that can only be passed by
reference (arrays and structs, even if they are only as big as an int
for example).

Although it's never going to happen now, if arrays and structs were
ever allowed to be passed by value, then all those missing &'s are
going to be a problem!

structures can be (and usually are) passed by value.

 

[Flash Gordon]

Bart wrote, On 01/12/07 12:27:

To me &x is easier to read and conveys more information; x by itself
could be anything, while &x is likely (in a function with 'get' in the
name) to be a reference to some data destination.

Ah, but &x is a different type, hence the cast in the above code. The
cast prevents the compiler from telling you if x is actually an array of
doubles, so incorrectly using &x and then casting to "fix it up" makes
your program more fragile.

C seems to have a somewhat arbitrary distinction between variables
that can be passed by value, and variables that can only be passed by
reference

It is not an arbitrary distinction. The problem is that you do not yet
know how C works, which is that *everything* is always passed by value.

(arrays and structs, even if they are only as big as an int
for example).

structs to not even give the appearance of being passed by reference,
unlike arrays.

Although it's never going to happen now, if arrays and structs were
ever allowed to be passed by value, then all those missing &'s are
going to be a problem!

Structs are *always* passed by value. Well, you can pass a pointer to a
struct, but that is done differently.

So allowing this kind of lazy coding (letting x and &x mean the same
thing
-- sometimes!) may well have impeded development of the language.

Again you do not understand the language. x and &x always mean different
things and the only time they give a real appearance of meaning the same
thing is when & is applied to a function name, in which case the
distinction is academic.

In most instances the name of an array decays to a pointer to the first
element of the array. &array_name give a pointer to the array, i.e. a
different type.

For more information on this read the comp.lang.c FAQ starting with
section 6. You can find the FAQ at http://c-faq.com/

 

[Richard Heathfield]

Bart said:

To me &x is easier to read and conveys more information;

Nevertheless, it is silly. &x has type char (*)[160], and is inappropriate
for passing to a function taking char *. The cast merely obscures the
problem.

C seems to have a somewhat arbitrary distinction between variables
that can be passed by value, and variables that can only be passed by
reference (arrays and structs, even if they are only as big as an int
for example).

No. In C, it is *always* the *value* of an argument expression that is
passed to a function - objects are never passed by reference.

Although it's never going to happen now, if arrays and structs were
ever allowed to be passed by value, then all those missing &'s are
going to be a problem!

Arrays can't be passed at all - what is actually passed is a pointer to
their first element - and structs can already be passed by value.

So allowing this kind of lazy coding (letting x and &x mean the same
thing
-- sometimes!)

The only time I can think of where they have the same value is where x has
type void * and points to itself. This is because the type of an object is
an innate aspect of its value.

may well have impeded development of the language.

That does not appear to be the case.

 

[Bart]

Bart said:

The only time I can think of where they have the same value is where x has
type void * and points to itself. This is because the type of an object is
an innate aspect of its value.

I meant because x reduces to &x in some circumstances:

a and &a are the same when a is an array (also strcmp and &strcmp for
functions). i and&i are different when i is any other type.

But, as has been pointed out, structs *are* passed by value (and
therefore provides a mechanism for arrays to be passed by value too by
having an array in a struct).

So it's just arrays (and maybe functions) that are the odd ones out,
probably for good reasons of language design.

Bart C

 

[James Kuyper]

I meant because x reduces to &x in some circumstances:

x usually decays to &x[0], not &x. It points at the same location in
memory as &x, but it has a different type, which means that different
operations are permitted on &x and on &x[0]. If those two pointer values
are stored in pointer objects with matching types, those pointer objects
may have different representations for the same location in memory; they
may even have different sizes.

 

[Flash Gordon]

Bart wrote, On 01/12/07 15:04:

I meant because x reduces to &x in some circumstances:

a and &a are the same when a is an array

Incorrect. Try using sizeof on those, or try assigning them to pointers
*without* casting. It is inadvisable to contradict Richard Heathfield
without carefully checking your facts. Read section 6 of the comp.lang.c
FAQ at http://c-faq.com/ to see why you are wrong.

(also strcmp and &strcmp for
functions).

There are technical differences in what happens, but in practice for
functions it gives the same result.

i and&i are different when i is any other type.

But, as has been pointed out, structs *are* passed by value (and
therefore provides a mechanism for arrays to be passed by value too by
having an array in a struct).
Yes.

So it's just arrays (and maybe functions) that are the odd ones out,
probably for good reasons of language design.

Arrays are odd ones out but *not* for the reason you are claiming.
Saying that a pointer to the first element of an array (which is what
the array name "decays" to in most situations) is the same as a pointer
to the array (which is what & gives you) is like saying the plans for
your house are the same as the plans for the road you live in, or a sign
pointing at London is the same as a sign pointing at the Tower of London
is the same as a sign pointing at the Bloody Tower.

 

[Richard Heathfield]

Flash Gordon said:

Bart wrote, On 01/12/07 15:04:


Incorrect. Try using sizeof on those, or try assigning them to pointers
*without* casting. It is inadvisable to contradict Richard Heathfield
without carefully checking your facts.

Kind of you, but of course it's inadvisable to contradict /anyone/ without
carefully checking your facts.

In his defence, BTW, he was right about functions: funcname and &funcname
do mean the same thing. (I didn't claim otherwise, but I did overlook it
in my reply.)

 

[Keith Thompson]

Flash Gordon said:

Bart wrote, On 01/12/07 15:04: [...]

a and &a are the same when a is an array

Incorrect. Try using sizeof on those, or try assigning them to pointers
*without* casting. It is inadvisable to contradict Richard Heathfield
without carefully checking your facts.

Kind of you, but of course it's inadvisable to contradict /anyone/ without
carefully checking your facts.

True, but the phenomenon is particularly noticeable in some cases.

In his defence, BTW, he was right about functions: funcname and &funcname
do mean the same thing. (I didn't claim otherwise, but I did overlook it
in my reply.)

Not in all contexts.

``sizeof funcname'' is a constraint violation; ``sizeof &funcname''
yields the size of a function pointer.

``& funcname'' yields the address of the function; ``& &funcname'' is
a constraint violation.

So you were wrong in implying that you were wrong to overlook it; in
fact, you were right to overlook it. You shouldn't contradict
yourself without carefully checking your facts.

 

[Richard Heathfield]

Keith Thompson said:

True, but the phenomenon is particularly noticeable in some cases.


Not in all contexts.

But we weren't discussing all contexts, merely values.

``sizeof funcname'' is a constraint violation; ``sizeof &funcname''
yields the size of a function pointer.

``& funcname'' yields the address of the function; ``& &funcname'' is
a constraint violation.

So you were wrong in implying that you were wrong to overlook it; in
fact, you were right to overlook it. You shouldn't contradict
yourself without carefully checking your facts.

But the original claim was specifically to do with *values*, and sizeof
does not evaluate its operand, so it doesn't qualify.

So I was right in implying that I was wrong to overlook the value
equivalence of funcname and &funcname, despite your contradiction. See
Flash Gordon's comment (quoted above).

 

[Flash Gordon]

Richard Heathfield wrote, On 02/12/07 04:04:

Keith Thompson said:


But we weren't discussing all contexts, merely values.

The values are generated within a context.

But the original claim was specifically to do with *values*, and sizeof
does not evaluate its operand, so it doesn't qualify.

So I was right in implying that I was wrong to overlook the value
equivalence of funcname and &funcname, despite your contradiction. See
Flash Gordon's comment (quoted above).

Actually, you should read the comments I made in other posts where I
stated there are differences, just ones that are of theoretical rather
than practical importance. Specifically the value of &funcname is a
pointer to a function (section 6.5.3.2 or N1256) but funcname on its own
is a function designator which has function type rather than pointer to
function (section 6.3.2.1 para 4).

It is of only theoretical import because except when it is the operand
of & or sizeof the value gets converted to type function to pointer, but
it shows you are wrong because that is not its original type, and type
is an important part of value in C.

I, of course, did follow my advice and check my facts before
contradicting you

 

[Richard Heathfield]

Flash Gordon said:

I, of course, did follow my advice and check my facts before
contradicting you

We appear to be in a maze of twisty little contradictions, all different.
Perhaps we should quit while we're behind.

 

[Flash Gordon]

Richard Heathfield wrote, On 02/12/07 13:55:

Flash Gordon said:



We appear to be in a maze of twisty little contradictions, all different.

go north

Perhaps we should quit while we're behind.

Depends on who or what we are behind ;-)

 

[David Thompson]

But, as has been pointed out, structs *are* passed by value (and
therefore provides a mechanism for arrays to be passed by value too by
having an array in a struct).

So it's just arrays (and maybe functions) that are the odd ones out,
probably for good reasons of language design.

Well, there was a good reason when BCPL and then B did it. C evolved
gradually from B and was never redesigned from scratch. In principle
it might be better if it had been -- but if its creators had focussed
their energy on creating a better language (of which there were
already then others available) rather than on creating Unix, quite
possibly we would have neither of them today. *

structs were (re?)added after the transition, and so were not
constrained by compatibility and could use firstclass semantics.

If you want to know more -- quite a bit more -- about the history and
evolution of C, Ritchie's paper to the HOPL2 conference is available
on his website at http://cm.bell-labs.com/cm/cs/who/dmr/
as are several other relevant documents from the time.

<ObSemiTopic=scoping> * In proofreading I realized this has a subtly
ambiguous referent. Of course I mean(t) that the then-potential C and
Unix would have not come to pass, not that the already existing people
(kmt and dmr) would have been destroyed somehow. <?G>

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