va_list

Discussion in 'C Programming' started by mito19651996@hotmail.com, May 17, 2006.

  1. Guest

    Hi,
    I am writing some code for the Nucleus OS and wanted to find out if
    there is a way to replace va_list and it's associated macros:
    va_list

    va_start

    va_arg

    va_end

    __va_copy

    I would like a standard way to implement these data types and macros
    without using any standard libraries.

    Thanks
    , May 17, 2006
    #1
    1. Advertising

  2. Ben Pfaff Guest

    writes:

    > I am writing some code for the Nucleus OS and wanted to find out if
    > there is a way to replace va_list and it's associated macros:
    > va_list
    >
    > va_start
    >
    > va_arg
    >
    > va_end
    >
    > __va_copy
    >
    > I would like a standard way to implement these data types and macros
    > without using any standard libraries.


    These are part of the standard library. Their goal is to
    abstract non-portable functionality. In other words, they exist
    *because* there is no portable way to implement them.
    --
    "For those who want to translate C to Pascal, it may be that a lobotomy
    serves your needs better." --M. Ambuhl

    "Here are the steps to create a C-to-Turbo-Pascal translator..." --H. Schildt
    Ben Pfaff, May 17, 2006
    #2
    1. Advertising

  3. writes:
    > I am writing some code for the Nucleus OS and wanted to find out if
    > there is a way to replace va_list and it's associated macros:
    > va_list
    >
    > va_start
    >
    > va_arg
    >
    > va_end
    >
    > __va_copy


    It's "va_copy", not "__va_copy".

    > I would like a standard way to implement these data types and macros
    > without using any standard libraries.


    No, there isn't. Part of the reason they're in the standard library
    is that they can't be portably implemented (the code that implements
    the standard library doesn't have to be portable).

    I'm guessing that Nucleus OS has a C implementation that doesn't
    include an implementation of <stdarg.h> (a quick Google search
    indicates that it's for embedded systems, so it's plausuble that it
    would have a freestanding implementation of C).

    The's probably a way to do what <stdarg.h> does -- or, to put it
    another way, it would probably be possible to implement <stdarg.h> for
    Nucleus OS. But without knowing anything about the OS, we can't guess
    how to do so (and details of the OS are almost certainly off-topic
    here).

    You might try a newsgroup that deals with realtime or embedded
    systems, or perhaps there's a Nucleus OS mailing list.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, May 17, 2006
    #3
  4. Eric Sosman Guest

    Keith Thompson wrote On 05/17/06 17:14,:
    > writes:
    >
    >>I am writing some code for the Nucleus OS and wanted to find out if
    >>there is a way to replace va_list and it's associated macros:
    >>[...]
    >>I would like a standard way to implement these data types and macros
    >>without using any standard libraries.

    >
    > [...]
    > I'm guessing that Nucleus OS has a C implementation that doesn't
    > include an implementation of <stdarg.h> (a quick Google search
    > indicates that it's for embedded systems, so it's plausuble that it
    > would have a freestanding implementation of C).
    > [...]


    A conforming C implementation, even if freestanding,
    must provide the <stdarg.h> facilities (also those of a
    few other Standard headers). It's possible that Nucleus
    has a deficient implementation, but "there's no printf()"
    doesn't necessarily imply "there's no <stdarg.h>." I
    encourage the O.P. to take another look.

    ... but if there's really nothing there, then there
    can't be "a standard way" to implement the missing bits.

    --
    Eric Sosman, May 17, 2006
    #4
  5. Malcolm Guest

    <> wrote
    > Hi,
    > I am writing some code for the Nucleus OS and wanted to find out if
    > there is a way to replace va_list and it's associated macros:
    > I would like a standard way to implement these data types and macros
    > without using any standard libraries.
    >

    You can't do this portably, but on most sytems you can do it in C.

    Arguments are usually passed on the stack. va_start() takes the address of
    the preceding argument. So simply increment the pointer, and read off the
    other arguments.

    Needless to say, this renders your program not strictly conforming.
    --
    www.personal.leeds.ac.uk/~bgy1mm
    Malcolm, May 17, 2006
    #5
  6. Eric Sosman <> writes:
    [...]
    > A conforming C implementation, even if freestanding,
    > must provide the <stdarg.h> facilities (also those of a
    > few other Standard headers). It's possible that Nucleus
    > has a deficient implementation, but "there's no printf()"
    > doesn't necessarily imply "there's no <stdarg.h>." I
    > encourage the O.P. to take another look.


    You're right. I looked at C99 4p6, but I somehow managed to miss the
    fact that <stdarg.h> is in the list of required headers for
    freestanding implementations (along with <float.h>, <iso646.h>,
    <limits.h>, <stdbool.h>, <stddef.h>, and <stdint.h>). Oops.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, May 18, 2006
    #6
  7. Ben Pfaff said:

    <snip>

    > [Vararg structs/routines] are part of the standard library. Their
    > goal is to abstract non-portable functionality. In other words,
    > they exist *because* there is no portable way to implement them.


    Then presumably we'll be seeing standard C library routines for networking,
    sound, graphics, filesystems, and all the rest of it, Real Soon Now? :)

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, May 18, 2006
    #7
  8. Richard Heathfield <> writes:
    > Ben Pfaff said:
    >
    > <snip>
    >
    >> [Vararg structs/routines] are part of the standard library. Their
    >> goal is to abstract non-portable functionality. In other words,
    >> they exist *because* there is no portable way to implement them.

    >
    > Then presumably we'll be seeing standard C library routines for networking,
    > sound, graphics, filesystems, and all the rest of it, Real Soon Now? :)


    While dropping everything in <string.h> (all of which *can* be
    implemented portably)?

    Seriously, the inability to implement something in standard C is only
    one of a number of reasons to put something into the standard library.
    Convenience is another. Historical accident is often a more important
    one.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, May 18, 2006
    #8
  9. pete Guest

    Keith Thompson wrote:
    >
    > Richard Heathfield <> writes:
    > > Ben Pfaff said:
    > >
    > > <snip>
    > >
    > >> [Vararg structs/routines] are part of the standard library. Their
    > >> goal is to abstract non-portable functionality. In other words,
    > >> they exist *because* there is no portable way to implement them.

    > >
    > > Then presumably we'll be seeing standard
    > > C library routines for networking,
    > > sound, graphics, filesystems,
    > > and all the rest of it, Real Soon Now? :)

    >
    > While dropping everything in <string.h> (all of which *can* be
    > implemented portably)?
    > Seriously, the inability to implement something in standard C is only
    > one of a number of reasons to put something into the standard library.
    > Convenience is another. Historical accident is often a more important
    > one.


    Speed is another.
    Nonportable, faster versions of the string functions
    is what I would hope for, from an implementation's library.

    You wouldn't want or expect your library's version
    of memmove to use the inequality operator
    to determine which kind of overlap you had, would you?

    void *memmove(void *s1, const void *s2, size_t n)
    {
    unsigned char *p1 = s1;
    const unsigned char *p2 = s2;

    p2 += n;
    while (p2 != s2 && --p2 != s1) {
    ;
    }
    if (p2 != s2) {
    p2 = s2;
    p2 += n;
    p1 += n;
    while (n-- != 0) {
    *--p1 = *--p2;
    }
    } else {
    while (n-- != 0) {
    *p1++ = *p2++;
    }
    }
    return s1;
    }

    --
    pete
    pete, May 18, 2006
    #9
  10. Jordan Abel Guest

    On 2006-05-18, Keith Thompson <> wrote:
    > Richard Heathfield <> writes:
    >> Ben Pfaff said:
    >>
    >> <snip>
    >>
    >>> [Vararg structs/routines] are part of the standard library. Their
    >>> goal is to abstract non-portable functionality. In other words,
    >>> they exist *because* there is no portable way to implement them.

    >>
    >> Then presumably we'll be seeing standard C library routines for networking,
    >> sound, graphics, filesystems, and all the rest of it, Real Soon Now? :)

    >
    > While dropping everything in <string.h> (all of which *can* be
    > implemented portably)?
    >
    > Seriously, the inability to implement something in standard C is only
    > one of a number of reasons to put something into the standard library.


    However, it is very much the only reason to put something, once it's
    already in the library, into the subset required for freestanding
    implementations.

    (yes, the full functionality of the stdio functions can be, in theory,
    implemented on a freestanding implementation. by keeping the filesystem
    structures in an array of stuff in a static block of memory).

    > Convenience is another. Historical accident is often a more important
    > one.
    Jordan Abel, May 18, 2006
    #10
  11. "Ben Pfaff" <> wrote in message
    news:...
    > writes:
    >


    Ha! I never noticed your sig...

    > "For those who want to translate C to Pascal, it may be that a lobotomy
    > serves your needs better." --M. Ambuhl
    >
    > "Here are the steps to create a C-to-Turbo-Pascal translator..." --H.

    Schildt

    I take it neither one has experience in PL/1. Pascal was heavily influenced
    by PL/1. In fact, I usually describe PL/1 to others as Pascal with C
    pointers and COBOL-ish records for structures...


    Rod Pemberton
    Rod Pemberton, May 18, 2006
    #11
  12. Jordan Abel <> writes:
    > On 2006-05-18, Keith Thompson <> wrote:
    >> Richard Heathfield <> writes:
    >>> Ben Pfaff said:
    >>>
    >>> <snip>
    >>>
    >>>> [Vararg structs/routines] are part of the standard library. Their
    >>>> goal is to abstract non-portable functionality. In other words,
    >>>> they exist *because* there is no portable way to implement them.
    >>>
    >>> Then presumably we'll be seeing standard C library routines for
    >>> networking, sound, graphics, filesystems, and all the rest of it,
    >>> Real Soon Now? :)

    >>
    >> While dropping everything in <string.h> (all of which *can* be
    >> implemented portably)?
    >>
    >> Seriously, the inability to implement something in standard C is only
    >> one of a number of reasons to put something into the standard library.

    >
    > However, it is very much the only reason to put something, once it's
    > already in the library, into the subset required for freestanding
    > implementations.

    [...]

    It seems to me that the headers required for freestanding
    implementations are the ones that don't require any library functions
    to be defined.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, May 18, 2006
    #12
  13. pete <> writes:
    > Keith Thompson wrote:
    >>
    >> Richard Heathfield <> writes:
    >> > Ben Pfaff said:
    >> >
    >> > <snip>
    >> >
    >> >> [Vararg structs/routines] are part of the standard library. Their
    >> >> goal is to abstract non-portable functionality. In other words,
    >> >> they exist *because* there is no portable way to implement them.
    >> >
    >> > Then presumably we'll be seeing standard
    >> > C library routines for networking,
    >> > sound, graphics, filesystems,
    >> > and all the rest of it, Real Soon Now? :)

    >>
    >> While dropping everything in <string.h> (all of which *can* be
    >> implemented portably)?

    [snip]
    > You wouldn't want or expect your library's version
    > of memmove to use the inequality operator
    > to determine which kind of overlap you had, would you?
    >
    > void *memmove(void *s1, const void *s2, size_t n)
    > {

    [snip]
    > }


    Yeah, I should have looked through that section of the standard before
    assuming that it could *all* be implemented portably.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, May 18, 2006
    #13
  14. pete Guest

    Keith Thompson wrote:
    >
    > pete <> writes:
    > > Keith Thompson wrote:
    > >>
    > >> Richard Heathfield <> writes:
    > >> > Ben Pfaff said:
    > >> >
    > >> > <snip>
    > >> >
    > >> >> [Vararg structs/routines]
    > >> >> are part of the standard library. Their
    > >> >> goal is to abstract non-portable functionality. In other words,
    > >> >> they exist *because* there is no portable way to implement them.
    > >> >
    > >> > Then presumably we'll be seeing standard
    > >> > C library routines for networking,
    > >> > sound, graphics, filesystems,
    > >> > and all the rest of it, Real Soon Now? :)
    > >>
    > >> While dropping everything in <string.h> (all of which *can* be
    > >> implemented portably)?

    > [snip]
    > > You wouldn't want or expect your library's version
    > > of memmove to use the inequality operator
    > > to determine which kind of overlap you had, would you?
    > >
    > > void *memmove(void *s1, const void *s2, size_t n)
    > > {

    > [snip]
    > > }

    >
    > Yeah, I should have looked through that section of the standard before
    > assuming that it could *all* be implemented portably.


    Most of the string library can be implemented portably.
    That version of memmove was portable.
    The point that I was trying to make with it,
    was that standard library functions
    don't have to be implemented portably
    and thus they can be faster than portable implementations.

    My intent was to say that "speed"
    is another reason why a function might be in the library.
    Library functions can be written in assembly
    and can use special opcodes that a compiler
    wouldn't ordinarily translate C code into,

    --
    pete
    pete, May 19, 2006
    #14
  15. On Thu, 18 May 2006 14:15:03 -0400, "Rod Pemberton"
    <> wrote:

    >
    > "Ben Pfaff" <> wrote in message
    > news:...
    > > writes:
    > >

    >
    > Ha! I never noticed your sig...
    >
    > > "For those who want to translate C to Pascal, it may be that a lobotomy
    > > serves your needs better." --M. Ambuhl
    > >
    > > "Here are the steps to create a C-to-Turbo-Pascal translator..." --H.

    > Schildt
    >
    > I take it neither one has experience in PL/1. Pascal was heavily influenced
    > by PL/1.


    Only negatively, I think. Both PL/I and Pascal are heavily derivative
    of algol, and influenced by typical (mainframe) environments of the
    day, but in the remaining (few) areas of freedom Pascal goes about as
    exactly opposite to PL/I as is possible.

    > In fact, I usually describe PL/1 to others as Pascal with C
    > pointers and COBOL-ish records for structures...
    >

    COBOLish records, yes. (IIRC even down to CORRESPONDING!)
    And COBOLish decimal numbers (even to PIC) plus FORTRAN/C-ish plus
    more binary/computational numbers and arrays. Even a bit of APL.
    And strings more than anything else of its day, especially BIT.

    C pointers, not really. (Original/then) PL/I (data) pointers are
    untyped, more like BCPL (or B) and offsets/areas are unlike any other
    HLL except a _little_ like C++ pointer-to-member. ENTRY and LABEL
    variables are more than C function pointer or even C++ function
    object. And CONDITION more than C++ exception, although in ways that
    are now unpopular and I think rightly so. And every I/O feature good
    or bad ever imagined by anybody up to its time. And tasking.

    The syntax even makes some attempts at brevity, though not as much as
    C, while Pascal goes toward verbosity though not as much as COBOL.

    - David.Thompson1 at worldnet.att.net
    Dave Thompson, May 29, 2006
    #15
    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. va_list in JNI

    , Jun 23, 2005, in forum: Java
    Replies:
    4
    Views:
    2,325
  2. Rich Herrick

    reference to va_list

    Rich Herrick, Jan 16, 2005, in forum: C++
    Replies:
    0
    Views:
    432
    Rich Herrick
    Jan 16, 2005
  3. Peter

    va_list help, please ...

    Peter, Feb 15, 2005, in forum: C++
    Replies:
    6
    Views:
    3,546
    Pete Becker
    Feb 15, 2005
  4. John Guo

    va_list help

    John Guo, Mar 31, 2005, in forum: C++
    Replies:
    5
    Views:
    3,309
    Pete Becker
    Mar 31, 2005
  5. Douwe
    Replies:
    3
    Views:
    734
    Chris Torek
    Aug 30, 2003
Loading...

Share This Page