Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #12789 > unrolled thread

variadic function

Back to article view | Back to comp.lang.c

Contents

  variadic function Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-05 22:32 +0000
    Re: variadic function Keith Thompson <kst-u@mib.org> - 2011-11-05 15:50 -0700
      Re: variadic function Quentin Pope <qp19433@hotmail.NOSPAM.com> - 2011-11-07 17:41 +0000
    Re: variadic function James Kuyper <jameskuyper@verizon.net> - 2011-11-05 18:53 -0400
      Re: variadic function Keith Thompson <kst-u@mib.org> - 2011-11-05 16:35 -0700
        Re: variadic function Kaz Kylheku <kaz@kylheku.com> - 2011-11-06 01:36 +0000
    Re: variadic function Kaz Kylheku <kaz@kylheku.com> - 2011-11-06 01:31 +0000
    Re: variadic function Barry Schwarz <schwarzb@dqel.com> - 2011-11-06 09:45 -0800
      Re: variadic function Keith Thompson <kst-u@mib.org> - 2011-11-06 11:38 -0800
        Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 23:24 -0800
          Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-01-25 02:54 -0800
            Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 18:22 -0800
              Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-01-31 21:50 -0800
                Re: variadic function James Kuyper <jameskuyper@verizon.net> - 2012-02-01 07:55 -0500
                Re: variadic function Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-01 08:06 -0500
                  Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-02-01 11:42 -0800
                Re: variadic function Willem <willem@toad.stack.nl> - 2012-02-01 16:15 +0000
                  Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-02-01 11:41 -0800
                Re: variadic function Shao Miller <sha0.miller@gmail.com> - 2012-02-01 13:41 -0500
                  Re: variadic function blp@cs.stanford.edu (Ben Pfaff) - 2012-02-01 10:45 -0800
                Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 10:30 -0800
                  Re: variadic function Keith Thompson <kst-u@mib.org> - 2012-03-08 13:57 -0800
                    Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 13:10 -0800
                      Re: variadic function jgk@panix.com (Joe keane) - 2012-03-11 07:56 +0000
                        Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-11 13:01 -0700
                          Re: variadic function jgk@panix.com (Joe keane) - 2012-03-12 19:04 +0000
                            Re: variadic function Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-13 15:05 -0700

Page 2 of 2 — ← Prev page 1 [2]

#18336

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>> Keith Thompson <kst-u@mib.org> writes:
>>>>> [snip]
>>>>>
>>>>> If the standard did have the requirement you mention: "Do not call
>>>>> va_end after va_start unless va_arg has been called to process
>>>>> every argument in the calling sequence", what great inconvenience
>>>>> would it cause?
>>>>
>>>> The problem is it requires us to know things that we may
>>>> not know, namely, the number and types of arguments remaining.
>>>> Even if a motivating example isn't immediately obvious, that's
>>>> a chilling prospect.
>>>
>>> The quoted discussion was a while ago, but I think what I had in mind is
>>> that calling va_end "too soon" would have undefined behavior.  For
>>> example (assuming printf uses the <stdarg.h> mechanism), this:
>>>
>>>     printf("%s\n", "arg1", "ignored");
>>>
>>> has well defined behavior; with the hypothetical rule, its behavior
>>> would be undefined.
>>
>> That's an issue right there.  We are taking a statement that
>> has defined behavior now and changing the language so it has
>> undefined behavior.  Don't you see a problem with that?
>
> I would certainly see a problem with that if that were what I suggested.
> I'm not talking about changing the language; I'm speculating about what
> problems, if any, would have resulted if the language had been defined
> that way from the beginning.
>
> When C was standardized in 1989, it *could have* been defined so that
> excess arguments cause undefined behavior.  If it had, I don't believe
> it would have caused any great inconvenience.  (Changing it now *would*
> cause great inconvenience.)

I believe behavior with printf(), etc, predates the first
C standard by at least a decade.  At that time (ie, the
late 1970's or earlier) there was no notion of undefined
behavior - implementations just did what they did.  So
what you're suggesting doesn't really make sense, historically.

> If you thought such a hypothetical is not worth discussion, I would
> have no argument.  But you obviously do think it's worth discussion.

I respond for two reasons:  first to clarify what suggestion
(or suggestions) are being made, second to give comments
about the hypothetical as a way of saying something about
potential similar proposals made non-hypthetically.  Not
sure how well I've succeeded with those, but oh well.


>>> [snip]

There's been enough discussion in the intervening
followups so that I'll just leave it here.

[toc] | [prev] | [next] | [standalone]

#18358

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> When C was standardized in 1989, it *could have* been defined so that
>> excess arguments cause undefined behavior.  If it had, I don't believe
>> it would have caused any great inconvenience.  (Changing it now *would*
>> cause great inconvenience.)
>
> I believe behavior with printf(), etc, predates the first
> C standard by at least a decade.  At that time (ie, the
> late 1970's or earlier) there was no notion of undefined
> behavior - implementations just did what they did.  So
> what you're suggesting doesn't really make sense, historically.

The first C standard introduced the rule that calling printf() without a
proper declaration in scope has undefined behavior.  Prior to that, this
program:

    extern printf();
    main() { printf("Hello, world\n"); }

would have been well behaved (i.e., would print "Hello, world" under
most or all implementations).

The standard imposed a *lot* of restrictions that rendered the behavior
of some existing code undefined -- including, if I'm not mistaken, the
first "hello, world" program in K&R1 (I don't remember whether it had
"#include <stdio.h>" or not).

Adding a rule that calling printf() with excess arguments has undefined
behavior would have been consistent with that.

I'm not saying it would necessarily have been a good idea to impose such
a rule, but it wouldn't have been completely insane.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#18403

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
> [...]
>>> When C was standardized in 1989, it *could have* been defined so that
>>> excess arguments cause undefined behavior.  If it had, I don't believe
>>> it would have caused any great inconvenience.  (Changing it now *would*
>>> cause great inconvenience.)
>>
>> I believe behavior with printf(), etc, predates the first
>> C standard by at least a decade.  At that time (ie, the
>> late 1970's or earlier) there was no notion of undefined
>> behavior - implementations just did what they did.  So
>> what you're suggesting doesn't really make sense, historically.
>
> The first C standard introduced the rule that calling printf() without a
> proper declaration in scope has undefined behavior.  Prior to that, this
> program:
>
>     extern printf();
>     main() { printf("Hello, world\n"); }
>
> would have been well behaved (i.e., would print "Hello, world" under
> most or all implementations).

True, but not nearly as relevant since all such problems could
be fixed by adding one line at the beginning of each source
file, without having to do any code inspection.

> The standard imposed a *lot* of restrictions that rendered the behavior
> of some existing code undefined -- including, if I'm not mistaken, the
> first "hello, world" program in K&R1 (I don't remember whether it had
> "#include <stdio.h>" or not).

Before C was standardized all C programs had undefined behavior
in every statement.  The Standard defines the behavior of some
of those statements.  Indeed it is defining behavior that imposes
a restriction - leaving something as undefined behavior imposes
no restrictions at all.

> Adding a rule that calling printf() with excess arguments has undefined
> behavior would have been consistent with that.

I disagree.  I'm surprised you don't see a difference.

> I'm not saying it would necessarily have been a good idea to impose such
> a rule, but it wouldn't have been completely insane.

Maybe not completely insane, but still insane.

[toc] | [prev] | [next] | [standalone]

#18519

In article <kfneht1qy40.fsf@x-alumni2.alumni.caltech.edu>,
Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>Before C was standardized all C programs had undefined behavior in
>every statement.

It's BSD 4.1 on a VAX.

I defined it.

If another platform gives different results then it's a compiler bug or
ill-formed code.

[toc] | [prev] | [next] | [standalone]

#18546

jgk@panix.com (Joe keane) writes:

> In article <kfneht1qy40.fsf@x-alumni2.alumni.caltech.edu>,
> Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>>Before C was standardized all C programs had undefined behavior in
>>every statement.
>
> It's BSD 4.1 on a VAX.
>
> I defined it.
>
> If another platform gives different results then it's a compiler bug or
> ill-formed code.

Presumably you're just making a joke.  There is however an
underlying point that's worth making.

In running an actual program there is no such thing as "undefined
behavior".  Every program execution does _something_, and it's
always possible to say that what the program does serves to
define the behavior.

The point, though, is that the term 'undefined behavior' means
behavior that is not defined by the ISO C Standard.  Before there
was an ISO C Standard, no program behavior was defined, so all
parts of all C programs were undefined behavior.

(Note: I know that 'undefined behavior' meant something different
during the time that ANSI had ratified a C standard but before
ISO did.  That doesn't change the point.)

[toc] | [prev] | [next] | [standalone]

#18602

In article <kfnd38ioqj0.fsf@x-alumni2.alumni.caltech.edu>,
Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>Before there was an ISO C Standard, no program behavior was defined, so
>all parts of all C programs were undefined behavior.

That i disagree with.

ANSI mainly codified current behavior.  Therefore there was some current
behavior.

K&R predates ANSI by a bit.  C compilers and libraries had been around
for a decade.  There would be some common knowledge of what is valid C.

For example, "a++ = 1;" was nonsense even then.

Programmers were aware that there's a function called 'strcpy', and what
it does, and if some guys reversed the arguments, that is -broken-.

etc etc

[toc] | [prev] | [next] | [standalone]

#18710

jgk@panix.com (Joe keane) writes:

> In article <kfnd38ioqj0.fsf@x-alumni2.alumni.caltech.edu>,
> Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>>Before there was an ISO C Standard, no program behavior was defined, so
>>all parts of all C programs were undefined behavior.
>
> That i disagree with.
>
> ANSI mainly codified current behavior.  Therefore there was some current
> behavior.
>
> K&R predates ANSI by a bit.  C compilers and libraries had been around
> for a decade.  There would be some common knowledge of what is valid C.
>
> For example, "a++ = 1;" was nonsense even then.
>
> Programmers were aware that there's a function called 'strcpy', and what
> it does, and if some guys reversed the arguments, that is -broken-.

I agree with your facts, but the point was about the labels, not
the facts.  The term 'undefined behavior' has a very specific
meaning in the context of both the group and the discussion in
question.  There was current behavior, and there was general
agreement as to what most of that behavior would be, but there
was no 'defined behavior' in the sense of not being 'undefined
behavior' -- before there was a Standard, all behavior was
'undefined' as far as there being an ISO standard definition.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web