Help in this programm in C

[Flash Gordon]

I had a bit more time so I took another look.


There that little devil is! It's global, that's considered bad form but I
could live with that in this instance. But you need to initialize it to
NULL! The code in the sequel depends on that!

If, as you say, it is a global, then the C standard guarantees that it
is initialised to a null pointer.

I still think the best thing to do is start over. If you follow all the
tweaking and formatting and syntax bitching in this thread and fix all that
up; I would guess the chances of your program working, after all that
effort, at about 1000:1. This is a pretty elementary error.

Nope, yours is the elementary error. deppy_3 would be better off
following the advice of those who know C better than you, such as
Richard Heathfield.

 

[Dann Corbit]

None, really. gets() is the only one that can _not_ be used safely.
Functions like scanf() are easy to use unsafely, but can be made safe in
a simple, though WOMBATty, way, by constructing the format string at run
time, using something like (warning: not tested!)

sprintf(format_string, "%%%ds", current_size_of_buffer);
scanf(format_string, destination_string);

I would add strtok(), which is hopelessly broken. The POSIX strtok_r() is
the correct way to write a simple token parser.

 

[Jiri Slaby]

Richard Heathfield napsal(a):

Jiri Slaby said:



There's a lot more to coding style than layout.

And anyway, you're using the wrong settings!

Nice, but this is Linux kernel default, see linux/scripts/Lindent .

 

[Keith Thompson]

Andrew Poelstra napsal(a): [...]

Actually, this is one of the most well-styled programs I've seen posted
here (by a novice) in a while. I recommend you use 2 or 4-space tabs
instead of 8.

Nope, indentation is done by 8-columns wide tabs, period.
Nope.

[...]

Fixed case 2 for you. (I use 2-space tabs, but 3 or 4 is fine.)

Blaah. Mixing of variable length indent is Evil(TM).
Read linux/Documentation/CodingStyle...

I might consider reading that, and I'd certainly follow it if I were
working on the Linux kernel. But there are a number of different
layout styles and there's no objective reason to think that indenting
with 8-column tabs is better than any other style.

BTW, if you want people to read linux/Documentation/CodingStyle, you
should provide an actual link.

(Personally, I use 4-space indentation and avoid hard tab characters
altogether, but I'm not going to claim that I'm right and everyone
else is wrong.)

 

[Nelu]

Andrew Poelstra napsal(a): [...]
<snip>

BTW, if you want people to read linux/Documentation/CodingStyle, you
should provide an actual link.

8 spaces tabs feel awkward to me. I find it hard to read code indented
that way because I'm not used to it.

Here's a snippet from the document Jiri talks about:

Chapter 1: Indentation

Tabs are 8 characters, and thus indentations are also 8 characters.
There are heretic movements that try to make indentations 4 (or even
2!)
characters deep, and that is akin to trying to define the value of PI
to
be 3.

Rationale: The whole idea behind indentation is to clearly define where
a block of control starts and ends. Especially when you've been
looking
at your screen for 20 straight hours, you'll find it a lot easier to
see
how the indentation works if you have large indentations.

Now, some people will claim that having 8-character indentations makes
the code move too far to the right, and makes it hard to read on a
80-character terminal screen. The answer to that is that if you need
more than 3 levels of indentation, you're screwed anyway, and should
fix
your program.

In short, 8-char indents make things easier to read, and have the
added
benefit of warning you when you're nesting your functions too deep.
Heed that warning.

Don't put multiple statements on a single line unless you have
something to hide:

if (condition) do_this;
do_something_everytime;

Outside of comments, documentation and except in Kconfig, spaces are
never
used for indentation, and the above example is deliberately broken.

Get a decent editor and don't leave whitespace at the end of lines.

 

[Andrew Poelstra]

Andrew Poelstra napsal(a):

Nope, indentation is done by 8-columns wide tabs, period.

Have you seen some of the programs posted here? Most have /no/ indentation.

You haven't read the thread, have you?

According to my newserver, I was the first person to actually comment
on the entire code. I've no idea what you mean.

again...

Please give me a link to the last post where this was mentioned.

semicolon?

Oops! My mistake.

Ugly as hell.
switch (whatever) {
case 1:
whatever
break;
}
is one of correct indentation.

1) Tabs are never correct indentation.
2) Aside from that, there is no "correct" indentation. 2, 3, or 4-space
is fine. 8 is rarely readable for real code.

and again...

Again what? I detect a AOL "Me too" posting style.

Blaah. Mixing of variable length indent is Evil(TM).
Read linux/Documentation/CodingStyle...

"Mixing of variable length indent"? Please tell me what that means
and where I did it.

Moreover it's not parsed...

It's an output statement. You don't "parse" output. Unless you meant
spellchecked or proofread...

 

[Richard Heathfield]

Keith Thompson said:

(Personally, I use 4-space indentation and avoid hard tab characters
altogether, but I'm not going to claim that I'm right and everyone
else is wrong.)

Good, because such a claim would be (very slightly) inaccurate. ;-)

 

[Andrew Poelstra]

Andrew Poelstra said:



That's the most efficient while loop I've seen in some time. Not content
with having the smallest possible loop body, it carefully avoids ever
executing it!

Thanks!

More prosaically: if the LHS of the && is true, the RHS cannot be true, so
the condition will always fail.

You are correct. The use of "gets" and the malloc wrapper caused me to
go through and correct style and UB issues while ignoring logical ones;
there were quite a few such issues I deliberately ignored (the post was
already 400 lines), and I wouldn't doubt that I missed many more.

I have to wonder how the posted code actually ran.

 

[Richard Heathfield]

Andrew Poelstra said:

On 2006-07-07, Jiri Slaby <[email protected]> wrote:
According to my newserver, I was the first person to actually comment
on the entire code.

According to mine, my compiler was the first to comment on the entire code.
Beat you by 6 hours 19 minutes.

 

[Skarmander]

jaysome said:

On Fri, 07 Jul 2006 09:10:14 +0000, Richard Heathfield

<snip>
What other Standard C functions would be good candidates for the
"-function" option?

Just gets(). But I'd flag a few others as being "experts-only"
functions, which you should not use in "real" code unless you know
/exactly/ what you're doing:

From <stdlib.h>

[...] calloc, malloc, realloc, free, [...]

Let's get this straight: you shouldn't dynamically allocate memory in
C unless you're an expert?

It is extremely easy to get wrong.

Well, actually, no arguments there -- but why not just say C is for
experts and leave it at that, then? For most applications, you need to
be an expert to write a program *without* dynamic memory allocation!

Well, in significant parts of the embedded world you are explicitly
banned from using allocated memory, and I wrote a *lot* of code without
any difficulty with that restriction even when I was new to programming.

Oh, let's get *that* straight too: obviously it's actually very *easy* to
write code if you can't use more than, say, 42 memory units exactly -- or
tell people such code can't be written.

For many applications that's simply not good enough, though. You'll want a
program that can scale to core without having to recompile it.

If you want a program that has to utilize those 42 units of memory to the
best of its ability, it's not unthinkable that you'll end up implementing
(pseudo-)dynamic memory allocation yourself.

For example, the first significant program I ever wrote (which I wrote
in BASIC) was "The Game of Life".
http://www.google.com/search?sourceid=navclient-ff&ie=UTF-8&rlz=1B2GGGL_enGB177&q="the+game+of+life"

If you have a static board size there is absolutely no need for dynamic
memory allocation. IIRC it was interesting to implement.

The key point being "if you have a static board size". And for Life, that's
indeed not a significant restriction.

There are plenty of other significant projects one can implement without
dynamic memory allocation.

This I do not dispute.

Sometimes by having a reasonable static size and reporting if the user
tries to go beyond it, sometimes without any need at all for dynamic
memory allocation.

But the latter class is a minority, and the former a distinct nuisance. I
cannot recount the number of times a program (quite likely written in C)
used a "reasonable" static size and refused my input. The programmer
responsible would probably shug their shoulders, increase the #define'd
constants a bit and recompile. Problem solved! For now.

S.

 

[Keith Thompson]

Keith Thompson said:



Good, because such a claim would be (very slightly) inaccurate. ;-)

Good point. A more accurate claim would be that I'm right and
everyone who disagrees with me is wrong. }

 

[jacob navia]

The solution to many of this problems of memory allocation is to
allocate dynamically all the memory you need, never call free()
and link with the GARBAGE COLLECTOR.

Boehm's garbage collector is delivered as standard in lcc-win32,
but you can find it for most compilers or environments.


jacob

 

[jacob navia]

None, really. gets() is the only one that can _not_ be used safely.

That is not the opinion of the C standards comitee.

We had an animated discussion in comp.std.c about why gets() is
still in the standard, and a certain Mr Gwyn, apparently from the
comitee or very associated with them defended gets() with all
kind of weird arguments.

None of the comitee members cared to contradict him or express another
opinion.

Look for the thread

"Why does rewind() ignore errors"?

initiated by K. Thompson

 

[Richard Heathfield]

Skarmander said:

For many applications that's simply not good enough, though. You'll want a
program that can scale to core without having to recompile it.

That is an excellent reason to learn how to do dynamic memory allocation
correctly. It is a very poor reason for using dynamic memory allocation
without having first learned how to do it correctly.

Dynamic memory allocation is indeed a vital technique. Let's do it right.

<snip>

 

[Dann Corbit]

That is not the opinion of the C standards comitee.

We had an animated discussion in comp.std.c about why gets() is
still in the standard, and a certain Mr Gwyn, apparently from the
comitee or very associated with them defended gets() with all
kind of weird arguments.

None of the comitee members cared to contradict him or express another
opinion.

Look for the thread

"Why does rewind() ignore errors"?

initiated by K. Thompson

Right, all you have to do to use it safely is to reopen standard input as a
file, do some seeks and voilla! The gets() function can be used safely.

It's sort of like saying: "You CAN roast marshmallows safely with hydrogen
bombs -- you just have to stand the right distance away."

 

[Skarmander]

Skarmander said:


That is an excellent reason to learn how to do dynamic memory allocation
correctly. It is a very poor reason for using dynamic memory allocation
without having first learned how to do it correctly.

Dynamic memory allocation is indeed a vital technique. Let's do it right.

And? And? "Hey, let's be careful out there."

S.

 

[Richard Heathfield]

Keith Thompson said:

Good point. A more accurate claim would be that I'm right and
everyone who disagrees with me is wrong. }

Close, but no banana.

 

[Richard Heathfield]

jacob navia said:

Richard Bos wrote:


That is not the opinion of the C standards comitee.

It is certainly possible to envisage a situation where a C programmer could
use gets() without the system being compromised - for example, he writes
the program, he compiles it, runs it himself on a single-user system, types
the input himself, and then deletes the program immediately when he has the
results he requires. This paragraph should not be taken as an endorsement
of gets(), which I maintain cannot be used safely, despite my previous
sentence. The programmer might decide against deleting the program "in case
it comes in handy again". He might be distracted by other matters, and
forget to delete the program. And so on.

We had an animated discussion in comp.std.c about why gets() is
still in the standard, and a certain Mr Gwyn, apparently from the
comitee or very associated with them defended gets() with all
kind of weird arguments.

The ISO C Committee writes the Standard, and the Standard defines the
language. But the Standard has no authority to /require/ programmers to use
gets(). If the Committee are daft enough to leave gets() in the Standard,
that's their problem. We don't have to be daft enough to use it.

A standard C library that omitted gets() would, in my opinion, still be
conforming to all intents and purposes, since a strictly conforming program
dare not trust gets(), and therefore dare not use it, in case the user
invokes undefined behaviour. The omission could be viewed as a sort of
extension.

None of the comitee members cared to contradict him or express another
opinion.

Presumably you mean none of the committee members who happened to read that
thread.

 

[Skarmander]

The solution to many of this problems of memory allocation is to
allocate dynamically all the memory you need, never call free()
and link with the GARBAGE COLLECTOR.

Please. We're having a pleasant academic argument, and do not wish to be
disturbed by all sorts of realistic solutions.

Sure, while you're adding a garbage collector, link in a safe string library
too, and you've probably covered most C mishaps. (I'd think out-of-bounds
errors and failure to check error returns account for the remainder.) The
context of the discussion was a "vanilla" C implementation, though, with
standard functions considered dangerous. The standard doesn't prohibit a
garbage collecting implementation, but doesn't guarantee it either.

S.

 

[Mark McIntyre]

Nope, indentation is done by 8-columns wide tabs, period.

Apparently you haven't worked with many large programmes...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan