beginner with programming, how to learn to debug and few C generalquestions

[Nate Eldredge]

Officially (Dartmouth again) it was called a subroutine, surprisingly
enough.

Oh, of course. *slaps head*

 

[bpascal123]

Hi Tor,

I'm not fully convinced because you don't tell the reason why choosing
C, C++, Perl to learn programing is a bad choice.

I have tried php and vba (for the last, i'm able to copy-paste excel
macros found in google and rearrange them to achieve something).

For php (i was learning basic simple algorithms at that time for a
year long (3 hours/a week) algos with very few maths (not my cup of
tea) but enough to understand a checkers application.

After a few php scripts and my first sips of { ' " $ I decided that
algo weren't enough and when i'd time i'd learn how to program with
true, bullet-proof computer language. And with C (unlike with vba) I
feel it is close to those algos I have learnt alone and for some
reasons, it wasn't a easy time...

So, please Tor, be more explicit about why C, C++, Perl are bad to
start with.
Don't forget I have studied (simple level) algos on my own.

Cheers,

Pascal

 

[bpascal123]

Hi Bart, Tor,

I'm not fully convinced because you don't tell the reason why
choosing
C, C++, Perl to learn programing is a bad choice.

I have tried php and vba (for the last, i'm able to copy-paste excel
macros found in google and rearrange them to achieve something).

For php (i was learning basic simple algorithms at that time for a
year long (3 hours/a week) algos with very few maths (not my cup of
tea) but enough to understand a checkers application.

After a few php scripts and my first sips of { ' " $ I decided that
algo weren't enough and when i'd time i'd learn how to program with
true, bullet-proof computer language. And with C (unlike with vba) I
feel it is close to those algos I have learnt alone and for some
reasons, it wasn't a easy time...

So, please Tor, be more explicit about why C, C++, Perl are bad to
start with.

Don't forget I have studied (simple level) algos on my own.

Cheers,

Pascal

 

[Richard Bos]

C is like driving a Formula One race car, you are better off getting
your driver licence in a Volvo.

I disagree. I got my license in a VW Golf, and drive a Volvo now. I
prefer my Volvo, but the Golf was definitely more forgiving on beginning
drivers. Also, Formula One cars aren't for advanced drivers, but for a
very, very few.
Pascal is a VW Golf; C is a Porsche; INTERCAL is a Formula One car.

Richard

 

[bpascal123]

Hi,

Ok guys, opinions diversify. I will keep on learning the basics of C
and afterwards if i see i'm facing a wall, i'll go on with a more
accessible language. I don't want to specialize for the next 2-3 years
(given i can have ennough time to keep on learning...).

If i'd ever specialize, i hope to go more intensevly (maybe take 6
months off and attend a class) with whatever language i'm on. It could
be C++, VBA, Python, Java, Php, Ruby... Java is very popular for
university certificates and more.

Anyhow, I think a basic understanding of C will help.

Thanks

Between a WV Golf, Volvo, Porshe (i don't have a car, I live in Paris
and i ride the tube/subway so i can read a C book)

Pascal

 

[Tim Rentsch]

Prolog (it has relations) and more generally rule-based languages.
(Rules are not functions.) Early BASICs. Assembler. Does COBOL have
functions?


Well, maybe. (I don't classify it as a /proper/ programming language
unless it as /first-class/ functions.)

In C, technically functions aren't first-class, but pointers to
functions are first-class. Some people might consider C functions
somewhat impoverished compared to functions in other languages, but
they are first-class (with the understanding that we're letting
pointers-to-functions stand in for functions).

 

[Tim Rentsch]

Yes, but...


...no. atoi() isn't as bad as gets() only because, making more effort
than you should need to, you _can_ stop atoi() from having undefined
behaviour using ISO C only. You cannot do that with gets(). However, if
you don't make that effort, and pass atoi() a string it cannot handle,
it will still have behaviour that is equally as undefined as gets().

What I think you mean is that the behavior /specification/ of atoi()
in such cases is equally undefined as the behavior specification of
gets() under analogous circumstances. It's likely that the /actual/
behavior of atoi() is much more well-defined than the behavior of
gets() in such cases.

 

[Keith Thompson]

What I think you mean is that the behavior /specification/ of atoi()
in such cases is equally undefined as the behavior specification of
gets() under analogous circumstances. It's likely that the /actual/
behavior of atoi() is much more well-defined than the behavior of
gets() in such cases.

I don't think that's what he meant. As far as the standard is
concerned, undefined behavior is undefined behavior. It's true that
atoi("99999999999999999999999999") is less likely to crash your
program or corrupt memory than gets(buf) while your cat is sitting on
the keyboard, but that's no excuse for being careless.

The point, I think, is that it's possible to use atoi() safely by
refraining from calling it with certain arguments. It's not possible
to use gets() safely, because its input is whatever appears on stdin,
and you typically have no control over that. The only defense (unless
you somehow have absolute control over what appears on stdin) is to
avoid calling gets() at all.

On the other hand, the effort required to use atoi() safely probably
exceeds the effort required to use strtol().

 

[Tim Rentsch]

I don't think that's what he meant. As far as the standard is
concerned, undefined behavior is undefined behavior. It's true that
atoi("99999999999999999999999999") is less likely to crash your
program or corrupt memory than gets(buf) while your cat is sitting on
the keyboard, but that's no excuse for being careless.

There's an ambiguity because the word "behavior" has a meaning
in two different contexts, the context of the Standard, and the
context of everyday life.

In the Standard, "behavior" is a description of what a program
/may/ do (ie, is allowed to do by the Standard).

In ordinary conversation, "behavior" is what a program
/actually does/.

The original comment was made (I believe) about "behavior" in the
first sense.

That statement could also be read taking "behavior" in the second
sense. In fact I think that mistake would be easy to make by
people who aren't used to the CLC argot. My comment was meant to
point out the ambiguity and clarify the distinction. Hopefully
I'll be more successful with that in this second posting than I
was in the first.

The point, I think, is that it's possible to use atoi() safely by
refraining from calling it with certain arguments. It's not possible
to use gets() safely, because its input is whatever appears on stdin,
and you typically have no control over that. The only defense (unless
you somehow have absolute control over what appears on stdin) is to
avoid calling gets() at all.

Perhaps, but practically speaking I wouldn't worry too much about
calling atoi() on malformed input, whereas I would never want to
call gets(). And I don't think that distinction is irrelevant,
even in comp.lang.c.

On the other hand, the effort required to use atoi() safely probably
exceeds the effort required to use strtol().

Technically speaking, or practically speaking? Technically
speaking, I agree with you. Practically speaking, in most cases
it's probably not worth worrying about; even if atoi() is used
wrongly, more often than not the cost of failure times the
probability of failure is still negligible.

 

[Curtis Dyer]

There's an ambiguity because the word "behavior" has a meaning
in two different contexts, the context of the Standard, and the
context of everyday life.

In the Standard, "behavior" is a description of what a program
/may/ do (ie, is allowed to do by the Standard).

In Section 3.4, the C99 Standard defines the word "behavior" as
"external appearance or action". From what I can tell, your
description here better describes /well-defined/ behavior, rather
than just "behavior", even as defined by the Standard.

It seems to me, in both senses of the word, "behavior" describes
what a program is able to do, not what it is permitted to do.

I apologize if I'm midunderstanding you or the Standard.

<snip>

--
Curtis

int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hell\
o, world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
~ Anonymous (1984 IOCCC winner)

 

[Tim Rentsch]

In Section 3.4, the C99 Standard defines the word "behavior" as
"external appearance or action". From what I can tell, your
description here better describes /well-defined/ behavior, rather
than just "behavior", even as defined by the Standard.

It seems to me, in both senses of the word, "behavior" describes
what a program is able to do, not what it is permitted to do.

Consider a statement like "if XYZ, the behavior is undefined."
This doesn't mean that what the program does is undefined; it
means what the program is allowed to do by the Standard is
undefined.

Now consider a statement like, "if I give my program an input
file of /dev/null, its bevahior is a little screwy." This
doesn't mean the program is allowed to be a little screwy, it
means what it actually does is a little screwy.

Another example: {unsigned u = 0; u = u+1; return u;} This
program fragment has "well-defined" behavior. But if we run the
program, and the memory for u gets hit by a cosmic ray, what the
program actually does may be different from what the Standard
requires it to do. Its behavior(1) is defined by the Standard,
but its behavior(2) is affected by cosmic rays (which are not
part of the Standard). The terms behavior(1) and behavior(2)
clearly can't mean the same thing.

Do you see the difference I'm trying to illuminate?

I apologize if I'm midunderstanding you or the Standard.

No problem. These ideas are difficult to communicate.

 

[Keith Thompson]

In Section 3.4, the C99 Standard defines the word "behavior" as
"external appearance or action". From what I can tell, your
description here better describes /well-defined/ behavior, rather
than just "behavior", even as defined by the Standard.

It seems to me, in both senses of the word, "behavior" describes
what a program is able to do, not what it is permitted to do.

I apologize if I'm midunderstanding you or the Standard.

"Behavior" is what a program actually does.

 

[Keith Thompson]

Perhaps, but practically speaking I wouldn't worry too much about
calling atoi() on malformed input, whereas I would never want to
call gets(). And I don't think that distinction is irrelevant,
even in comp.lang.c.

[...]

I agree that it's relevant, but I disagree with your conclusion.

I might use atoi() in a throwaway program that nobody else will ever
use, and that I won't use more than once or twice. (I might even use
gets() in the same circumstances.) For anything more serious than
that, I'd go to the extra effort to use strtol(). I would no more
assume that atoi("9999999999999999999") is harmless than I would
assume that INT_MAX + 1 is harmless. In both cases, a signed integer
overflow will probably give some arbitrary result, but on some
implementations it could crash the program.

Or I might use atoi() if the program logic guarantees that the
argument won't overflow, but even then I"d consider it to be too
fragile.

Programs inevitably have bugs, and programmers inevitably spend time
tracking down those bugs. There is considerable value in having one
less thing to worry about when the program's behavior goes awry.

 

[Keith Thompson]

I disagree. "Behavior" is what the program actually does.

And if a program doesn't behave in the way required by the standard,
the standard's statement about its behavior isn't incorrect, it's
merely inapplicable; just about everything the standard says applies
only to conforming implementations.

[snip]

 

[Curtis Dyer]

I disagree. "Behavior" is what the program actually does.

And if a program doesn't behave in the way required by the
standard, the standard's statement about its behavior isn't
incorrect, it's merely inapplicable; just about everything the
standard says applies only to conforming implementations.

[snip]

Thank you both (Tim and Keith). I'm not sure how I managed to get
confused over this.

--
Curtis

int i;main(){for(;i["]<i;++i){--i;}"];read('-'-'-',i+++"hell\
o, world!\n",'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
~ Anonymous (1984 IOCCC winner)

 

[Tim Rentsch]

Perhaps, but practically speaking I wouldn't worry too much about
calling atoi() on malformed input, whereas I would never want to
call gets(). And I don't think that distinction is irrelevant,
even in comp.lang.c.

[...]

I agree that it's relevant, but I disagree with your conclusion.

I might use atoi() in a throwaway program that nobody else will ever
use, and that I won't use more than once or twice. (I might even use
gets() in the same circumstances.) For anything more serious than
that, I'd go to the extra effort to use strtol(). [snip]

I don't think our positions are that far apart here. We both
think it's better to use strtol() than atoi(); where I think we
differ is we put different priorities on doing that relative to
other attention-demanding tasks. I don't mean to disagree, only
to note the difference in priorities.

 

[Tim Rentsch]

In the Standard, "behavior" is a description of what a
program /may/ do (ie, is allowed to do by the Standard).

I disagree. "Behavior" is what the program actually does.

And if a program doesn't behave in the way required by the
standard, the standard's statement about its behavior isn't
incorrect, it's merely inapplicable; just about everything the
standard says applies only to conforming implementations.

[snip]

Thank you both (Tim and Keith). I'm not sure how I managed to get
confused over this.

Happy to be of service. ;-)

 

[Tim Rentsch]

I disagree. "Behavior" is what the program actually does.

And if a program doesn't behave in the way required by the standard,
the standard's statement about its behavior isn't incorrect, it's
merely inapplicable; just about everything the standard says applies
only to conforming implementations.

Let me try saying this a different way. When the Standard talks
about behavior, it is talking about how a program behaves (or
will behave) on the abstract machine. When people in general
talk about the behavior of a program (or especially a particular
program execution), "behavior" typically refers to how the
program will behave (or does behave) on a physical machine.
Behavior on the abstract machine could be undefined as far as
the Standard is concerned, but at the same time the behavior on
the physical machine could be well-defined by the implementation
(and in fact is in many cases).

It's important to distinguish between these two usages, because
they are talking about two different things. Related things,
perhaps, but still different things. Making a statement about
behavior in the first sense isn't the same as making that
statement about behavior in the second sense. And vice versa.

 

[Flash Gordon]

Let me try saying this a different way. When the Standard talks
about behavior, it is talking about how a program behaves (or
will behave) on the abstract machine.

Not all the time. Also, the observable behaviour of the physical machine
has to be the same as the required observable behviour of the abstract
machine.

When people in general
talk about the behavior of a program (or especially a particular
program execution), "behavior" typically refers to how the
program will behave (or does behave) on a physical machine.

It depends. Sometimes people are talking about how the program is
required to behave, especially where the program will be run on multiple
different systems.

Behavior on the abstract machine could be undefined as far as
the Standard is concerned, but at the same time the behavior on
the physical machine could be well-defined by the implementation
(and in fact is in many cases).

Undefined behaviour in the C standard does not mean undefined on the
abstract machine, it means undefined by the C standard, which is not the
same thing.

It's important to distinguish between these two usages, because
they are talking about two different things. Related things,
perhaps, but still different things. Making a statement about
behavior in the first sense isn't the same as making that
statement about behavior in the second sense. And vice versa.

I dom't think the difference is what you think it is. For example, the
behaviour might be defined by the Posix standard, and that certainly is
not a physical machine!

 

[Keith Thompson]

Let me try saying this a different way. When the Standard talks
about behavior, it is talking about how a program behaves (or
will behave) on the abstract machine.

I don't think so; I think it's talking about the program's actual
behavior. The standard specifies a range of possible actual behaviors
that a program on a conforming implementation may exhibit. Even the
phrase "undefined behavior" implies that there *is* some behavior that
the standard doesn't define; this can only be the actual behavior on a
real system. Nasal demons are behavior.

When people in general
talk about the behavior of a program (or especially a particular
program execution), "behavior" typically refers to how the
program will behave (or does behave) on a physical machine.
Behavior on the abstract machine could be undefined as far as
the Standard is concerned, but at the same time the behavior on
the physical machine could be well-defined by the implementation
(and in fact is in many cases).

It's important to distinguish between these two usages, because
they are talking about two different things. Related things,
perhaps, but still different things. Making a statement about
behavior in the first sense isn't the same as making that
statement about behavior in the second sense. And vice versa.

And in my opinion, the standard uses the word "behavior" in the second
sense, not the first.