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.

[Flash Gordon]

Malcolm McLean wrote, On 18/11/07 08:39:

>
"CBFalconer " <cb********@yah oo.comwrote in message

>Need not, not must not. gets() (and any replacement) can be
written in standard C and fully satisfy all the specifications. As
evidenced by my ggets() and others.

On top of fgetc().

Or fgets. However, I accept your point.

>I wish the library had been divided into things implementable
within the language, and things requiring extensions. Although
actually doing it might have been a horrendous task, and it is now
too late to try.

The standard library fits into a small book. I don't think it would take
more than a few minutes to go through ticking each one.

assert (portable)
the isxxxx character macros (portable*)

No, they require system specific knowledge.

tolower (portable*)
toupper (portable*)
math.h functions (portable but)
setjmp (compiler-specific)
longjmp (compiler-specific)
stdarg,h (compiler-specific)
stdio.h - all functions that take a FILE parameter need system calls, as
do those whicht ake an implicit stdin / stdout.

At least two of the IO functions need to use a system specific method,
but the rest can be built on top of the two selected. The system
specific method is not necessarily a system call (on DOS it could be
accessing the keyboard and video HW directly, this might or might not be
a *good* choice but it is possible).

sprintf, vsprintf - (portable with one niggle)
remove, rename, tmpname - (system call)

Or other system specific method.

tmpfile - interesting one. Needs either a malloc(0 call or access tot he
filesystem.

I don't see how malloc(0) helps. You need access to the file system
because you are opening a file that does not already exist so you need
to either get the OS to do it or makes sure that the file you are
opening does not already exist.

atof, atoi, atol, strtod, strtol, strtoul (portable)
rand, srand (portable)
malloc family (in reality system, but theoretically portable except for
a niggle)
abort, exit (system / compiler-specific|)
atexit - (portable)

Not really, it depends on how the startup code works.

system - (system)
getenv - (system)
bsearch, qsort - (portable)
abs, labs - (portable)
div, ldiv - (anyone heard of these? compiler-specific)

You could write them in standard C. It might not be the most efficient
method, but...

string functions - (portable, in reality compiler-specific)
clock - (system)
time - (system)
difftime, mktime, ctime, gmtime, localtime, strftime - (portable as logn
as you know the internal time structure)

You you need to know the internal structure then it is not portable.

There, more or less done it.

Apart from the bits others disagree with, which shows it is not easy.

The problem is the division doesn't really work. sqrt() was originally a
portable function. Now most larger machines have dedicated root-finding
hardware, which in practise you must use.

That has applied to a number of the maths functions on some
implementations for a lot of years.

tolower and toupper, and the isxxxx macros can be written in C, but to
implement with any efficiency you need to know the execution character
encoding.

Others in the group need knowledge of the execution character set to
implement. For example, how do you implement isprint without knowing
which characters are printable?

Some functions, like longjmp(), do not need to make system calls, but
cannot be implemented without an intimate knowledge of the compiler.
sprinf() can be written completely portably, except for the %p field.

You can implement %p portably, you just write the pointer a byte at a
type for sizeof(void*) bytes.

The string functions can be portable, in reality you'd want to take
advantage of the alignment. malloc() realistically needs a system call
on all but the smallest machines that run only one program, but you can
write using a global arena, except that there is no cast iron way of
ensuring correct alignment in portable C.

I agree with what I believe your main point is, i.e. that trying to
split the functions in to ones that can be implemented portably and ones
that can't is pointless. My disputes of some of your categorisations
just show that it is not as easy to do as some people might think.
--
Flash Gordon

[Malcolm McLean]

"Richard Tobin" <ri*****@cogsci .ed.ac.ukwrote in message

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

>>Oh? Then why the frantic efforts right here on c.l.c to implement
sizeof?

As far as I can tell, most recent questions about this seem to be the
result of one particular C programming course, in India.

I'd expect an Indian to ask why sizeof(void) does not equal zero.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Tor Rustad]

Keith Thompson wrote:

CBFalconer wrote:

>Malcolm McLean wrote:

>>"Richard Heathfield" <rj*@see.sig.in validwrote:

It is possible, though rather difficult, to implement a safe
gets(), that is to say one that always terminates the program
with an error message if the buffer is exceeded.
Show me.
We'll declare that pointer cosist of three values - the address,
the start of the object, and the end of the object. Now in the
write to array code we specify that if the address execceds the
end of the object, the program is to terminate with an error
meaage.

No good. Pointers do not necessarily contain those components. You
have to make it safe within the guarantees provided by the C
standard.

No, he doesn't. You're asking for more than Malcolm claimed.

Malcolm didn't claim that it could be made safe within the gaurantees
provided by the C standard. His claim is a much more modest one,
that it's possible for a (hypothetical) C implementation to provide a
"safe" gets() function, and I believe he's correct.

I don't think so.

His solution requires the use of "fat pointers", which are not

Methinks, fat pointers break pointer arithmetic and thus require at
least a new language dialect.

Also, the buffer passed to gets() may not be malloc'ed, but can be an
array, or even a sub-array.

I believe Malcolm's claim as stated is correct. It's not particularly
useful, but he didn't claim that it was; I believe it was merely an
intellectual excercise, not a serious proposal.

I can't see how Malcolm's claim can be correct, the only way.... is IF
the implementation restrict gets() buffer writes to some hard upper
limit, let say one less than MAX_GETS_WRITE, then the

char buf[MAX_GETS_WRITE];

gets(buf);

would be safe.

--
Tor <bw****@wvtqvm. vw | tr i-za-h a-z>

[jameskuyper]

Tor Rustad wrote:

Keith Thompson wrote:

....

His solution requires the use of "fat pointers", which are not

Methinks, fat pointers break pointer arithmetic and thus require at
least a new language dialect.

I don't believe that's the case; could you explain what breakage you
would expect?

[Kenny McCormack]

In article <7a************ *************** *******@d50g200 0hsf.googlegrou ps.com>,
<ja*********@ve rizon.netwrote:

>Tor Rustad wrote:

>Keith Thompson wrote:

...

His solution requires the use of "fat pointers", which are not

Methinks, fat pointers break pointer arithmetic and thus require at
least a new language dialect.

I don't believe that's the case; could you explain what breakage you
would expect?

While I agree with the sentiment behind Malcolm's idea (and I'm of the
opinion that most of the naysaying in this thread is of the usual
"usual negative comments" variety as noted by Jacob - i.e., the usual
nonsense), I do see this as being a bit difficult. It boils down to: Is
it possible to keep enough information in the system so that we can
know, for any possible pointer and/or pointer value, how much valid
memory there is after that pointer?

I can't think of any counter-examples off-hand, but that doesn't mean
there aren't any.

[Keith Thompson]

Tor Rustad wrote:

Keith Thompson wrote:

>CBFalconer wrote:

>>Malcolm McLean wrote:
"Richard Heathfield" <rj*@see.sig.in validwrote:

>It is possible, though rather difficult, to implement a safe
>gets(), that is to say one that always terminates the program
>with an error message if the buffer is exceeded.
Show me.
We'll declare that pointer cosist of three values - the address,
the start of the object, and the end of the object. Now in the
write to array code we specify that if the address execceds the
end of the object, the program is to terminate with an error
meaage.

No good. Pointers do not necessarily contain those components. You
have to make it safe within the guarantees provided by the C
standard.

No, he doesn't. You're asking for more than Malcolm claimed.

Malcolm didn't claim that it could be made safe within the gaurantees
provided by the C standard. His claim is a much more modest one,
that it's possible for a (hypothetical) C implementation to provide a
"safe" gets() function, and I believe he's correct.

I don't think so.

>His solution requires the use of "fat pointers", which are not

Methinks, fat pointers break pointer arithmetic and thus require at
least a new language dialect.

Hmm. You might be right. I don't care enough about a hypothetical
"safe" gets() to work out the details.

Also, the buffer passed to gets() may not be malloc'ed, but can be an
array, or even a sub-array.

Certainly. My assumption is that *all* pointers would be "fat". For
example, if you take the address of a single declared object, the
resulting pointer value includes the information that it points to a
single object (and dereferencing ptr+1 is therefore not allowed). When
an array name decays to a pointer to its first element, that pointer
value contains bounds information about the array. Pointer arithmetic
preserves and updates the bounds information.

A "fat" pointer might consist of three elements: the address of the
zeroth element of the array that contains the object being pointed to,
the index of the specific element, and the length of the array. All
operations that create pointers must correctly initialize this
information; all operations on pointers must preserve and update it.

I *think* that such an implementation could conform to the C standard,
and could detect many pointer bugs (at a perhaps unacceptable cost in
performance).

>I believe Malcolm's claim as stated is correct. It's not particularly
useful, but he didn't claim that it was; I believe it was merely an
intellectual excercise, not a serious proposal.

I can't see how Malcolm's claim can be correct, the only way.... is IF
the implementation restrict gets() buffer writes to some hard upper
limit, let say one less than MAX_GETS_WRITE, then the

char buf[MAX_GETS_WRITE];

gets(buf);

would be safe.

Such an implementation of gets() would be non-conforming, since it
wouldn't allow you to read into a buffer bigger than MAX_GETS_WRITE bytes.

--
Keith Thompson (The_Other_Keit h) <ks***@mib.or g>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Flash Gordon]

Keith Thompson wrote, On 20/11/07 22:36:

Tor Rustad wrote:

>Keith Thompson wrote:

>>CBFalconer wrote:
Malcolm McLean wrote:
"Richard Heathfield" <rj*@see.sig.in validwrote:
>
>>It is possible, though rather difficult, to implement a safe
>>gets(), that is to say one that always terminates the program
>>with an error message if the buffer is exceeded.
>Show me.
We'll declare that pointer cosist of three values - the address,
the start of the object, and the end of the object. Now in the
write to array code we specify that if the address execceds the
end of the object, the program is to terminate with an error
meaage.

No good. Pointers do not necessarily contain those components. You
have to make it safe within the guarantees provided by the C
standard.

No, he doesn't. You're asking for more than Malcolm claimed.

Malcolm didn't claim that it could be made safe within the gaurantees
provided by the C standard. His claim is a much more modest one,
that it's possible for a (hypothetical) C implementation to provide a
"safe" gets() function, and I believe he's correct.

I don't think so.

>>His solution requires the use of "fat pointers", which are not

Methinks, fat pointers break pointer arithmetic and thus require at
least a new language dialect.

Hmm. You might be right. I don't care enough about a hypothetical
"safe" gets() to work out the details.

>Also, the buffer passed to gets() may not be malloc'ed, but can be an
array, or even a sub-array.

Certainly. My assumption is that *all* pointers would be "fat". For
example, if you take the address of a single declared object, the
resulting pointer value includes the information that it points to a
single object (and dereferencing ptr+1 is therefore not allowed). When
an array name decays to a pointer to its first element, that pointer
value contains bounds information about the array. Pointer arithmetic
preserves and updates the bounds information.

A "fat" pointer might consist of three elements: the address of the
zeroth element of the array that contains the object being pointed to,
the index of the specific element, and the length of the array. All
operations that create pointers must correctly initialize this
information; all operations on pointers must preserve and update it.

I *think* that such an implementation could conform to the C standard,
and could detect many pointer bugs (at a perhaps unacceptable cost in
performance).

Here is a problem for it. Assume that all allocations succeed and each
function is in a separate TU with appropriate headers etc...

char *p1;
char *p2;
char *p3;

char *alloc()
{
return p2 = p3 = malloc(5);
}

char *ralloc(char *orig)
{
return realloc(orig,10 );
}

char *foo(void)
{
p1 = ralloc(alloc()) ;
if (p1 == p2)
strcpy(p3,"Hell o World");
else
strcpy(p3,"Bye" );
}

If realloc has not moved the pointer then how will the size information
in the fat pointer p3 get updated? This is a contrived example, but
there might be more likely situations that would also be a problem, so
there would be a lot of work to nail down everything for a fat pointer
system.

>>I believe Malcolm's claim as stated is correct. It's not particularly
useful, but he didn't claim that it was; I believe it was merely an
intellectua l excercise, not a serious proposal.

I can't see how Malcolm's claim can be correct, the only way.... is IF
the implementation restrict gets() buffer writes to some hard upper
limit, let say one less than MAX_GETS_WRITE, then the

char buf[MAX_GETS_WRITE];

gets(buf);

would be safe.

Such an implementation of gets() would be non-conforming, since it
wouldn't allow you to read into a buffer bigger than MAX_GETS_WRITE bytes.

Even if it returned NULL to indicate an error?
--
Flash Gordon

[Ben Bacarisse]

Flash Gordon <sp**@flash-gordon.me.ukwri tes:

Keith Thompson wrote, On 20/11/07 22:36:

<snip>

>A "fat" pointer might consist of three elements: the address of the
zeroth element of the array that contains the object being pointed
to, the index of the specific element, and the length of the array.
All operations that create pointers must correctly initialize this
information; all operations on pointers must preserve and update it.

I *think* that such an implementation could conform to the C
standard, and could detect many pointer bugs (at a perhaps
unacceptable cost in performance).

Here is a problem for it. Assume that all allocations succeed and each
function is in a separate TU with appropriate headers etc...

char *p1;
char *p2;
char *p3;

char *alloc()
{
return p2 = p3 = malloc(5);
}

char *ralloc(char *orig)
{
return realloc(orig,10 );
}

char *foo(void)
{
p1 = ralloc(alloc()) ;
if (p1 == p2)
strcpy(p3,"Hell o World");
else
strcpy(p3,"Bye" );
}

If realloc has not moved the pointer then how will the size
information in the fat pointer p3 get updated?

I don't think that example is valid. An implementation is allowed to
have realloc always move the object, and that is what I'd do if I were
implementing fat pointers.

--
Ben.

[RoS]

In data Tue, 20 Nov 2007 23:18:50 +0000, Flash Gordon scrisse:

>Here is a problem for it. Assume that all allocations succeed and each
function is in a separate TU with appropriate headers etc...

char *p1;
char *p2;
char *p3;

char *alloc()
{
return p2 = p3 = malloc(5);
}

char *ralloc(char *orig)
{
return realloc(orig,10 );
}

char *foo(void)
{
p1 = ralloc(alloc()) ;
if (p1 == p2)
strcpy(p3,"Hell o World");
else
strcpy(p3,"Bye" );
}

If realloc has not moved the pointer then how will the size information
in the fat pointer p3 get updated?

it is update from realloc

if realloc not move the pointer, p3 point to a valid address
and its size is changed from realloc (aggiornato da realloc)

if realloc move the pointer, p3 point to not valid address

[Richard Bos]

Tor Rustad <to********@hot mail.comwrote:

Keith Thompson wrote:

CBFalconer wrote:

Malcolm McLean wrote:
"Richard Heathfield" <rj*@see.sig.in validwrote:

It is possible, though rather difficult, to implement a safe
gets(), that is to say one that always terminates the program
with an error message if the buffer is exceeded.
Show me.
We'll declare that pointer cosist of three values - the address,
the start of the object, and the end of the object. Now in the
write to array code we specify that if the address execceds the
end of the object, the program is to terminate with an error
meaage.

No good. Pointers do not necessarily contain those components. You
have to make it safe within the guarantees provided by the C
standard.

No, he doesn't. You're asking for more than Malcolm claimed.

Malcolm didn't claim that it could be made safe within the gaurantees
provided by the C standard. His claim is a much more modest one,
that it's possible for a (hypothetical) C implementation to provide a
"safe" gets() function, and I believe he's correct.

I don't think so.

In theory, he's correct. In practice, it depends on whether you think
either a predictable crash or predictable loss of data counts as "safe".
It is at least generally safer than having gets() write all over the end
of its target.

His solution requires the use of "fat pointers", which are not

Methinks, fat pointers break pointer arithmetic and thus require at
least a new language dialect.

No, they don't. Pointer arithmetic beyond the bounds of an object has
undefined behaviour anyway, and within an object it works fine with fat
pointers. Adding an integer to a pointer is now a matter of adding it to
a single field of the pointer structure, rather than to a flat index,
but something similar is needed with, e.g., segmented architectures.

Also, the buffer passed to gets() may not be malloc'ed, but can be an
array, or even a sub-array.

So? A sub-array simply has it recorded, in its fat pointer data, that it
is a sub-array, and what of.

Richard