Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > va_list

Reply
Thread Tools

va_list

 
 
mito19651996@hotmail.com
Guest
Posts: n/a
 
      05-17-2006
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

 
Reply With Quote
 
 
 
 
Ben Pfaff
Guest
Posts: n/a
 
      05-17-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      05-17-2006
(E-Mail Removed) 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) (E-Mail Removed) <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.
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      05-17-2006


Keith Thompson wrote On 05/17/06 17:14,:
> (E-Mail Removed) 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.

--
(E-Mail Removed)

 
Reply With Quote
 
Malcolm
Guest
Posts: n/a
 
      05-17-2006



<(E-Mail Removed)> 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




 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-17-2006
Eric Sosman <(E-Mail Removed)> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      05-18-2006
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)
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-18-2006
Richard Heathfield <(E-Mail Removed)> 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) (E-Mail Removed) <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.
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      05-18-2006
Keith Thompson wrote:
>
> Richard Heathfield <(E-Mail Removed)> 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
 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      05-18-2006
On 2006-05-18, Keith Thompson <(E-Mail Removed)> wrote:
> Richard Heathfield <(E-Mail Removed)> 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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
va_list in JNI leonwild@hotmail.com Java 4 06-23-2005 02:57 PM
va_list help John Guo C++ 5 03-31-2005 03:05 PM
va_list help, please ... Peter C++ 6 02-15-2005 06:40 PM
reference to va_list Rich Herrick C++ 0 01-16-2005 06:12 PM
va_list, va_start, va_end very nice ... but how to copy all vars as one parameter ? Douwe C Programming 3 08-30-2003 10:31 PM



Advertisments