va_args Conformance

Discussion in 'C Programming' started by Shao Miller, Jan 31, 2012.

  1. Shao Miller

    Shao Miller Guest

    If the following program strictly conforming?

    #include <stddef.h>
    #include <stdarg.h>

    static void test(int, ...);

    int main(void) {
    test(0, 42);

    return 0;
    }

    static void test(int x, ...) {
    typedef unsigned char one_char[1];
    /* Valid declaration on the next line */
    one_char * unused;
    va_list varargs;
    unsigned char * byte;

    va_start(varargs, x);
    if (x)
    byte = va_arg(varargs, one_char);
    va_end(varargs);

    return;
    }

    --
    "The stationery store has moved. Aaargh!"
    Shao Miller, Jan 31, 2012
    #1
    1. Advertising

  2. Shao Miller <> writes:

    > If the following program strictly conforming?
    >
    > #include <stddef.h>
    > #include <stdarg.h>
    >
    > static void test(int, ...);
    >
    > int main(void) {
    > test(0, 42);
    >
    > return 0;
    > }
    >
    > static void test(int x, ...) {
    > typedef unsigned char one_char[1];
    > /* Valid declaration on the next line */
    > one_char * unused;
    > va_list varargs;
    > unsigned char * byte;
    >
    > va_start(varargs, x);
    > if (x)
    > byte = va_arg(varargs, one_char);
    > va_end(varargs);
    >
    > return;
    > }


    It looks fine to me. Does some implementation reject it?

    --
    Ben.
    Ben Bacarisse, Jan 31, 2012
    #2
    1. Advertising

  3. Shao Miller

    Shao Miller Guest

    On 1/31/2012 09:50, Ben Bacarisse wrote:
    > Shao Miller<> writes:
    >
    >> If the following program strictly conforming?
    >>
    >> #include<stddef.h>
    >> #include<stdarg.h>
    >>
    >> static void test(int, ...);
    >>
    >> int main(void) {
    >> test(0, 42);
    >>
    >> return 0;
    >> }
    >>
    >> static void test(int x, ...) {
    >> typedef unsigned char one_char[1];
    >> /* Valid declaration on the next line */
    >> one_char * unused;
    >> va_list varargs;
    >> unsigned char * byte;
    >>
    >> va_start(varargs, x);
    >> if (x)
    >> byte = va_arg(varargs, one_char);
    >> va_end(varargs);
    >>
    >> return;
    >> }

    >
    > It looks fine to me. Does some implementation reject it?
    >


    Yes. At least two of them, and in different ways that I didn't quite
    expect.

    GCC 4.3.3 says:

    test.c: In function 'test':
    test.c:21: error: invalid use of non-lvalue array

    Where 'va_arg' expands to '__builtin_va_arg'.

    clang 2.9 says:

    test.c:21:16: error: assigning to 'unsigned char *' from incompatible
    type 'one_char' (aka 'unsigned char [1]')
    byte = va_arg(varargs, one_char);
    ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
    1 error generated.

    Where once again, 'va_arg' expands to '__builtin_va_arg'.

    My reading of N1256's 7.15.1.1 has me pondering these.

    --
    "The stationery store has moved. Aaargh!"
    Shao Miller, Jan 31, 2012
    #3
  4. Shao Miller

    James Kuyper Guest

    On 01/31/2012 09:50 AM, Ben Bacarisse wrote:
    > Shao Miller <> writes:
    >
    >> If the following program strictly conforming?
    >>
    >> #include <stddef.h>
    >> #include <stdarg.h>
    >>
    >> static void test(int, ...);
    >>
    >> int main(void) {
    >> test(0, 42);
    >>
    >> return 0;
    >> }
    >>
    >> static void test(int x, ...) {
    >> typedef unsigned char one_char[1];
    >> /* Valid declaration on the next line */
    >> one_char * unused;
    >> va_list varargs;
    >> unsigned char * byte;
    >>
    >> va_start(varargs, x);
    >> if (x)
    >> byte = va_arg(varargs, one_char);
    >> va_end(varargs);
    >>
    >> return;
    >> }

    >
    > It looks fine to me. Does some implementation reject it?


    The second argument of his call to test() has a type of int. He calls
    va_arg() with a type of one_char, which is a typedef for unsigned char.
    "if type is not compatible with the type of the actual next argument (as
    promoted according to the default argument promotions), the behavior is
    undefined ..." (7.15.1.1p2). The promoted type of "int" is "int".
    "unsigned char" is not compatible with "int". That clause has some
    exceptions, but none of them are applicable.
    James Kuyper, Jan 31, 2012
    #4
  5. James Kuyper <> writes:

    > On 01/31/2012 09:50 AM, Ben Bacarisse wrote:
    >> Shao Miller <> writes:
    >>
    >>> If the following program strictly conforming?
    >>>
    >>> #include <stddef.h>
    >>> #include <stdarg.h>
    >>>
    >>> static void test(int, ...);
    >>>
    >>> int main(void) {
    >>> test(0, 42);
    >>>
    >>> return 0;
    >>> }
    >>>
    >>> static void test(int x, ...) {
    >>> typedef unsigned char one_char[1];
    >>> /* Valid declaration on the next line */
    >>> one_char * unused;
    >>> va_list varargs;
    >>> unsigned char * byte;
    >>>
    >>> va_start(varargs, x);
    >>> if (x)
    >>> byte = va_arg(varargs, one_char);
    >>> va_end(varargs);
    >>>
    >>> return;
    >>> }

    >>
    >> It looks fine to me. Does some implementation reject it?

    >
    > The second argument of his call to test() has a type of int. He calls
    > va_arg() with a type of one_char, which is a typedef for unsigned
    > char.


    I though his code did not do this. Was that not the point of the
    if (x) with x == 0?

    > "if type is not compatible with the type of the actual next argument (as
    > promoted according to the default argument promotions), the behavior is
    > undefined ..." (7.15.1.1p2). The promoted type of "int" is "int".
    > "unsigned char" is not compatible with "int". That clause has some
    > exceptions, but none of them are applicable.


    --
    Ben.
    Ben Bacarisse, Jan 31, 2012
    #5
  6. Shao Miller

    Shao Miller Guest

    On 1/31/2012 11:53, Ben Bacarisse wrote:
    > James Kuyper<> writes:
    >
    >> On 01/31/2012 09:50 AM, Ben Bacarisse wrote:
    >>> Shao Miller<> writes:
    >>>
    >>>> If the following program strictly conforming?
    >>>>
    >>>> #include<stddef.h>
    >>>> #include<stdarg.h>
    >>>>
    >>>> static void test(int, ...);
    >>>>
    >>>> int main(void) {
    >>>> test(0, 42);
    >>>>
    >>>> return 0;
    >>>> }
    >>>>
    >>>> static void test(int x, ...) {
    >>>> typedef unsigned char one_char[1];
    >>>> /* Valid declaration on the next line */
    >>>> one_char * unused;
    >>>> va_list varargs;
    >>>> unsigned char * byte;
    >>>>
    >>>> va_start(varargs, x);
    >>>> if (x)
    >>>> byte = va_arg(varargs, one_char);
    >>>> va_end(varargs);
    >>>>
    >>>> return;
    >>>> }
    >>>
    >>> It looks fine to me. Does some implementation reject it?

    >>
    >> The second argument of his call to test() has a type of int. He calls
    >> va_arg() with a type of one_char, which is a typedef for unsigned
    >> char.

    >
    > I though his code did not do this. Was that not the point of the
    > if (x) with x == 0?
    >


    Yes, that was the point, to keep the test-case fairly simple. I gather
    that 'printf' [theoretically] uses the passed format string to determine
    what kind of 'va_arg' to do each other additional parameter in a loosely
    similar fashion, for example.

    >> "if type is not compatible with the type of the actual next argument (as
    >> promoted according to the default argument promotions), the behavior is
    >> undefined ..." (7.15.1.1p2). The promoted type of "int" is "int".
    >> "unsigned char" is not compatible with "int". That clause has some
    >> exceptions, but none of them are applicable.

    >


    --
    "The stationery store has moved. Aaargh!"
    Shao Miller, Jan 31, 2012
    #6
  7. Shao Miller

    James Kuyper Guest

    On 01/31/2012 11:53 AM, Ben Bacarisse wrote:
    > James Kuyper <> writes:
    >
    >> On 01/31/2012 09:50 AM, Ben Bacarisse wrote:
    >>> Shao Miller <> writes:
    >>>
    >>>> If the following program strictly conforming?
    >>>>
    >>>> #include <stddef.h>
    >>>> #include <stdarg.h>
    >>>>
    >>>> static void test(int, ...);
    >>>>
    >>>> int main(void) {
    >>>> test(0, 42);
    >>>>
    >>>> return 0;
    >>>> }
    >>>>
    >>>> static void test(int x, ...) {
    >>>> typedef unsigned char one_char[1];
    >>>> /* Valid declaration on the next line */
    >>>> one_char * unused;
    >>>> va_list varargs;
    >>>> unsigned char * byte;
    >>>>
    >>>> va_start(varargs, x);
    >>>> if (x)
    >>>> byte = va_arg(varargs, one_char);
    >>>> va_end(varargs);
    >>>>
    >>>> return;
    >>>> }
    >>>
    >>> It looks fine to me. Does some implementation reject it?

    >>
    >> The second argument of his call to test() has a type of int. He calls
    >> va_arg() with a type of one_char, which is a typedef for unsigned
    >> char.

    >
    > I though his code did not do this. Was that not the point of the
    > if (x) with x == 0?


    You're right - I didn't pay attention to that. Sorry!
    James Kuyper, Jan 31, 2012
    #7
  8. Shao Miller <> writes:

    > On 1/31/2012 09:50, Ben Bacarisse wrote:
    >> Shao Miller<> writes:
    >>
    >>> If the following program strictly conforming?
    >>>
    >>> #include<stddef.h>
    >>> #include<stdarg.h>
    >>>
    >>> static void test(int, ...);
    >>>
    >>> int main(void) {
    >>> test(0, 42);
    >>>
    >>> return 0;
    >>> }
    >>>
    >>> static void test(int x, ...) {
    >>> typedef unsigned char one_char[1];
    >>> /* Valid declaration on the next line */
    >>> one_char * unused;
    >>> va_list varargs;
    >>> unsigned char * byte;
    >>>
    >>> va_start(varargs, x);
    >>> if (x)
    >>> byte = va_arg(varargs, one_char);
    >>> va_end(varargs);
    >>>
    >>> return;
    >>> }

    >>
    >> It looks fine to me. Does some implementation reject it?
    >>

    >
    > Yes. At least two of them, and in different ways that I didn't quite
    > expect.
    >
    > GCC 4.3.3 says:
    >
    > test.c: In function 'test':
    > test.c:21: error: invalid use of non-lvalue array
    >
    > Where 'va_arg' expands to '__builtin_va_arg'.


    gcc 4.6.1 is happy with it...

    > clang 2.9 says:
    >
    > test.c:21:16: error: assigning to 'unsigned char *' from
    > incompatible type 'one_char' (aka 'unsigned char [1]')
    > byte = va_arg(varargs, one_char);
    > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
    > 1 error generated.


    .... and my clang version 2.9 (tags/RELEASE_29/final) is also happy with
    it.

    > Where once again, 'va_arg' expands to '__builtin_va_arg'.
    >
    > My reading of N1256's 7.15.1.1 has me pondering these.


    It seems OK to me. va_arg(varargs, one_char) must be an expression of
    type one_char. An expression with type "array of T" gets converted to
    one of type "pointer to T" so the assignment should type-check. (You
    can't execute the line without UB, but presumably that's why you put
    the if (x) check there.)

    I was briefly concerned that maybe the array-to-pointer conversion might
    only apply to lvalue expressions, but it does not -- it applies to any
    expression with an array type (other than a string literal or one that
    is the operand of sizeof or unary &).

    --
    Ben.
    Ben Bacarisse, Jan 31, 2012
    #8
  9. Shao Miller

    Shao Miller Guest

    On 1/31/2012 12:19, Ben Bacarisse wrote:
    > Shao Miller<> writes:
    >
    >> On 1/31/2012 09:50, Ben Bacarisse wrote:
    >>> Shao Miller<> writes:
    >>>
    >>>> If the following program strictly conforming?
    >>>>
    >>>> #include<stddef.h>
    >>>> #include<stdarg.h>
    >>>>
    >>>> static void test(int, ...);
    >>>>
    >>>> int main(void) {
    >>>> test(0, 42);
    >>>>
    >>>> return 0;
    >>>> }
    >>>>
    >>>> static void test(int x, ...) {
    >>>> typedef unsigned char one_char[1];
    >>>> /* Valid declaration on the next line */
    >>>> one_char * unused;
    >>>> va_list varargs;
    >>>> unsigned char * byte;
    >>>>
    >>>> va_start(varargs, x);
    >>>> if (x)
    >>>> byte = va_arg(varargs, one_char);
    >>>> va_end(varargs);
    >>>>
    >>>> return;
    >>>> }
    >>>
    >>> It looks fine to me. Does some implementation reject it?
    >>>

    >>
    >> Yes. At least two of them, and in different ways that I didn't quite
    >> expect.
    >>
    >> GCC 4.3.3 says:
    >>
    >> test.c: In function 'test':
    >> test.c:21: error: invalid use of non-lvalue array
    >>
    >> Where 'va_arg' expands to '__builtin_va_arg'.

    >
    > gcc 4.6.1 is happy with it...
    >


    Aha. Thanks a lot for checking that!

    >> clang 2.9 says:
    >>
    >> test.c:21:16: error: assigning to 'unsigned char *' from
    >> incompatible type 'one_char' (aka 'unsigned char [1]')
    >> byte = va_arg(varargs, one_char);
    >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
    >> 1 error generated.

    >
    > ... and my clang version 2.9 (tags/RELEASE_29/final) is also happy with
    > it.
    >


    That's odd. I was also using "tags/RELEASE_29/final". I was using
    '-ansi -pedantic' as well, so maybe there's a C90 vs. C99 difference in
    treatment?

    >> Where once again, 'va_arg' expands to '__builtin_va_arg'.
    >>
    >> My reading of N1256's 7.15.1.1 has me pondering these.

    >
    > It seems OK to me. va_arg(varargs, one_char) must be an expression of
    > type one_char. An expression with type "array of T" gets converted to
    > one of type "pointer to T" so the assignment should type-check. (You
    > can't execute the line without UB, but presumably that's why you put
    > the if (x) check there.)
    >


    I had the same reasoning, so thank you very much for that. Yes, I
    believe the undefined behaviour would be from the 'va_arg' result not
    being addressable, so the address of the first element would be
    undefined and hence the would-be-resulting pointer value.

    Beyond all of that business, I don't know of a way to pass an array to
    any function, so the 'one_char' type could never be compatible with any
    parameter. But that wasn't the point of the original question, of course.

    > I was briefly concerned that maybe the array-to-pointer conversion might
    > only apply to lvalue expressions, but it does not -- it applies to any
    > expression with an array type (other than a string literal or one that
    > is the operand of sizeof or unary&).
    >


    I had some moments where I shared this same concern and drew the same
    conclusion. This seems to be related to something like:

    typedef unsigned char one_char[1];
    register one_char foo;

    where there are now restrictions on the use of 'foo'; 'sizeof' and
    '_AlignOf' only, presumably.

    --
    "The stationery store has moved. Aaargh!"
    Shao Miller, Jan 31, 2012
    #9
  10. Shao Miller

    Shao Miller Guest

    On 1/31/2012 12:31, Shao Miller wrote:
    >
    > I had some moments where I shared this same concern and drew the same
    > conclusion. This seems to be related to something like:
    >
    > typedef unsigned char one_char[1];
    > register one_char foo;
    >
    > where there are now restrictions on the use of 'foo'; 'sizeof' and
    > '_AlignOf' only, presumably.
    >


    Uh. I meant 'alignof'. Oops.

    --
    "The stationery store has moved. Aaargh!"
    Shao Miller, Jan 31, 2012
    #10
  11. Shao Miller

    Shao Miller Guest

    On 1/31/2012 12:34, Shao Miller wrote:
    > On 1/31/2012 12:31, Shao Miller wrote:
    >>
    >> I had some moments where I shared this same concern and drew the same
    >> conclusion. This seems to be related to something like:
    >>
    >> typedef unsigned char one_char[1];
    >> register one_char foo;
    >>
    >> where there are now restrictions on the use of 'foo'; 'sizeof' and
    >> '_AlignOf' only, presumably.
    >>

    >
    > Uh. I meant 'alignof'. Oops.
    >


    And I'm wrong, anyway. [Albeit outdated] N1494 doesn't have 'alignof'
    applying to identifiers. I forgot about the gripe I had about that in
    comp.std.c some time ago.

    --
    "The stationery store has moved. Aaargh!"
    Shao Miller, Jan 31, 2012
    #11
  12. On Jan 31, 3:12 pm, Shao Miller <> wrote:
    > If the following program strictly conforming?
    >
    >    #include <stddef.h>
    >    #include <stdarg.h>
    >
    >    static void test(int, ...);
    >
    >    int main(void) {
    >        test(0, 42);
    >
    >        return 0;
    >      }
    >
    >    static void test(int x, ...) {
    >        typedef unsigned char one_char[1];
    >        /* Valid declaration on the next line */
    >        one_char * unused;
    >        va_list varargs;
    >        unsigned char * byte;
    >
    >        va_start(varargs, x);
    >        if (x)
    >            byte = va_arg(varargs, one_char);


    In C90, this is invalid. As your compilers' error messages state, the
    standard does not require va_arg's result to be an lvalue, and a non-
    lvalue array cannot be used in any way except to discard it, to take
    its size, or to uselessly pass it to another variadic function. In
    particular, it cannot be converted to a pointer, and its members
    cannot be accessed.

    In C99 (and presumably C11), this use of va_arg unconditionally
    invokes undefined behaviour: there is no longer any way to pass an
    array to a variadic function without it getting converted to a pointer
    to its first element. A line that unconditionally invokes undefined
    behaviour at runtime is technically allowed in a strictly conforming
    program if the line is never executed, but this would not be the first
    example where compilers divert from the standard in that regard.

    >        va_end(varargs);
    >
    >        return;
    >      }
    Harald van Dijk, Jan 31, 2012
    #12
  13. Shao Miller <> writes:

    > On 1/31/2012 12:19, Ben Bacarisse wrote:
    >> Shao Miller<> writes:

    <snip>
    >>> clang 2.9 says:
    >>>
    >>> test.c:21:16: error: assigning to 'unsigned char *' from
    >>> incompatible type 'one_char' (aka 'unsigned char [1]')
    >>> byte = va_arg(varargs, one_char);
    >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~
    >>> 1 error generated.

    >>
    >> ... and my clang version 2.9 (tags/RELEASE_29/final) is also happy with
    >> it.

    >
    > That's odd. I was also using "tags/RELEASE_29/final". I was using
    > -ansi -pedantic' as well, so maybe there's a C90 vs. C99 difference in
    > treatment?


    So it would seem. Error with -std=C90, fine with -C99. The C90 wording
    is:

    "The va_arg macro expands to an expression that has the type and value
    of the next argument in the call."

    which I find very strange!

    <snip>
    --
    Ben.
    Ben Bacarisse, Jan 31, 2012
    #13
  14. Shao Miller

    Shao Miller Guest

    On 1/31/2012 12:46, Harald van Dijk wrote:
    > On Jan 31, 3:12 pm, Shao Miller<> wrote:
    >> If the following program strictly conforming?
    >>
    >> #include<stddef.h>
    >> #include<stdarg.h>
    >>
    >> static void test(int, ...);
    >>
    >> int main(void) {
    >> test(0, 42);
    >>
    >> return 0;
    >> }
    >>
    >> static void test(int x, ...) {
    >> typedef unsigned char one_char[1];
    >> /* Valid declaration on the next line */
    >> one_char * unused;
    >> va_list varargs;
    >> unsigned char * byte;
    >>
    >> va_start(varargs, x);
    >> if (x)
    >> byte = va_arg(varargs, one_char);

    >
    > In C90, this is invalid. As your compilers' error messages state, the
    > standard does not require va_arg's result to be an lvalue, and a non-
    > lvalue array cannot be used in any way except to discard it, to take
    > its size, or to uselessly pass it to another variadic function. In
    > particular, it cannot be converted to a pointer, and its members
    > cannot be accessed.
    >


    Aha! Thanks very much. Indeed, the result is a "value" rather than
    designating an "object."

    That such a value can be passed to another function is interesting,
    though... I suppose it could be passed to a non-variadic function whose
    parameters aren't specified, too.

    > In C99 (and presumably C11), this use of va_arg unconditionally
    > invokes undefined behaviour: there is no longer any way to pass an
    > array to a variadic function without it getting converted to a pointer
    > to its first element.


    Out of curiosity, how could you pass an array pre-C99? Or do you mean
    for the strict case where the expression is an array "value" without
    being an lvalue, that you described above?

    The program doesn't attempt to pass an array to the 'test' function, by
    the way. So I think by "this use," you were referring to a construct
    which didn't appear in the program, but which might be associated with
    it. Or did you really mean a construct in the program?

    > A line that unconditionally invokes undefined
    > behaviour at runtime is technically allowed in a strictly conforming
    > program if the line is never executed, but this would not be the first
    > example where compilers divert from the standard in that regard.
    >


    I see. Well thanks again!

    --
    "The stationery store has moved. Aaargh!"
    Shao Miller, Jan 31, 2012
    #14
  15. On Jan 31, 7:45 pm, Shao Miller <> wrote:
    > On 1/31/2012 12:46, Harald van Dijk wrote:
    > > In C99 (and presumably C11), this use of va_arg unconditionally
    > > invokes undefined behaviour: there is no longer any way to pass an
    > > array to a variadic function without it getting converted to a pointer
    > > to its first element.

    >
    > Out of curiosity, how could you pass an array pre-C99?  Or do you mean
    > for the strict case where the expression is an array "value" without
    > being an lvalue, that you described above?


    Right, this is a program that I believe to strictly conform to the C90
    standard:

    #include <stdarg.h>
    typedef char array[10];
    struct S { array array; };
    struct S foo(void) { static struct S s; return s; }
    int bar(int x, ...)
    {
    int result;
    va_list ap;
    va_start(ap, x);
    va_arg(ap, array);
    result = va_arg(ap, int);
    va_end(ap);
    return result;
    }
    int main(void)
    {
    return bar(0, foo().array, 0);
    }

    It's useless, but it's valid, and C90's va_arg is (strictly speaking:
    for practical purposes nobody really cares) required to skip over the
    array to correctly read the next passed argument.

    > The program doesn't attempt to pass an array to the 'test' function, by
    > the way.  So I think by "this use," you were referring to a construct
    > which didn't appear in the program, but which might be associated with
    > it.  Or did you really mean a construct in the program?


    I meant the use of va_arg: if its second argument has array type, it
    cannot possibly be compatible with the type of the passed argument in
    C99, no matter how you call the function. If you pass an array, even
    an array rvalue, it gets converted to a pointer, so va_arg's second
    argument should be a pointer type.
    Harald van Dijk, Jan 31, 2012
    #15
  16. On Jan 31, 7:45 pm, Shao Miller <> wrote:
    > On 1/31/2012 12:46, Harald van Dijk wrote:
    > > In C90, this is invalid. As your compilers' error messages state, the
    > > standard does not require va_arg's result to be an lvalue, and a non-
    > > lvalue array cannot be used in any way except to discard it, to take
    > > its size, or to uselessly pass it to another variadic function. In
    > > particular, it cannot be converted to a pointer, and its members
    > > cannot be accessed.

    >
    > Aha!  Thanks very much.  Indeed, the result is a "value" rather than
    > designating an "object."
    >
    > That such a value can be passed to another function is interesting,
    > though...


    But be careful: the standard doesn't require va_arg's result to be an
    lvalue, but does allow it. If it is an lvalue, then it will get
    converted to a pointer if you pass it on to another function!

    > I suppose it could be passed to a non-variadic function whose
    > parameters aren't specified, too.


    Perhaps, but a non-variadic function cannot have a definition allowing
    arguments of array type (parameters of array type are converted to
    pointers too), so again, the behaviour would again always be
    undefined, no matter how the function is defined.
    Harald van Dijk, Jan 31, 2012
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. T.J.

    Triple-A conformance?

    T.J., Dec 14, 2003, in forum: HTML
    Replies:
    20
    Views:
    775
    brucie
    Dec 16, 2003
  2. EN
    Replies:
    45
    Views:
    1,133
    Mark Parnell
    May 5, 2006
  3. Amarendra GODBOLE
    Replies:
    25
    Views:
    686
    Dan Pop
    Jan 21, 2004
  4. Michael B Allen

    va_args going unused ok?

    Michael B Allen, Mar 30, 2005, in forum: C Programming
    Replies:
    1
    Views:
    384
    Krishanu Debnath
    Mar 30, 2005
  5. c library conformance testing

    , Dec 1, 2005, in forum: C Programming
    Replies:
    0
    Views:
    364
Loading...

Share This Page