adapting getline

[Keith Thompson]

You seem to have a faulty compiler. size_t is an unsigned integral
value, picked so as to be able to describe all sizes. Not a
double, which is signed and floating point. I assume n is
integral.

The warning is correct. It complains of a double *format*, namely
the "%f".

If the "%d" is correct, then n must be of type int. We know len
is of type size_t, so len / n is most likely of type size_t as well.

I note that in some languages other than C, ``x / y'', where x and
y are integers, yields a floating-point result. In C, it yields
an integer.

If you want a floating-point ratio, you can convert the operands
before dividing:
printf("There were %d lines, average length %f\n",
n, (double)len / (double)n);
(Only one of the two casts is really necessary, but I like the
symmetry.)

Note that this:
(double)(len / n)
converts the result of the integral division, and doesn't give you
the fractional result you might expect. For example, (double)3 / 2
is 1.5, but (double)(3 / 2) is 1.0.

With C99 I believe the printf format for size_t is x (assuming a
C99 library). For C90, cast the value to long and print a long.

Why guess? The C99 printf format for size_t is "%zu". For C90, it's
better to cast to unsigned long rather than long (and use "%lu").

 

[kid joe]

int n = 0;
double len = 0;

One question here:
printf("There were %d lines, average length %f\n", n, len / n);
I wouldn't think an integer divided by an integer would behave like it
does(?)

Hi Franken,

len is a double, so what happens is that n gets typecast to a double
also (which has a greater storage range than int), and the division is
then done using the FPU. If you change len to an integral type like size_t
then you'll get problems.

Cheers,
Joe


.---. .-----------
/ \ __ / ------
/ / \( )/ -----
////// ' \/ ` --- /=================\
//// / // : : --- | |
// / / /` '-- | Good Morning... |
// //..\\ | |
=============UU====UU============\================/
'//||\\`
''``

 

[kid joe]

This only works if realloc never fails.

Hi Ben,

In practise realloc never fails in this situation as the amount of memory
involved is very small. Even if it does fail, then the next line

will detect the error automatically and exit the program with an error
message, so there's no danger of data corruption.

Cheers,
Joe


.---. .-----------
/ \ __ / ------
/ / \( )/ -----
////// ' \/ ` --- /=================\
//// / // : : --- | |
// / / /` '-- | Good Morning... |
// //..\\ | |
=============UU====UU============\================/
'//||\\`
''``

 

[Ian Collins]

Hi Franken,

len is a double, so what happens is that n gets typecast to a double

It isn't cast (that would yield gibberish), it is converted.

// / / /` '-- | Good Morning... |

It's evening....

 

[Guest]

Hi Ben,

In practise realloc never fails in this situation as the amount of memory
involved is very small. Even if it does fail, then the next line


will detect the error automatically and exit the program with an error
message, so there's no danger of data corruption.

what absolute rubbish

 

[James Kuyper]

Hi Ben,

In practise realloc never fails in this situation as the amount of memory
involved is very small. Even if it does fail, then the next line


will detect the error automatically and exit the program with an error
message, so there's no danger of data corruption.

No, such code is NOT guaranteed to detect the error automatically. The
behavior is undefined. There is a popular notion that "undefined
behavior" means that your program will exit immediately. That is a
permitted possibility, but only because there are no possibilities that
are not permitted. It's a commonplace result, because essentially random
addresses have a good chance, on many systems, of being addresses of
memory your program doesn't have a right to modify, and attempting to
write to such memory causes the program to abort.

However, another very realistic possibility is that buf+bufsz-1 will
point at an object that your program does have a right to modify, an
object whose modification will cause your program to behave in highly
unexpected ways.

Here's an exercise: after a failed reallocation, the objects that the
expression buf + bufsz - 1 could, in principle, point at, include fd,
buf, c, and bufsize, or a piece of memory from a previous successful
reallocation. Try to figure out what your program will do in each of
those cases. After completing that exercise, seriously consider never
again letting a memory allocation failure to go unchecked.

 

[Keith Thompson]

Hi Ben,

In practise realloc never fails in this situation as the amount of memory
involved is very small. Even if it does fail, then the next line


will detect the error automatically and exit the program with an error
message, so there's no danger of data corruption.

James Kuyper has already told you why this is completely wrong.

Cheers,
Joe


.---. .-----------
/ \ __ / ------
/ / \( )/ -----
////// ' \/ ` --- /=================\
//// / // : : --- | |
// / / /` '-- | Good Morning... |
// //..\\ | |
=============UU====UU============\================/
'//||\\`
''``

Ok, we've seen your bird picture. Very impressive.

I believe I've told you before that signatures are traditionally no
longer than 4 lines, and that putting large ASCII graphics at the
bottom of every article you post is inappropriate. Also, a signature
is introduced by a line consisting of "-- ". Please fix your
signature before posting again.

 

[Ben Bacarisse]

In Dread Ink, the Grave Hand of Ben Bacarisse Did Inscribe:


I just dug this up from the clc wiki K&R solns by Heathfield:

I don't see your point. The awful code I was commenting on seemed to
be from someone else.

 

[Ben Bacarisse]

I suspect he means on his system.

His code won't work, reliably, on many systems. For some reason he
picked only one comment to talk about. The code is wrong for reasons
other than just the realloc assumption.

 

[Ben Bacarisse]

In practise realloc never fails in this situation as the amount of memory
involved is very small. Even if it does fail, then the next line


will detect the error automatically and exit the program with an error
message, so there's no danger of data corruption.

I won't repeat what has been said on this, but what about the other
bug?

 

[Franken Sense]

In Dread Ink, the Grave Hand of Keith Thompson Did Inscribe:

Ok, we've seen your bird picture. Very impressive.

I believe I've told you before that signatures are traditionally no
longer than 4 lines, and that putting large ASCII graphics at the
bottom of every article you post is inappropriate. Also, a signature
is introduced by a line consisting of "-- ". Please fix your
signature before posting again.

I like good ascii art, and I think joe's got a lot of moxie to post on a
difficult topic and endure the clc spin cycle with good cheer.

Maybe he can keep his bird picture if he alters it a scoch, so that a
reasonable news client will snip it upon reply. I think added the "hyphen
hyphen space crlf" to the top of the left wing will work:

--
.---. .-----------
/ \ __ / ------
/ / \( )/ -----
////// ' \/ ` --- /=================\
//// / // : : --- | |
// / / /` '-- | Happy 4:20 day! |
// //..\\ | |
=============UU====UU============\================/
'//||\\`
''``
(?)

 

[Eric Sosman]

I like good ascii art, [...]

Then take your enthusiasms to alt.ascii-art, please.
Keep flogging them here, and I for one will give you no
more help.

 

[CBFalconer]

CBFalconer said:

The function returns int because it's straight out of K&R2 and, at
the point in the book where it is introduced, they haven't
introduced size_t yet, and therefore they can't use it. I suggest
you obtain and peruse a copy of K&R2, so that you don't have to ask
such dumb questions any more.

I suggest, instead of these silly meanderings, you look at the
original message (to which I replied). I fail to see any mention
of K&R there. Just because you recognize such code doesn't mean
that Franken Sense got it in your approved manner. If you removed
the foolishness, and simply advised that it appeared to come from
K&R, which hadn't introduced ... etc. you would make a good deal
more sense and, incidentally, might induce more innocents to read
your messages. Why do you insist on burying perfectly good
knowledge and advice in this sort of foolishness. Grow up.

 

[Franken Sense]

In Dread Ink, the Grave Hand of Eric Sosman Did Inscribe:

I like good ascii art, [...]

Then take your enthusiasms to alt.ascii-art, please.
Keep flogging them here, and I for one will give you no
more help.

I don't need your help, Eric.

Chew on my too-long sig:
--
Frank

....it's obviously how his disease manifests itself, any kind of substance
dependency is very deep, issues of self esteem, you can just tell that he's
a really insecure and vulnerable person -- and I love him. You know,
sometimes I listen to him on the radio, and he's very judgmental, he's a
very angry person, and I just want to remind him that anytime you have a
finger pointing at someone else, there's three pointing back at you.
~~ Al Franken

 

[Franken Sense]

In Dread Ink, the Grave Hand of Eric Sosman Did Inscribe:

In Dread Ink, the Grave Hand of Eric Sosman Did Inscribe:
[...]

To get a useful warning about a potential problem in
getline(), crank up gcc's diagnostic level and call for an
optimization level that prompts the compiler to study the
usage patterns of variables. `-W -Wall -ansi -pedantic -O2'
is a reasonable starting point.

What would I be asking gcc.exe to do with these warnings?

You're asking gcc to *produce* its warnings. Then
you're going to ponder what the warnings are trying to
tell you, and whether they indicate a potential flaw in
your code. (Hint: They do, although the complete program
as it stands will not fall foul of the flaw.)

It looks to me more like it creates errors:

E:\gfortran\dan>gcc sosman1.c -W -Wall -ansi -pedantic -O2 -o out
In file included from sosman1.c:2:
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h:317:
error: s
yntax error before "double"
sosman1.c:34: error: syntax error before '/' token
sosman1.c:40: error: syntax error before "while"
sosman1.c:43: error: syntax error before '+' token

E:\gfortran\dan>gcc sosman2.c -Wall -o out

E:\gfortran\dan>

You might mean volvos.
--
Frank

....it's obviously how his disease manifests itself, any kind of substance
dependency is very deep, issues of self esteem, you can just tell that he's
a really insecure and vulnerable person -- and I love him. You know,
sometimes I listen to him on the radio, and he's very judgmental, he's a
very angry person, and I just want to remind him that anytime you have a
finger pointing at someone else, there's three pointing back at you.
~~ Al Franken

 

[Keith Thompson]

In Dread Ink, the Grave Hand of Eric Sosman Did Inscribe:

I like good ascii art, [...]

Then take your enthusiasms to alt.ascii-art, please.
Keep flogging them here, and I for one will give you no
more help.

I don't need your help, Eric.

Chew on my too-long sig:

[8 lines deleted]

Please reconsider what you're doing.

Excessively long signatures are considered rude. There's nothing
wrong with liking good ascii art, but as Eric points out, there is a
newsgroup for that very purpose. I'm sure there are web sites too.
I like science fiction, but I don't post it here.

You join a community, someone advises you that we don't do X here,
and you respond by defiantly doing X. This is not constructive.

 

[luserXtrog]

In Dread Ink, the Grave Hand of Eric Sosman Did Inscribe:

In Dread Ink, the Grave Hand of Eric Sosman Did Inscribe:
[...]
     To get a useful warning about a potential problem in
getline(), crank up gcc's diagnostic level and call for an
optimization level that prompts the compiler to study the
usage patterns of variables.  `-W -Wall -ansi -pedantic -O2'
is a reasonable starting point.
What would I be asking gcc.exe to do with these warnings?

     You're asking gcc to *produce* its warnings.  Then
you're going to ponder what the warnings are trying to
tell you, and whether they indicate a potential flaw in
your code.  (Hint: They do, although the complete program
as it stands will not fall foul of the flaw.)

It looks to me more like it creates errors:

E:\gfortran\dan>gcc sosman1.c -W -Wall -ansi -pedantic -O2 -o out
In file included from sosman1.c:2:
C:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h:317:
error: s
yntax error before "double"
sosman1.c:34: error: syntax error before '/' token
sosman1.c:40: error: syntax error before "while"
sosman1.c:43: error: syntax error before '+' token

E:\gfortran\dan>gcc sosman2.c -Wall -o out

E:\gfortran\dan>

You might mean volvos.

OTOH, you might have better luck leaving off the -ansi part.
I have a suspicion that mingw had to deviate quite a bit
in order to interface with m$windows.
The -O2 was the important part.

 

[Kenny McCormack]

In Dread Ink, the Grave Hand of Eric Sosman Did Inscribe:

Franken Sense wrote:

I like good ascii art, [...]

Then take your enthusiasms to alt.ascii-art, please.
Keep flogging them here, and I for one will give you no
more help.

I don't need your help, Eric.

Chew on my too-long sig:

Indeed. Well put.

....

Excessively long signatures are considered rude. There's nothing
wrong with liking good ascii art, but as Eric points out, there is a
newsgroup for that very purpose. I'm sure there are web sites too.
I like science fiction, but I don't post it here.

You join a community, someone advises you that we don't do X here,
and you respond by defiantly doing X. This is not constructive.

What a jerk KT is. Keep this in mind always.

The real thing to cogitate upon is this: Can you imagine *being* this guy???

 

[Antoninus Twink]

It looks to me more like it creates errors:

E:\gfortran\dan>gcc sosman1.c -W -Wall -ansi -pedantic -O2 -o out
sosman1.c:34: error: syntax error before '/' token

The -ansi switch makes gcc conform to an obsolete version of the ISO C
standard, which Sossman, Heathfield and some other posters here prefer
because they want C to remain as a museum piece rather than a living
language.

Either omit -ansi altogether (to get the default GNU C dialect), or use
-std=c99 (to get the /current/ version of the ISO C Standard).

 

[Franken Sense]

In Dread Ink, the Grave Hand of Richard Heathfield Did Inscribe:

Franken Sense said:

In Dread Ink, the Grave Hand of Eric Sosman Did Inscribe:

Franken Sense wrote:

I like good ascii art, [...]

Then take your enthusiasms to alt.ascii-art, please.
Keep flogging them here, and I for one will give you no
more help.

I don't need your help, Eric.

Chew on my too-long sig:

Do you need my help?

That's a different question. Without it I would change syntaxes, with my
latest tasks unsolved.

I don't need any American to talk to me about flogging, and in the
imperative.

Wouldn't the portable solution delete 8192 chars after the '-- crlf', as I
posted.
--
Frank

I think some people hold [G.W.Bush] in high esteem because they watch Fox.
And they get their news from Rush Limbaugh. And they are fooled.
~~ Al Franken, in response to the 2004 SOTU address