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

[Keith Thompson]

There is no "1!=func()" style.

There's no variable there
to put on either the left or the right hand side
of the inequality operator.

I don't know whether there is such a style or not.

As we know, there is a common style that uses "42 == var" rather than
"var == 42". The point is to make it more likely that the error of
typing "=" rather than "==" will be caught.

In some of the code posted in this thread, this style was extended to
something like "42 != var", even though accidentally typing "=" rather
than "!=" is far less likely. Presumably this is done for the sake of
consistency.

If you've developed the habit of putting constants on left, it makes
as much sense to use "1 != func()" (in my opinion, it's consistently
ugly). But I don't remember whether I've ever seen such code.

 

[=?ISO-8859-1?Q?Martin_J=F8rgensen?=]

You should not print EOF using the %c format specifier.
There is no EOF character.

Actually, this was about using %d instead of %c (which is not a good
idea)... But I know what you mean...


Best regards / Med venlig hilsen
Martin Jørgensen

 

[CBFalconer]

En CBFalconer va escriure:

.... snip ...


The origin is more OpenBSD than FreeBSD, as far as I know.

Thanks for the correction. I get that confused.

You shoud read the rationale (N1147) before commenting in such a
way. Obviously strlcpy() and strlcat() were considered, and
discarded (1.1.15, 6.7.1.3, 6.7.2.1).

I shall take a look later for:
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1147.pdf>

I did not know it existed. IIRC I found some replacements for
strcpy and strcat in N1147. I saw no objections to strlcpy and
strlcat, both of which are perfectly safe from overruns, so why
propose something further that is familiar to no-one?

Also, as far as I could see, the proposed gets replacement does
nothing that fgets does not. ggets does - it makes overruns
impossible and eliminates confusion about whether complete lines
have been absorbed. It also avoids the silly differences between
fggets and ggets that exist between fgets and gets. C interactive
action is plagued with failure to know whether complete lines have
been handled.

IMO placing these three routines in the standard library could
greatly reduce the silly overrun error density.

--
"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]

.... snip ...

If you've developed the habit of putting constants on left, it makes
as much sense to use "1 != func()" (in my opinion, it's consistently
ugly). But I don't remember whether I've ever seen such code.

You have from me I try to make it a habit, which may well save
me from myself at some time. I have definitely been known to write
down the inverse of the desired test, and later been forced to
replace the comparison operator involved.

I have actually found that compilers tend to be more consistent in
catching errors than I am, and I am quite willing to give them an
opportunity.

--
"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/>

 

[Antoine Leca]

En CBFalconer va escriure:

IMO placing these three routines in the standard library could
greatly reduce the silly overrun error density.

I agree (personnal POV) with your point strlcpy() and strlcat() are very
good candidates for inclusion (along with the forced wcslcpy() and
wcslcat()) into the Standard library. However, it would take place in a
future revision (or even an amendment), which we have no date for.

Furthermore, the "safer" TR is *not* the good path for such a move: there is
a clear distinction between the standard library and the addendum provided
by the TR; also, the added baggage of the TR will probably *not* be
implemented by a number of people. Last but not least, the scheme of the
strlcpy() etc. functions is quite different from the other additions, even
if it more widely used this has further implications (like the different
variation in cycles used vs. the classical ones).


I am much more reserved about your ggets(): I believe there are already too
much ways to get strings in (fgets, *scanf, fwrite), adding a new one does
not seem necessary to me. YMMV, of course.


Antoine

 

[Richard Bos]

Actually, this was about using %d instead of %c (which is not a good
idea)... But I know what you mean...

EOF is an integer constant with negative value. You _could_ try printing
it using %ld if you think it's likely to be larger than will fit in a
plain int, but, given the contents of <ctype.h>, how likely is that?

Richard

 

[Keith Thompson]

EOF is an integer constant with negative value. You _could_ try printing
it using %ld if you think it's likely to be larger than will fit in a
plain int, but, given the contents of <ctype.h>, how likely is that?

EOF "expands to an integer constant expression, with type int and a
negative value" (C99 7.19.1p3).

 

[Richard Bos]

EOF "expands to an integer constant expression, with type int and a
negative value" (C99 7.19.1p3).

Teach me to look these up some time :-/

That's even better, then: %d will indeed work fine.

Richard

 

[CBFalconer]

En CBFalconer va escriure:


I agree (personnal POV) with your point strlcpy() and strlcat() are very
good candidates for inclusion (along with the forced wcslcpy() and
wcslcat()) into the Standard library. However, it would take place in a
future revision (or even an amendment), which we have no date for.

Furthermore, the "safer" TR is *not* the good path for such a move: there is
a clear distinction between the standard library and the addendum provided
by the TR; also, the added baggage of the TR will probably *not* be
implemented by a number of people. Last but not least, the scheme of the
strlcpy() etc. functions is quite different from the other additions, even
if it more widely used this has further implications (like the different
variation in cycles used vs. the classical ones).

I am much more reserved about your ggets(): I believe there are already too
much ways to get strings in (fgets, *scanf, fwrite), adding a new one does
not seem necessary to me. YMMV, of course.

Well, that's why I put it out there and made it public domain. My
objective was the simplicity of gets with the safety of fgets
without any ambiguity and minimum data loss. What little feedback
I receive is generally positive. I consider the 1135 technique of
discarding data on error to be foul.

As I said, I had never heard of n1135 or n1147 before. This came
up when someone posted in c.l.c about deprecated messages from
Microsoft compilers, and I reacted with outrage at yet another
attempt to derail standards. I do not subscribe to c.stds.c. This
is written in c.l.c.

It is one thing to attempt to provide a set of safer routine
replacements, but I suspect it is forlorn. Working code will not
be upgraded to match, and any such upgrade will reduce
portability. The target should be new code. One urgent and
overdue step is the deprecation of gets. It is not possible to
overcome the fundamental insecurities of C, because such things as
pointer usage are too deeply inbred, and close typing (subranges)
is impossible. Therefore library errors are the obvious path.

Many items in the library can be eliminated, as being fabricable
with purely standard code. So I consider the first step is library
paring to essentials. After that pay attention to consistent
parameter format, allow for length controls a-la-strlcpy etc.
Eliminate subtly error prone constructs such as returning pointers
in strcat. The result can be a new set of include files, which is
feasible since the target is new code. A further set of includes
can cover the handy utilities, fabricable anywhere. These would
include strlcpy and strlcat, for example.

I suggest cross-posting any publicity about such efforts to c.l.c,
with suitable follow-ups. That will at least have a chance of
alerting those with opinions.

BTW, just the use of '_' in routine names is counter-productive.
It is a pain to type because of the use of the shift key, and the
extremely lazy, such as myself, will avoid it.

--
"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/>

 

[Douglas A. Gwyn]

It is one thing to attempt to provide a set of safer routine
replacements, but I suspect it is forlorn. Working code will not
be upgraded to match, and any such upgrade will reduce
portability.

Well, no, a goal is for the new functions to be readily
edited into place (e.g. with an automated tool), and one
would naturally carry around a portable implementation of
the new function library with the app that uses it.

The target should be new code. One urgent and
overdue step is the deprecation of gets.

New code doesn't need to use gets. Recall that gets was
specified in the standard simply because it was a widely
used piece of the base library. Almost any function can
be abused, but that doesn't mean they all need to be
deprecated.

It is not possible to
overcome the fundamental insecurities of C, because such things as
pointer usage are too deeply inbred, and close typing (subranges)
is impossible. Therefore library errors are the obvious path.

Many programmers have written secure code in C despite
those possibilities. Indeed, if you think you need such
features for security, you're on the wrong path -- those
features take effect only when there is already an error
in your algorithm, and cannot in themselves correct the
algorithm. There are C development environments that can
help you detect such errors early on, if you really feel
insecure about your ability to code correctly.

Many items in the library can be eliminated, as being fabricable
with purely standard code.

That has never been a goal of the C standard, nor is it
something that programmers have been clamoring for. To
the contrary, there has been some demand for including
even more of the commonly-encountered library functions.

BTW, just the use of '_' in routine names is counter-productive.
It is a pain to type because of the use of the shift key, and the
extremely lazy, such as myself, will avoid it.

It's a matter of style, and most people are fine with it.

 

[Micah Cowan]

New code doesn't need to use gets. Recall that gets was
specified in the standard simply because it was a widely
used piece of the base library. Almost any function can
be abused, but that doesn't mean they all need to be
deprecated.

The difference is that there is no way that gets() can be used
/without/ abusing it. A possible exception might be offtopic concepts,
such as forking off and reading from a pipe via gets() where one
knows, with absolute certainty, that one will never get longer lines
than a particular length. Even then, I'd avoid it.

Since that's a fairly contrived example, /severely/ outweighed by the
fact that pretty much any other situation constitutes abuse, I'd say
that puts it in a class of its own. While itoa(), strcpy() and scanf()
may be easy to abuse, gets() is virtually impossible /not/ to abuse.

If it came to a vote, I'd certainly put mine in for deprecating and
eventually eliminating support for gets().

Just my $0.02, of course,
-Micah

 

[CBFalconer]

Well, no, a goal is for the new functions to be readily
edited into place (e.g. with an automated tool), and one
would naturally carry around a portable implementation of
the new function library with the app that uses it.

Any firm that lets any automated tool loose to revise their working
code is not long for this world.

New code doesn't need to use gets. Recall that gets was
specified in the standard simply because it was a widely
used piece of the base library. Almost any function can
be abused, but that doesn't mean they all need to be
deprecated.

gets is automatically abused. It is in the class of attractive
nuisances. It is unique in this characteristic.

Many programmers have written secure code in C despite
those possibilities. Indeed, if you think you need such
features for security, you're on the wrong path -- those
features take effect only when there is already an error
in your algorithm, and cannot in themselves correct the
algorithm. There are C development environments that can
help you detect such errors early on, if you really feel
insecure about your ability to code correctly.

I can take care of myself, thank you. I have a harder time
protecting myself (and others) from the inanities performed by the
incompetent.

That has never been a goal of the C standard, nor is it
something that programmers have been clamoring for. To
the contrary, there has been some demand for including
even more of the commonly-encountered library functions.

So? What is wrong with recognizing that there are two classes of
library contents, one is those things used to adapt to the actual
environment, whose implementation is not portable, and another is
those that are conveniences. Just because there are thousands of
newbies clamoring for routines to print decimal/hex/octal/binary
etc. representations doesn't mean that having such routines is
essential.

It's a matter of style, and most people are fine with it.

No, it's a matter of touch typing. The key location will vary.

--
"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/>

 

[Michael Mair]

Any firm that lets any automated tool loose to revise their
working code is not long for this world.

I know several that do and are still around. This involves
heavy testing on ugly samples beforehand and testing
afterwards but sometimes you have no choice when throwing
out something which came in because wrapping was not
demanded early enough. I have written such tools myself
for a very narrow scope of application.

gets is automatically abused. It is in the class of attractive
nuisances. It is unique in this characteristic.

Indeed, my fullest agreement.

So? What is wrong with recognizing that there are two classes of
library contents, one is those things used to adapt to the actual
environment, whose implementation is not portable, and another is
those that are conveniences. Just because there are thousands of
newbies clamoring for routines to print decimal/hex/octal/binary
etc. representations doesn't mean that having such routines is
essential.

Well, signals and other things cannot be used sensibly in a
portable way -- throw them out? Or expand them to usefulness?

No, it's a matter of touch typing. The key location will vary.

Does this mean that I am unfit for C because it is impossible
for me to type brackets and braces without completely changing
my hand position (bad keyboard layout for C purposes)? Underscores
are _much_ easier in comparison...

Cheers
Michael

 

[Richard Bos]

New code doesn't need to use gets. Recall that gets was
specified in the standard simply because it was a widely
used piece of the base library.

As long as gets() is still in the Standard, some new code _will_ use
gets(). gets() must go.

Richard

 

[Flash Gordon]

As long as gets() is still in the Standard, some new code _will_ use
gets(). gets() must go.

Agreed. I can see some justification for it having been included in C89
marked as deprecated (if it was not marked as deprecated in the original
C89 standard that was IMHO a mistake), but I would have thought that 10
years further with lots of experience of buffer overruns it should have
been deleted in the C99 standard. Since that was not done it should be
removed in the next amendment. If this breaks any existing code, then
that is code that *needs* to be either fixed or binned anyway.

I can't think of any other function in the C standard which is
fundamentally impossible to use in a safe way.
--
Flash Gordon
Living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidlines and intro -
http://clc-wiki.net/wiki/Intro_to_clc

 

[Antoine Leca]

En news:[email protected], CBFalconer wrotre:

I suggest cross-posting any publicity about such efforts to c.l.c,
with suitable follow-ups. That will at least have a chance of
alerting those with opinions.

I disagree.
If you want to follow on Usenet the evalution of the C standard, you are
supposed to subscribe to comp.std.c; it is the very purpose of having two
groups, isn't it? Furthermore, I think comp.lang.c is already pretty "high
volume", I do not believe further traffic sould be welcome there.

The most important events affecting the Standard are of course published to
comp.lang.c as well (should be with followup-to:comp.std.c set); the very
problem then is that because of the volume, it is quite easy to miss them.


Antoine

 

[Richard G. Riley]

Agreed. I can see some justification for it having been included in C89
marked as deprecated (if it was not marked as deprecated in the original
C89 standard that was IMHO a mistake), but I would have thought that 10
years further with lots of experience of buffer overruns it should have
been deleted in the C99 standard. Since that was not done it should be
removed in the next amendment. If this breaks any existing code, then
that is code that *needs* to be either fixed or binned anyway.

I can't think of any other function in the C standard which is
fundamentally impossible to use in a safe way.

Could someone explan to why me gets() is worse than any other function
that cant itself limit its input/working space to the size of the
buffer provided? e.g scanf, strtok. Or are all these function now
moved and "non standard"?

Of course I see the issues with it : I just wonder why it is being
picked on.

 

[kuyper]

Richard Bos wrote:
....

As long as gets() is still in the Standard, some new code _will_ use
gets(). gets() must go.

And even after gets() is removed from the standard, some new code will
continue to use gets(). That will be possible, because few
implementations can afford the consequences of failing to continue
supporting it as an extension to the standard, if only because of
legacy code. I'm not disagreeing with the goal; l'm just pointing out
that relief from the problems caused by gets() will not occur until
several decades after release of the first version of the standard from
which it is removed.

 

[pete]

Could someone explan to why me gets() is worse than any other function
that cant itself limit its input/working space to the size of the
buffer provided? e.g scanf, strtok.

What do you mean about strtok?
If you call strtok with two string pointers as arguments,
you have defined behavior. Teh Enb.

 

[Richard G. Riley]

What do you mean about strtok?
If you call strtok with two string pointers as arguments,
you have defined behavior. Teh Enb.

I was referring more to the fact its buggy in a reentrant system
since its internal databuffer is static. In addition it can continue
to read over "illegal" memory if the token isnt found before the end
of the passed in string buffer : in the same way almost virtually any
C func does. Dont know why it cropped into my head.

But anyway, regardless, why the pressure on the other function which
is undoubtedly in hundreds of thousands of lines of legacy code?