pointer

[Richard Tobin]

but C99 7.15.1.1 (va_arg) need not apply.

I take it you mean that printf() might not be implemented using the
defined stdarg mechanisms, so it doesn't have to obey the rules for
va_arg(). Surely that is not the intention of the standard.

Especially since the rationale says that the va_* macros were added to
C to enable the portable implementation of library functions such as
printf().

-- Richard

 

[Harald van Dijk]

I take it you mean that printf() might not be implemented using the
defined stdarg mechanisms, so it doesn't have to obey the rules for
va_arg(). Surely that is not the intention of the standard.

Especially since the rationale says that the va_* macros were added to C
to enable the portable implementation of library functions such as
printf().

I am sure the intent was never to _require_ implementations to implement
any standard library functions portably, only to allow them to do so.

I am unsure about the intent of the standard regarding the original
question (printf("%u", 0) and equivalent signed/unsigned mismatches).

 

[Richard Tobin]

I take it you mean that printf() might not be implemented using the
defined stdarg mechanisms, so it doesn't have to obey the rules for
va_arg(). Surely that is not the intention of the standard.

Especially since the rationale says that the va_* macros were added to C
to enable the portable implementation of library functions such as
printf().

[/QUOTE]

I am sure the intent was never to _require_ implementations to implement
any standard library functions portably, only to allow them to do so.

Of course not. I mentioned it as suggesting that they were not
intending the library functions to be any different from other
variable-argument functions.

-- Richard

 

[Antoninus Twink]

All you could dump is the mostky rather uninteresting address space of
your program.

On the contrary, a core dump can be very interesting indeed when you're
debugging a program. However, on most platforms this sort of memory dump
is generated automatically when your program dies.

If the OP is interested in monitoring memory usage within a process, he
might want to check out the source code to valgrind, though I think it's
pretty hardcore stuff.

 

[Harald van Dijk]

Of course not. I mentioned it as suggesting that they were not
intending the library functions to be any different from other
variable-argument functions.

Okay, here's the exact wording from the rationale:

"These macros, modeled, after the UNIX <varargs.h> macros, have been added
to enable the portable implementation in C of library functions such as
printf and scanf (see §7.19.6)."

I don't see where this intent is expressed.

But why does all this matter? This subthread started with viza pointing
out that printf("%02x ", p) -- where p is an unsigned char -- needs
a different format specifier, or needs a cast. I replied saying that
technically, viza was right, but practically, the code was fine. You took
issue with that. Why does the intent matter? If the intent is not
expressed in the standard, then _technically_, the code _is_ invalid,
regardless of whether anyone wants to allow or disallow it.

 

[Walter Roberson]

On the contrary, a core dump can be very interesting indeed when you're
debugging a program. However, on most platforms this sort of memory dump
is generated automatically when your program dies.

Different senses of the word 'dump'.

A "core dump" used to be pages and pages and pages of (usually)
hex and text, output by the operating system (or operating
executive anyhow) when a problem was detected (or upon request.)

When disk space became affordable enough, "core dump" in common
parlance mutated into a binary file representing the system or
program state, and there would be programs (interactive or otherwise)
to examine portions of that state.

Modern "debuggers" usually are able to examine one of these binary
"core dumps". But inside the debugger (or other program), the action
of requesting that a particular portion of the binary state be
output in readable format can also be referred to as "dumping" that
portion of memory.

Thus, "memory dump" can, these days, refer to the binary file holding
program state, or to the action of printing a portion of that state
in readable format (or to the output so obtained.) And of course,
one might want to "dump" (whether to binary file or as printable
text) a portion of memory from a currently running program instead
of based upon a stored state....