va_list

[mito19651996]

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

 

[Ben Pfaff]

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.

 

[Keith Thompson]

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.

 

[Eric Sosman]

Keith Thompson wrote On 05/17/06 17:14,:

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.

 

[Malcolm]

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.

 

[Keith Thompson]

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.

 

[Richard Heathfield]

Ben Pfaff said:

[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?

 

[Keith Thompson]

Ben Pfaff said:

[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.

 

[pete]

Ben Pfaff said:

[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;
}

 

[Jordan Abel]

Ben Pfaff said:

[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).

 

[Rod Pemberton]

(e-mail address removed) 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

 

[Keith Thompson]

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]

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.

 

[pete]

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,

 

[Dave Thompson]

Ha! I never noticed your sig...

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