Clive,
Please see comments below.
Thanks,
Don
>From yyyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx Fri Feb 14 08:05:46 2003
>Resent-Date: 14 Feb 2003 16:03:45 -0000
>From: "Clive D.W. Feather" <yyyyy@xxxxxxxxx>
>To: yyyyyyy@xxxxxxx
>Cc: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Subject: Re: Defect in XSH makecontext
>Content-Disposition: inline
>User-Agent: Mutt/1.5.3i
>Resent-Message-ID: <yyyyyyyyyyyyyyyyyy@xxxxxxx>
>Resent-To: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Resent-From: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>X-Mailing-List: austin-review-l:archive/latest/1390
>X-Loop: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>Resent-Sender: yyyyyyyyyyyyyyyyyyyyyyy@xxxxxxxxxxxxx
>
>yyyyyyy@xxxxxxx said:
>> The 1st paragraph of the description of makecontext() (XSH6, P729,
>> L23937-23940) says that the arguments following argc in the
>> makecontext() call are passed to func(). But, the "void (*func)(void)"
>> in the function prototype on XSH6, P729, L23931-23932 does not allow any
>> arguments to be passed to func(). Therefore, the standard conflicts with
>> itself except in the case when argc is zero.
>
>Correct.
>
>> In practice, func() is called by various applications with an arbitrary
>> number of arguments (including zero) of varying types. Specifying func()
>> as "void (*func)(int, ...)" would break all existing applications that
>> currently use makecontext(), but it is the only way in ISO/IEC 9899:1999
>> (C99) to specify that func() takes one or more arguments of varying
>> types. Furthermore, this would require that func() take at least one
>> argument (invalidating the example shown on XSH6, P729-730, L23957-23991).
>
>This has not changed since C90.
You're correct. We were blissfully unaware we were violating our rules
before.
>
>> C99 (subclause 6.11.6) specifies that the use of function declarators
>> with empty parentheses is an obsolescent feature.
>
>This has not changed since C90 (except the reference is to 6.9.4).
>
>> Therefore, using the
>> function prototype (as in XSH5, P493):
>>
>> void makecontext(ucontext_t *ucp, void (*func)(), int argc,...);
>>
>> is making use of an obsolescent feature of C99.
>
>This has not changed since C90.
>
>> Therefore, a strictly
>> conforming POSIX application can't use this form and is why it changed
>> in XSH6.
>
>Is that so? In the C Standards, "obsolescent" means simply "we may change
>this in the next version; be warned".
In the POSIX standards, a strictly conforming POSIX application shall
not use facilities designated as obsolescent (XBD, P29, L1182). The
same applies to strictly conforming XSI applications (XBD, P30,
L1226).
>
>> There is no way in C99 to specify a non-obsolescent function prototype
>> indicating that a function will be called with an arbitrary number
>> (including zero) of arguments of arbitrary types (including integers,
>> pointers to data, pointers to functions, and composite types).
>
>There is no way to specify this in C90 or C99, whether using old-style or
>new-style function prototypes.
>
>Both versions of the language require that either:
>* the number of parameters in the definition equals the number of
> arguments in the actual call, or
>* the declaration uses an ellipsis and the number of arguments in the
> actual call is not less than the number of named parameters in the
> definition.
>
>> By going
>> back to the XSH5 specification for makecontext(), existing applications
>> will continue to work, although they won't be able to be classified as
>> strictly conforming applications.
>
>Any application making use of this feature is relying on undefined
>behaviour. At least, I can see no way to write makecontext in C to make
>this work.
Don't forget that there is no requirement that an implementation of
POSIX functions be a conforming POSIX (or C) application. We know that
implementations of makecontext() will be hardware architecture
specific.
>
>> We (standards developers) are stuck between a rock and a hard place
>> because there is no way in C99 (without using obsolescent behavior) to
>> specify functionality that was standard, strictly conforming behavior in
>> XSH5 using the 1990 C Standard.
>
>False - this has not changed since C90.
>
>> Action:
>
>I can see no way that makecontext could be written in portable C. Therefore
>it already relies on implementation-specific features. Suggestion:
>
>change the makecontext() function prototype in XSH6 page 729 on lines
>23931-23932 from:
> void makecontext(ucontext_t *ucp, void (*func)(void), int argc, ...);
> to:
> void makecontext(ucontext_t *ucp, makecontext_cb_t func, int argc,
>...);
Isn't this still using the same obsolescent feature as in?:
void makecontext(ucontext_t *ucp, void (*func)(), int argc, ...);
>
>where makecontext_cb_t is a pointer to a function-returning-void type, with
>nothing specified about the parameters. Alternatively, change it to:
> void makecontext(ucontext_t *ucp, void (*func)(va_list), int argc,
>...);
Doing this would mean that all existing uses of makecontext would have
to be rewritten such that func() takes at least one argument and uses
the va_* macros from <stdarg.h>.
>
>> Add rationale to makecontext() in XSH6 page 730 line 23995 saying:
>>
>> "With the incorporation of ISO/IEC 9899:1999 (C99) into this
>> specification it was found that C99 (subclause 6.11.6) specifies that
>> the use of function declarators with empty parentheses is an obsolescent
>> feature.
>[...]
>
>This has the same issues as described above.
>
>--
>Clive D.W. Feather | Work: <yyyyy@xxxxxxxxx> | Tel: +44 20 8371 1138
>Internet Expert | Home: <yyyyy@xxxxxxxxxx> | Fax: +44 870 051 9937
>Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646
>Thus plc | |
|