«

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.

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.

Richard Heathfield <> 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.

Malcolm McLean wrote:
> "Gordon Burditt" <> 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.

Richard wrote:

> Richard Heathfield <> 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?

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.

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.

santosh <> writes:

> Richard wrote:
>
>> Richard Heathfield <> 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.

On Aug 10, 12:42*pm, Richard<rgr...@gmail.com> wrote:
> Richard Heathfield <r...@see.sig.invalid> 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

"Antoninus Twink" <> schreef in bericht
news:...
> 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

>