N
Nate Eldredge
Officially (Dartmouth again) it was called a subroutine, surprisingly
enough.
Oh, of course. *slaps head*
Officially (Dartmouth again) it was called a subroutine, surprisingly
enough.
Tor Rustad said:C is like driving a Formula One race car, you are better off getting
your driver licence in a Volvo.
Chris Dollin said: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.)
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().
Tim Rentsch said: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 said: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().
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).
Curtis Dyer said: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.
Curtis Dyer said: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.
[...]Tim Rentsch said: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 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]
Keith Thompson said:[...]Tim Rentsch said: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]
Curtis Dyer said:Tim Rentsch said: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.
Keith Thompson said: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.
Tim said: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.
Tim Rentsch said: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.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.