why the usage of gets() is dangerous.

[jayapal]

Hi all,

Whenever I use the gets() function, the gnu c compiler gives a
warning that it is dangerous to use gets(). why...?

regards,
jayapal.

[=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F]

On Sat, 24 Nov 2007 10:16:52 -0500, CBFalconer wrote:

So here is another. Imagine a routine to upshift a string. One routine
receives a char, and answere with 'this is lower case'. Another receives
a char, and answers by replacing it with the upper case equivalent.
Both are passed pointers.

Assuming the original data is a string, the calling routine will pass
something like:

p = &(s[3]); or p = s + 3; (p is parameter)

For the reading routine, there is no harm in allowing reads from (p -
n), where n can be 0 through 3. For the writing routine, this is not
allowable.

Why not? Is it because the behaviour would be undefined, or is it because
the function's actions would be different from its description? If the
former, I'm not seeing it, so could you please explain? If the latter, as
long as it's valid C, there's no reason why an implementation would or
should complain about it.

[RoS]

In data Thu, 22 Nov 2007 08:57:22 +0100, RoS scrisse:

>if the compiler has a array of elements
arrayelement{c har* where; size_t size}
that point to each memory object in the memory returned from malloc or
allocated in the stack
it is possible to write a routine that says if one address is allow to
read-write or not; this mean it is possible to write a safe gets()
in the sense: make gets() function not overflow the input array

int isok(char* a)
{arrayelemen t *p=&whereitis;
for(i=0; p[i].where!=0; ++i)
{if(a>p[i].where && a<p[i].where+p[i].size)
return 1;
}
return 0;
}

size_t sizefromhere(ch ar* a)
{arrayelemen t *p=&whereitis;
for(i=0; p[i].where!=0; ++i)
{if(a>p[i].where && a<p[i].where+p[i].size)
return p[i].size-(a-p[i].where);
}
return 0;
}
so gets could be something like

yes gets if its argument is a stack memory should return always 0
(why waste cicles and memory space for debug automatic objects?)

if the argument is malloc heap memory (that in my case has the list of
avaiable memory and their size) could be somethign like below

>char* gets(char* buf)
{char *p;
int c;
size_t limit, h;
p=buf;
limit=sizefromh ere(buf);
if(limit==0) return 0;
h=0;
l0:;
if(h==limit)
{l1:;
p[h]=0;
return 0;
}
c=getchar();
if(c==EOF)
{if(ferror(stdi n)) goto l1
p[h]=0;
return buf;
}
if(c=='\n')
{p[h]='\n'; /* limit-1 */
p[h+1]=0; /* limit */
return buf;
}
p[h]=c; ++h; goto l0;
}

[Kenny McCormack]

In article <aL************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

>James Kuyper said:

<snip>

>Also, quite frankly, it's virtually impossible to write up something
that long and complicated without making several mistakes, and I prefer
to avoid publishing something like that on a public forum known for the
viciousness with which mistakes are attacked.

On the whole, mistakes in clc articles are identified and corrected, but
not attacked. I have made a great many mistakes in clc articles over the
last few years, but I have never been attacked for them (except by trolls,
and I don't count those).

That's because you are an accepted "regular" and most defer to you.
Or, to put it another way, your definition of "troll" is:

One who has the balls to attack you.

(Therefore, it is definitionally true that the only posters who attack
you are "trolls").

>I have also corrected a great many mistakes in
clc articles over the last few years, but I've never attacked a mistake.

Liar. Two words: Jacob Navia.

[Flash Gordon]

CBFalconer wrote, On 24/11/07 15:24:

santosh wrote:

><ja*********@v erizon.netwrote :

<snip fat pointer C implementation discussion>

>>production code. I say "would be", because I believe that actual
implementatio ns with fat pointers are rare; possibly non-existent.

Apparently not non-existent, if the following page is to be believed.

<http://www.springerlin k.com/content/qhb2pnhvr9w96nf c/>

Also Cyclone is well known language based on C, which also implements
fat pointers.

However this is about C, not Cyclone. I have no difficulty
implementing proper range checking in Pascal, for example. Having
done so, I have a fair idea of the evil difficulties of adapting to
C pointers.

Read the post again and then read the article. Once sentence in
particular from the article is, "This paper describes a memory-safe
implementation of the full ANSI C language."

The reference to Cyclone was a reference to something else related and
potentially interesting, not a reference to the article. Hence the word
"Also" in the post.
--
Flash Gordon

[Flash Gordon]

�Harald van Dijk wrote, On 24/11/07 17:29:

On Sat, 24 Nov 2007 10:16:52 -0500, CBFalconer wrote:

>So here is another. Imagine a routine to upshift a string. One routine
receives a char, and answere with 'this is lower case'. Another receives
a char, and answers by replacing it with the upper case equivalent.
Both are passed pointers.

Assuming the original data is a string, the calling routine will pass
something like:

p = &(s[3]); or p = s + 3; (p is parameter)

For the reading routine, there is no harm in allowing reads from (p -
n), where n can be 0 through 3. For the writing routine, this is not
allowable.

Why not? Is it because the behaviour would be undefined, or is it because
the function's actions would be different from its description? If the
former, I'm not seeing it, so could you please explain? If the latter, as
long as it's valid C, there's no reason why an implementation would or
should complain about it.

I agree. Further, if the routine that is not allowed to write has the
parameter declared as a pointer to const the compiler will complain
about it.

Someone else has posted a link to an article about a fat pointer
implementation of C thus providing strong evidence that such an
implementation is possible.

My position is that it is difficult rather than impossible.
--
Flash Gordon

[Flash Gordon]

jacob navia wrote, On 24/11/07 16:38:

James Kuyper wrote:

[snip]

>Also, quite frankly, it's virtually impossible to write up something
that long and complicated without making several mistakes, and I
prefer to avoid publishing something like that on a public forum known
for the viciousness with which mistakes are attacked.

I think this is the big problem with this forum, and I have been
trying to fight this for over 2 years now. The only solution is to
ignore the vicious attacks.

So we should ignore you? You frequently attack people.

Keep in mind that those people are
just unable to propose anything positive and their only way to
express themselves is through those attacks.

Think about the fact that you frequently attack.

It suffices to ignore them, and discuss normally.

So why do you attack and ascribe to people motives and opinions that
they do not have?

For instance the rounding thread, it was full of
those. I ignore them, and I think my opinion came through
at the end.

Your opinion was clear. It was not sensible to offer code that did not
meet the stated requirements without telling the OP that it did not and
why not, and I would not say that you one the argument either since
there is no independent arbiter.
--
Flash Gordon

[Chris Torek]

In article <fi********@new s2.newsguy.comI described various
techniques for constructing and testing "fat pointers".

In article <47************ ***@yahoo.com>,
CBFalconer <cb********@mai neline.netwrote :

>Just picking on one thing, based on it has to work everywhere, or
it is useless.

There is a difference between "only catches some mistakes right away"
and "is useless". Still:

>If a pointer is malloced, and then copied while the original is
realloced, it may be totally invalid. The above won't pick this up.

"The above" was merely the description of a fat pointer.

If you want the runtime system to catch the use of a pointer value
that was once valid due to a malloc(), but is now invalid due to
a later realloc() or free(), you probably want one of the compilers[%]
that "up-converts" a "thin pointer" as needed, using the runtime
tables I described. This has a time penalty:

>(If every use of a pointer is accompanied by a grand sweep of
possibilitie s, things may be possible. However the resultant code
would be totally useless and spend all its time sweeping.)

It is not "every use", but rather "every case where the compiler
cannot prove that a cached fat pointer is still valid". For
instance, in the code fragment:

char *little, *big;
size_t i, len;
...
len = strlen(little);
for (i = 0; i < len; i++)
big[i] = toupper((unsign ed char)little[i]);

the compiler needs to do at most two lookups to validate the pointers
"little" and "big" before the loop starts. (If it is sufficiently
clever, it can even do the bounds-checking at that time as well,
using 0 and len as the minimum and maximum offsets to be applied
to the "current value" of each pointer.)

A not-so-smart compiler has to check each pointer each time, or
we might do something like this:

for (i = 0; i < len; i++) {
uglify(&big, &little);
big[i] = toupper((unsign ed char)little[i]);
}

after which, yes, "every" use of the two pointers (in this case)
is "accompanie d by a grand sweep of possibilities", which causes
a noticeable slowdown.

As I said, there are tradeoffs.

[% I say this as if there are lots of bounds-checking compilers to
choose from, when in fact they are as rare as correct comp.lang.c
posts. :-) ]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[James Kuyper]

CBFalconer wrote:

Flash Gordon wrote:

....

>So provide such an impossibility then you will have proved your
position.

So here is another. Imagine a routine to upshift a string. One
routine receives a char, and answere with 'this is lower case'.
Another receives a char, and answers by replacing it with the upper
case equivalent. Both are passed pointers.

Assuming the original data is a string, the calling routine will
pass something like:

p = &(s[3]); or p = s + 3; (p is parameter)

For the reading routine, there is no harm in allowing reads from (p
- n), where n can be 0 through 3. For the writing routine, this is
not allowable. How do we separate the actions?

Distinguishing readable from writable memory is what 'const' is for. Fat
pointers are for bounds checking.

You don't indicate whether s is a pointer or an array. For simplicity,
I'll assume that it's an array of N chars. Then when s decays into a
pointer, that pointer's limits are set to s and s+N. When s+3 is
evaluated, it inherits those same limits, and they are retained when
that pointer value is stored in p. As a result, any attempt to calculate
p+i for i<-3 or i>N-3 will trigger a failure mechanism. any attempt to
evaluate p[i] for i<-3 or i >= N-3 will trigger a failure mechanism, and
that's true whether the access is for read or write.

[CBFalconer]

$)CHarald van D)&k wrote:

CBFalconer wrote:

>So here is another. Imagine a routine to upshift a string. One
routine receives a char, and answere with 'this is lower case'.
Another receives a char, and answers by replacing it with the
upper case equivalent. Both are passed pointers.

Assuming the original data is a string, the calling routine will
pass something like:

p = &(s[3]); or p = s + 3; (p is parameter)

For the reading routine, there is no harm in allowing reads from
(p - n), where n can be 0 through 3. For the writing routine,
this is not allowable.

Why not? Is it because the behaviour would be undefined, or is
it because the function's actions would be different from its
description? If the former, I'm not seeing it, so could you
please explain? If the latter, as long as it's valid C, there's
no reason why an implementation would or should complain about
it.

Because a char was passed, not an array. So a means has to be
found to separate the two. Remember that the system is pointless
unless it works all the time.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home .att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Chris Torek wrote:

>
In article <fi********@new s2.newsguy.comI described various
techniques for constructing and testing "fat pointers".

CBFalconer <cb********@mai neline.netwrote :

>Just picking on one thing, based on it has to work everywhere,
or it is useless.

There is a difference between "only catches some mistakes right
away" and "is useless". Still:

>If a pointer is malloced, and then copied while the original is
realloced, it may be totally invalid. The above won't pick
this up.

"The above" was merely the description of a fat pointer.

For example, I conclude that the only reasonable way to handle C
style pointers is to make them ALL indirect. I.e. the value in the
running code points at a descriptor, which separates auto, static,
allocated pointers and includes limits, etc. Now a modification of
such a pointer requires another descriptor, etc., which in turn
requires storage. However a copy can simply point to the same
descriptor. In theory this can be done, but in practice it would
mean an unusable language.

I admit I have not taken the time to read your proposal. It is
quite possible we have much different views of feasibility.

.... snip ...

It is not "every use", but rather "every case where the compiler
cannot prove that a cached fat pointer is still valid". For
instance, in the code fragment:

char *little, *big;
size_t i, len;
...
len = strlen(little);
for (i = 0; i < len; i++)
big[i] = toupper((unsign ed char)little[i]);

the compiler needs to do at most two lookups to validate the
pointers "little" and "big" before the loop starts. (If it is
sufficiently clever, it can even do the bounds-checking at that
time as well, using 0 and len as the minimum and maximum offsets
to be applied to the "current value" of each pointer.)

Point to be made here. The above is user code, calling system
functions with known abilities and requirements (assuming the often
unfollowed directions are followed :-) ). However the common
situation is to call user routines, located in different
compilations, and with no known requirements beyond the argument
types. Now the compiler doesn't even know what to look for. It
doesn't read comments.

And even in the above, what supplied big? How did it find the
storage limits? How does it _always_ know that big is a pointer to
a char 10 bytes from the end of a malloced area. Etc.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home .att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com