scanf (yes/no) - doesn't work + deprecation errors scanf, fopen etc.

[Douglas A. Gwyn]

And how is the input controlled? Blind luck?

No. How is an automobile's direction controlled? By blind luck?

 

[John Devereux]

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

I was thinking in particular about "big" functions like printf, and
embedded applications (where malloc / free use is often discouraged).

If it was guaranteed that standard functions did *not* use malloc
"behind the scenes", then this could be useful to know.

 

[kuyper]

Douglas A. Gwyn wrote:
....

Hardly. Gets() has been used in a zillion contexts where it has
not overflowed the allotted buffer, ...

That just means that the developers were unlucky enough to have a bad
design's flaws fail to surface. It doesn't mean that the design wasn't
flawed.

... so it must not require all
of what you describe. You probably have in mind a usage model
that does *not* include controlling the input to stdin, which is
a different context.

Since I don't know of any portable way for a C program to control it's
own standard input, yes, I am using such a model. It's bad design for
the ability of a program to avoid udefined behavior rely upon that
program being used correctly. When used incorrectly, it should fail
gracefully; it should not have undefined behavior. Obviously, you have
less strict standards for the behavior of incorrectly-used programs.

It's OK for a program that's not intended to be portable, to use
non-portable methods to control it's own standard input, but I don't
think the existence of such methods on some platforms should have any
influence over whether or not gets() remains in the standard library.

 

[Keith Thompson]

I was thinking in particular about "big" functions like printf, and
embedded applications (where malloc / free use is often discouraged).

If it was guaranteed that standard functions did *not* use malloc
"behind the scenes", then this could be useful to know.

There's no such guarantee in the standard. Nothing other than
malloc(), calloc(), and realloc() returns a pointer that the program
should, or may, pass to free(), but other library functions are
allowed to use *alloc() and free() internally.

 

[kuyper]

Well, obviously malloc() does, and calloc() and realloc() effectively
do. Other than that, fopen() and other functions *could* malloc
storage behind the scenes, but not in any manner that's visible to a
calling program.

Many of the standard library functions contain wording that says that
other library functions must behave as-if they never call that
particular function. I can find no such wording for the malloc()
family.

On the other hand, I can't think of any portable method of detecting
whether or not malloc() was called by, for instance, printf().
Correspondingly, I can't think of any reason why it should matter.

 

[Micah Cowan]

I was thinking in particular about "big" functions like printf, and
embedded applications (where malloc / free use is often discouraged).

If it was guaranteed that standard functions did *not* use malloc
"behind the scenes", then this could be useful to know.

No such guarantee may be made. Doug's point, I think, was that none of
the other standard functions /require/ allocating storage.

But, as a quality-of-implementation issue, I'd be fairly miffed if
printf() did a buncha allocating, as it's clearly unnecessary. Also,
nothing specifically allows printf() to fail due to allocation
problems, and therefore it is not allowed (in that, it is not one of
the explicitly listed exceptions for the requirement that it behave as
described by the standard, every time).

 

[Jordan Abel]

No. How is an automobile's direction controlled? By blind luck?

"Steering an automobile into a concrete wall will cause a crash" is
acceptable and widely understood by drivers. I'd dispute both that
"entering more than _x_ characters at _y_ prompt will cause a crash (or
other undefined behavior)" is acceptable and that it's typically
documented.

 

[Keith Thompson]

Many of the standard library functions contain wording that says that
other library functions must behave as-if they never call that
particular function. I can find no such wording for the malloc()
family.

Even if there were such wording, an implementation could easily get
around it by providing a lower-level __malloc() function. malloc()
itself could just call __malloc(); other library functions couldn't
call malloc(), but they could call __malloc(). One could argue either
way on the question of whether this meets the "as-if" requirement.

 

[Jordan Abel]

Even if there were such wording, an implementation could easily get
around it by providing a lower-level __malloc() function. malloc()
itself could just call __malloc(); other library functions couldn't
call malloc(), but they could call __malloc(). One could argue either
way on the question of whether this meets the "as-if" requirement.

Standard library functions _are_ forbidden from calling the rand()
function, and as far as I know the reason for this leads to the
conclusion that they're not permitted to do anything that messes with
rand()'s internal state. However, this can be easily detected in a
conforming program, whereas I'm at a loss to figure out how a conforming
program could detect memory allocation.

 

[Richard Heathfield]

Keith Thompson said:

Well, obviously malloc() does,

You mean malloc calls malloc? ;-)

 

[Keith Thompson]

Keith Thompson said:

You mean malloc calls malloc? ;-)

As a verb, "malloc()" means "whatever malloc does". malloc presumably
doesn't call malloc (though I suppose it could), but it does malloc().

That's my story, and I'm sticking to it.

 

[Mark McIntyre]

"Steering an automobile into a concrete wall will cause a crash" is
acceptable and widely understood by drivers. I'd dispute both that
"entering more than _x_ characters at _y_ prompt will cause a crash (or
other undefined behavior)" is acceptable and that it's typically
documented.

Nowhere in my /automobile/ documentation does it say "do not steer
this vehicle into a wall". I was taught this when I learned to drive.
Nowhere in my /compiler/ documentation does it say "do not overflow
arrays". I was taught this when I learned to programme.

Mark McIntyre

 

[Jordan Abel]

Nowhere in my /automobile/ documentation does it say "do not steer
this vehicle into a wall". I was taught this when I learned to drive.
Nowhere in my /compiler/ documentation does it say "do not overflow
arrays". I was taught this when I learned to programme.

Exactly. And you shouldn't assume that your users, even if they do know
how to program, know there is an array overflow lurking. Even if you
tell them, that's not an acceptable "feature" for a program to have.

 

[Brian Inglis]

Is it really true that no standard function malloc(s) storage?

Probably, "no standard function shall call {c,m,re}alloc or free".
OTOH fopen, fclose, setvbuf, and some others may dynamically
(de-)allocate memory.

 

[CBFalconer]

No. How is an automobile's direction controlled? By blind luck?

Yes, as is made supremely evident by observing traffic anywhere in
the world for significant length of time.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[CBFalconer]

It's not evident how useful it is in general, because details
of the buffering vary among platforms. For example, on some
systems multiple input or output lines might be buffered while
on others just one line at a time might be, depending on file
type etc. There are also multiple levels of buffering,
including kernel character queues, etc. and one needs to
specify whether or not unread/unwritten buffered data is
flushed at that level also. For a specific platform one can
handle all the details, but for general use it would be not
only a problem to specify adequately but also to use in a
portable manner.

But that is precisely the point. Only the system designer knows
how to make the function work on his system. I should think of it
as a means to guarantee that any future input occured after the
call to fpurge. It puts the input system in a known state and
avoids having to keep track of line ending absorption.

With it fgets would be useful. Just specify the min. length of
line you want to consider, and use fpurge to eliminate the rest.
If there is no rest, fpurge does nothing.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Francis Glassborow]

Some of us tried to get strdup() adopted for the standard,
but there was resistance primarily on the grounds that no other
standard function malloc()ed storage and the opposition didn't
want to start that as a design trend.

You mean like calloc and realloc Of course those functions might be
implemented in a free standing way but conceptually they acquire memory
from the heap. The same applies to strdup (which might also be
implemented directly rather than by using malloc).

C has a family of functions that acquire memory from the heap and a
function free() that releases such memory. In what way does strdup() not
qualify to be a member? Indeed had it been we would not have the
resource leakage brought about by naive programmers who do not realise
that third party supplied functions such as strdup need a corresponding
call to free().

 

[Francis Glassborow]

Pedagogically, gets() is a good example to have around.

If the desired lesson is that using the Standard Library is dangerous
When a student uses gets() it is much harder to persuade them that even
with, for example, the commonly used char buffer[BUFSIZE] when 19 out of
every 20 introductory books use it and it is in the Standard Library.
You know not to use it and so does everyone here yet it is in wide use
in the real world. The first step is to remove the endorsement of the C
Standard. And note that we could do so if we had the will because we do
have the power to issue a normative correction to the Standard even if
that would be very rare. Actually removing gets() would be one of the
few places that using such power could be justified and the resulting
exposure in the media might get the message home more effectively than
anything else we have available.

 

[Francis Glassborow]

Nowhere in my /automobile/ documentation does it say "do not steer
this vehicle into a wall". I was taught this when I learned to drive.
Nowhere in my /compiler/ documentation does it say "do not overflow
arrays". I was taught this when I learned to programme.

But the former is common sense (though with the litigious behaviour that
is common these days perhaps there should be a warning in the
documentation for vehicles The latter is very far from obvious, has
to be taught and manifestly is usually (certainly considering the range
of academic authors who use it in their books) not taught.

 

[Mark McIntyre]

But the former is common sense

Oh, did someone say that there was a requirement not to teach obvious
stuff? Hmm, that must have escaped most of the establishment.

Well then, pick your example - don't overfeed your fish, don't walk
through deep rivers, don't cross thin ice, etc. These are all things
you can learn either by instruction or experience. Documentation is
unlikely to be useful because hey, who reads the instructions on your
fishfood?

Mark McIntyre