Re: I don't get how the computer arrives at 2^31

"Tim Rentsch" <txr@xxxxxxxxxxxxxxxxxxx> wrote in message
news:kfn4q4s4h2r.fsf@xxxxxxxxxxxxxxxxxxxxxx
> "Wojtek Lerch" <Wojtek_L@xxxxxxxx> writes:
>> "Tim Rentsch" <txr@xxxxxxxxxxxxxxxxxxx> wrote in message
>> news:kfn4q56tbrt.fsf@xxxxxxxxxxxxxxxxxxxxxx
....
> If the authors were mathematicians, your interpretation that "the"
> implies only one type would probably be right. The writing in the
> Standard isn't always as careful with the language it uses.

No argument there.

> It's certainly true that what constitutes a "correct type" doesn't
> have any explicit definition. The behavior is well-defined only if
> the type of an argument is of "correct type"; since "correct type"
> doesn't any explicit definition, it's logical to conclude that the
> behavior isn't defined either.

An explicit definition of the term "correct type" is missing, but a term is
not a behaviour. According to 3p1, "Terms not defined in this International
Standard are to be interpreted according to ISO/IEC 2382-1." I doubt
ISO/IEC 2382-1 clarifies this particular case, but that doesn't mean that
the words about undefined behaviour apply instead.

....
> Granted. It's reasonable, though, to infer that vfprintf() uses
> va_arg() to collect argument values.

It's reasonable to infer that it's *allowed* to use va_arg(), but given that
it doesn't even have to be implemented in C, there's no reason to infer that
it is *required* to use va_arg(). All we're promised is that it must use
something that will make its functionality "equivalent" to fprintf().

What is reasonable to infer is that the requirements that apply to the
variadic arguments to fprintf() apply to the variadic arguments to the
function that created the va_list value passed to vfprintf(). But I don't
see why it's reasonable to think that an analogy with va_arg() implied by
the reference to va_start() in the description of vfprintf() affects the
meaning of the words that directly describe fprintf(). I can easily believe
that that was the intent, but not that that intent is sufficiently reflected
by the words.

>> Imagine an extended C standard that has two new interfaces in <stdarg.h>:
>> a
>> va_istype() macro that takes a va_list and a type name and returns a
>> Boolean
>> that tells you whether that type is compatible with the type of the next
>> variable argument (and distinguishes between signed and unsigned), and a
>> va_exactarg() macro that is identical to va_arg() except it has undefined
>> behaviour if you mix signed with unsigned or char* with void*. Do you
>> think
>> that after adding those two macros, it would still be reasonable to
>> assume
>> that vfprintf() and fprintf() use va_arg(), rather than va_exactarg(), to
>> fetch their arguments? Since the implementation of standard library
>> functions are free to use extensions, is it reasonable to interpret the
>> standard's description of vfprintf() and fprintf() differently depending
>> on
>> whether my va_istype() and va_exactarg() are portable interfaces defined
>> by
>> the standard or merely possible extensions?
>
> The answer to the second question is Yes: having va_istype() and
> va_exactarg() be Standard-defined carries (potentially) different
> implications than if they are extensions. The reason is that, unless
> there is an explicit statement to the contrary, implementation-defined
> behavior cannot eliminate Standard-required behavior.

Sorry, I didn't quite get this part; what's the standard-required behaviour
and how would it be "eliminated" by an implementation-defined behaviour in
my example?

Anyway, what do you think about my other modified version of C -- the one
with <stdarg.h> removed, along with all the "v" variants of printf and
scanf? Would you still consider it unclear what the description of
fprintf() refers to by "the correct type"? Would you still consider it more
reasonable to interpret "the correct type" as "the type mentioned in the
description of the format specifier, or the corresponding signed or unsigned
type provided the value fits in both" than simply as "the type mentioned in
the description of the format specifier"?

....
>> > The idea that the vfprintf()/fprintf() equivalence imposes additional
>> > requirements on va_arg() is pretty much the tail wagging the dog.
>>
>> Additional requirements on va_arg()? I think one of us must have
>> misunderstood something.
>
> I'll just second that last statement and move on...

:-)

>> ...
>> > I don't think it's necessary to guess. The description of vfprintf()
>> > provides the link between fprintf() and va_arg(). [...]
>>
>> But that's my point: since the va_list argument to vfprintf() *replaces*
>> the
>> argument list of fprintf(), whatever requirements the link between
>> vfprintf() and va_arg() places on the va_list does not automatically
>> extend
>> to fprintf(). Besides, even the link between vfprintf() and va_arg() is
>> not
>> real. The standard never says that vfprintf() uses va_arg(), rather than
>> an
>> extension like my va_exactarg(), to extract values from the va_list.
>
> I read it differently. Since vfprintf() is required to be equivalent
> to (an analogous call to) fprintf(), it seems reasonable to conclude
> that the conditions that hold for one most hold for the other.

About as reasonable as concluding that all the requirements that apply to
fprintf() must necessarily apply to sprintf(), including the one that the
first argument must point to a stream opened for writing.

The requirements on the arguments to fprintf() are explicitly stated in the
description of fprintf(); the requirements on the va_list argument to
vfprintf() are vaguely implied by saying that vfprintf() is "equivalent" to
fprintf() and by mentioning va_start(). Is it really reasonable to conclude
that an explicit requirement in the former is overriden by the implied
analogy to va_arg() in the latter?

> I agree that vfprintf() using va_arg() is only implied, not stated.

Right: you say "reasonable to conclude", I say "necessary to guess".
Potato,
potahto... ;-)

> I still think it's the best explanation, given the available facts.


.

Relevant Pages

  • Re: I dont get how the computer arrives at 2^31
    ... Standard isn't always as careful with the language it uses. ... > vfprintf() does with its argument. ... > standard's description of vfprintf() and fprintfdifferently depending on ... I agree that putting both format specifications and a statement that ...
    (comp.std.c)
  • Re: I dont get how the computer arrives at 2^31
    ... The description of each format specifier names ... I believe the standard says clearly enough that the type explicitly named ... >>> 2 The vfprintf function is equivalent to fprintf, ... >>> Considering the statement of equivalence between vfprintf and fprintf, ...
    (comp.std.c)
  • Re: kids and their furniture?
    ... I would always honor and respect any house rules I was ... standards that differed significantly from the range of behaviors ... I think it's pretty close to the legal 'reasonable person' standard. ... too much work to reason one's way through every single ...
    (misc.kids)
  • Re: How do you imagine future Common Lisp standard ?
    ... Scheme doesn't focus on good macro ... Goodness and Badness must be evaluated in a particular design-space ... It's fortunate that this can be done without change to the standard, ... There's no reason to define the old language away, ...
    (comp.lang.lisp)
  • Re: Understanding # and function variables
    ... That's the reason for my statement that I don't care whether a ... >>change is standard compliant or not. ... >>substantial revision of ANSI Common Lisp and would provide equally ... I will find out about an already existing language that is strictly ...
    (comp.lang.lisp)
Loading