Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Why is it dangerous?

Reply
Thread Tools

Why is it dangerous?

 
 
CBFalconer
Guest
Posts: n/a
 
      08-10-2008
santosh wrote:
> CBFalconer wrote:
>> Ian Collins wrote:
>>> Julian wrote:
>>>
>>>> Please advise my instructor says gcc is overly pedantic.
>>>
>>> As Richard said, the opposite is true unless you invoke gcc with
>>> the correct options. That's why it has a -pedantic option!
>>>
>>> As a learner using gcc, you should use
>>>
>>> gcc -ansi -Wall -pedantic
>>>
>>> as a minimum set of options. Substitute '-std=c99' for '-ansi'
>>> if you are learning C99.

>>
>> Correction: That omits many useful tests. I suggest:
>>
>> gcc -W -Wall -ansi -pedantic
>>
>> for better error detection.

>
> I would also recommend:
>
> -Wfloat-equal
> -Wshadow
> -Wpointer-arith
> -Wbad-function-cast
> -Wcast-qual
> -Wcast-align
> -Wwrite-strings
> -Wstrict-prototypes
> -Wold-style-definition
> -Wmissing-prototypes
> -Wredundant-decls
> -Wunreachable-code


I wouldn't, although those may be useful. The OP is obviously a
newbie, and is not going to remember all that. It is only useful
when implemented via an alias, a script, or a makefile, etc. What
I recommended is a minimum to ensure reasonably correct standard C
code.

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


 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      08-10-2008
santosh wrote:
> Harald van D?k wrote:
>> santosh wrote:
>>> CBFalconer wrote:
>>>
>>>> Correction: That omits many useful tests. I suggest:
>>>>
>>>> gcc -W -Wall -ansi -pedantic
>>>>
>>>> for better error detection.
>>>
>>> I would also recommend:
>>> [...]
>>> -Wwrite-strings

>>
>> I would not, since it deliberately makes the compiler nonconforming.
>> For those that understand in what ways, it can be useful, but they
>> can find the option themselves. CBFalconer included that option in
>> his recommendations recently, and I'm glad he dropped it.

>
> Thanks for that. I do remember that subthread now, but I passed over
> it, being pressed for time. Now, to the Google Groups archive...


I didn't drop it. I conceded your 'non-standard' point. I
maintain that, for new code, including it will result in better
code, and maintain conformity. It may object to some actually
conforming code.

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


 
Reply With Quote
 
 
 
 
Richard
Guest
Posts: n/a
 
      08-10-2008
Richard Heathfield <(E-Mail Removed)> writes:

> Julian said:
>
>> 'evening.
>>
>> I'm not new to C and have been programming in it since I was 8 but
>> here's a strange problem I've never seen before.
>>
>> When I compile a program from our C course with a windows compiler
>> there is no problem but when I try to compile it with a linux compiler
>> it complains that
>>
>> a_03.c.text+0x4d): warning: the `gets' function is dangerous
>> and should not be used.
>>
>> Is linux more dangerous than windows?

>
> No. Your Linux compiler warned you about a dangerous function that should
> never be used.


Total and utter nonsense. C is used all over the place for creating
elements which are under strict control and the program/process/function
has a totally controlled and defined input stream. In those scenarios
gets is used flawlessly in millions of programs around the world.

if you can NOT define the input then I would agree. But in the real
world the input is indeed guarenteed in a properly functioning
system. if the system isn't well defined then all "bets are off" since
you can pretty much be sure that undefined behaviour/input has already
compromised the process pipeline.


 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      08-10-2008
Malcolm McLean wrote:
> "Gordon Burditt" <(E-Mail Removed)> wrote:
>
>> There is no non-dangerous gets() function with the same interface.
>> The non-dangerous function is called fgets().

>
> This is a hardy annual. Of course fgets() can be used safely, but
> won't be. For instance Richard Heathfield posted a dangerous use of
> fgets() in this very thread. It will give the wrong answer if the
> user enters a string of over 2000 characters. Of course it is not
> dangerous in a little exercise program that doesn't do anything,
> but then neither is gets().
>
> To use fgets() safely you must check for the newline. If it is not
> present a buffer overflow occurred. So you must then take action
> against the buffer to ensure that the next read doesn't get the
> remainder of the previous line.


Or just get the remainder of the line. No overflow has occurred.

And you can avoid all those problems by using the (released to
public domain) ggets() function, available in standard C source
form at:

<http://cbfalconer.home.att.net/downlod/ggets.zip>

ggets gets complete lines, is safe, and has the simplicity of
gets. Malicious users can run the system out of assignable heap
memory, but will normally have to work hard to do so.

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


 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      08-10-2008
Richard wrote:

> Richard Heathfield <(E-Mail Removed)> writes:
>
>> Julian said:
>>
>>> 'evening.
>>>
>>> I'm not new to C and have been programming in it since I was 8 but
>>> here's a strange problem I've never seen before.
>>>
>>> When I compile a program from our C course with a windows compiler
>>> there is no problem but when I try to compile it with a linux
>>> compiler it complains that
>>>
>>> a_03.c.text+0x4d): warning: the `gets' function is dangerous
>>> and should not be used.
>>>
>>> Is linux more dangerous than windows?

>>
>> No. Your Linux compiler warned you about a dangerous function that
>> should never be used.

>
> Total and utter nonsense. C is used all over the place for creating
> elements which are under strict control and the
> program/process/function has a totally controlled and defined input
> stream. In those scenarios gets is used flawlessly in millions of
> programs around the world.
>
> if you can NOT define the input then I would agree. But in the real
> world the input is indeed guarenteed in a properly functioning
> system. if the system isn't well defined then all "bets are off" since
> you can pretty much be sure that undefined behaviour/input has already
> compromised the process pipeline.


I wonder, can you give examples of sources of perfectly controlled and
defined input? Certainly disk files can be tampered, as can pipes,
sockets and almost every other device. Why risk it with gets when fgets
is just as easy and safer?

 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      08-10-2008
On Sun, 10 Aug 2008 13:27:34 +0530, santosh wrote:
> CBFalconer wrote:
>> Correction: That omits many useful tests. I suggest:
>> gcc -W -Wall -ansi -pedantic
>> for better error detection.

>
> I would also recommend:
> [...]
> -Wpointer-arith


This is redundant, since it's already enabled by -pedantic.

 
Reply With Quote
 
Antoninus Twink
Guest
Posts: n/a
 
      08-10-2008
On 10 Aug 2008 at 13:17, santosh wrote:
> Richard wrote:
>> Total and utter nonsense. C is used all over the place for creating
>> elements which are under strict control and the
>> program/process/function has a totally controlled and defined input
>> stream. In those scenarios gets is used flawlessly in millions of
>> programs around the world.

>
> I wonder, can you give examples of sources of perfectly controlled and
> defined input? Certainly disk files can be tampered, as can pipes,
> sockets and almost every other device.


True. The world might also be destroyed in a nuclear holocaust while
your throwaway program is reading its non-life-critical data, so why
take the risk of programming at all? Drink a beer, get laid, and wait
for the mushroom cloud to take you.

 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      08-10-2008
santosh <(E-Mail Removed)> writes:

> Richard wrote:
>
>> Richard Heathfield <(E-Mail Removed)> writes:
>>
>>> Julian said:
>>>
>>>> 'evening.
>>>>
>>>> I'm not new to C and have been programming in it since I was 8 but
>>>> here's a strange problem I've never seen before.
>>>>
>>>> When I compile a program from our C course with a windows compiler
>>>> there is no problem but when I try to compile it with a linux
>>>> compiler it complains that
>>>>
>>>> a_03.c.text+0x4d): warning: the `gets' function is dangerous
>>>> and should not be used.
>>>>
>>>> Is linux more dangerous than windows?
>>>
>>> No. Your Linux compiler warned you about a dangerous function that
>>> should never be used.

>>
>> Total and utter nonsense. C is used all over the place for creating
>> elements which are under strict control and the
>> program/process/function has a totally controlled and defined input
>> stream. In those scenarios gets is used flawlessly in millions of
>> programs around the world.
>>
>> if you can NOT define the input then I would agree. But in the real
>> world the input is indeed guarenteed in a properly functioning
>> system. if the system isn't well defined then all "bets are off" since
>> you can pretty much be sure that undefined behaviour/input has already
>> compromised the process pipeline.

>
> I wonder, can you give examples of sources of perfectly controlled and
> defined input? Certainly disk files can be tampered, as can pipes,
> sockets and almost every other device. Why risk it with gets when fgets
> is just as easy and safer?


If I have a well defined pipeline then any deviance make the entire line
corrupt.

If I have a process whose DEFINED input is say, 16 characters at a time
on its standard input then its not its job to ensure thats what
comes. Dont believe me? Try calling strcpy with NULL pointer as the
destination.

Since it has NO way of reporting back errors to the program feeding it,
what should me module do? Carry on processing this rogue data?

The point is this - one can worry all day long. Once can also be
practical and "real".

Its like the malloc business. If malloc fails for a few bytes the chance
of that program not exhibiting "Undefined Bahvaiour" because you checked
the return code is practically nil.



 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      08-10-2008
On Aug 10, 12:42*pm, Richard<(E-Mail Removed)> wrote:
> Richard Heathfield <(E-Mail Removed)> writes:
> > Julian said:


> >> I'm not new to C and have been programming in it since I was 8 but
> >> here's a strange problem I've never seen before.

>
> >> When I compile a program from our C course with a windows compiler
> >> there is no problem but when I try to compile it with a linux compiler
> >> it complains that

>
> >> a_03.c.text+0x4d): warning: the `gets' function is dangerous
> >> and should not be used.

>
> >> Is linux more dangerous than windows?

>
> > No. Your Linux compiler warned you about a dangerous function that should
> > never be used.

>
> Total and utter nonsense. C is used all over the place for creating
> elements which are under strict control and the program/process/function
> has a totally controlled and defined input stream. In those scenarios
> gets is used flawlessly in millions of programs around the world.
>
> if you can NOT define the input then I would agree. But in the real
> world the input is indeed guarenteed in a properly functioning
> system.


hardly. Much web based software does not have total control
of its inputs. Compilers don't have TCOI. Even if the other end of
your
"link" is "trusted" there can be errors made. Yes, you test your
software but
why not on the length of input

> if the system isn't well defined then all "bets are off" since
> you can pretty much be sure that undefined behaviour/input has already
> compromised the process pipeline


how many bugs has gets() caused? Windows certainly. Wasn't the Unix
worm gets() based?


--
Nick Keighley
 
Reply With Quote
 
Serve Lau
Guest
Posts: n/a
 
      08-10-2008

"Antoninus Twink" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> True. The world might also be destroyed in a nuclear holocaust while
> your throwaway program is reading its non-life-critical data, so why
> take the risk of programming at all? Drink a beer, get laid, and wait
> for the mushroom cloud to take you.


I agree except on one thing. I'd drink the beer last

>


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Cisco 2611 and Cisco 1721 : Why , why , why ????? sam@nospam.org Cisco 10 05-01-2005 08:49 AM
Why, why, why??? =?Utf-8?B?VGltOjouLg==?= ASP .Net 6 01-27-2005 03:35 PM
Why Why Why You HAVE NO IDEA MCSE 31 04-24-2004 06:40 PM



Advertisments