I've two questiond regarding variable arguments.
First, how to count arguments passed ?
I see that va_arg macro can be used, but if don't know type of
arguments ?

Then, How can a print a % sign with vsnprintf ?
Please consider this code:

//
#include <stdio.h>
#include <stdarg.h>

//
#define BUFFER_SIZE     256

//
void myPrintf(char *szText, ...)
{
        char szBuffer[BUFFER_SIZE] = { 0 };
        va_list pArgList = NULL;

        va_start(pArgList, szText);
        vsnprintf(szBuffer, BUFFER_SIZE, szText, pArgList);
        va_end(pArgList);

        printf(szBuffer);

        return 0;

this string should show a (percent sign)

as you can see % sign is not present, with Lcc I get an empty string.

     [*] Since it's a part of the implementation, the printf()
function might use some kind of implementation-specific
trickery rather than actually using <stdarg.h> -- it might
not even be written in C.  But it "acts like" a <stdarg.h>
function, and its strategy is one you can use yourself.

     Suggestion: Change the final printf() to

        fputs (szBuffer, stdout);

... which just writes the characters of szBuffer without
trying to interpret them as a format string.  (In the example
code, szBuffer isn't really necessary: You could just use
vprintf(), or discard myPrintf() altogether and use printf().
But I assume this is a stripped-down example, and that you
intend to do more with szBuffer than you've shown here.)

--
Eric.Sos...@sun.com

What is in szBuffer?

"this string should show a % (percent sign)\n"

What happens when you pass this string, containing only a SINGLE
percent sign, to printf?

Maybe you should use another function in order to display your
output, such as fwrite.  Or, if you want to be silly but not do
something partiicularly dangerous:
        printf("%s", szBuffer);

The camel-case and type prefixes are unidiomatic and not useful; if
you're going to write C, I recommend you avoid them.

Idiomatic usage is an important thing, because people have to work on other
peoples' code.  It is easier for everyone to write correct and efficient C
if people follow common conventions.  The bulk of existing C has standardized
on names like do_some_things() rather than doSomeThings().  That means that,
in a large project, there will always be a fair amount of code which has
to refer to functions which have lowercase-and-underscores names.  If you use
camel case for your new functions, you've created a barrier to quick and
effective programming; someone who remembers the words "do some things"
has to *remember* which way you spelled them, rather than simply writing them
using the standard convention.  This is of course caught mostly at compile
time, but it's a hassle and a distraction.

Type prefixes are in general stupid in a strongly-typed language.  They
distract the reader from the variable's function to interject with information
the reader probably already has readily at hand.

adverbBasically, conjunctionIf nounYou verbFind pronounThis adjectiveReadable,
conjunctionMaybe pronounIt verbWorks prepositionFor pronounYou.  For most
people, it doesn't work.

Type prefixs on the other hand are Pure Evil. Search for Hungarian
Notation on the internet.

I know structs mess up this idealised world, but good naming naming
conventions and modularisation practices clean this all up. And you do
have a decent sourec code browser don't you?

****************
What do the letters W and L stand for in WPARAM and LPARAM?
Once upon a time, Windows was 16-bit. Each message could carry with it
two pieces of data, called WPARAM and LPARAM. The first one was a 16-
bit value ("word"), so it was called W. The second one was a 32-bit
value ("long"), so it was called L.

You used the W parameter to pass things like handles and integers. You
used the L parameter to pass pointers.

When Windows was converted to 32-bit, the WPARAM parameter grew to a
32-bit value as well. So even though the "W" stands for "word", it
isn't a word any more. (And in 64-bit Windows, both parameters are 64-
bit values!)

It is helpful to understand the origin of the terms. If you look at
the design of window messages, you will see that if the message takes
a pointer, the pointer is usually passed in the LPARAM, whereas if the
message takes a handle or an integer, then it is passed in the WPARAM.
(And if a message takes both, the integer goes in the WPARAM and the
pointer goes in the LPARAM.)

Once you learn this, it makes remembering the parameters for window
messages a little easier. Conversely, if a message breaks this rule,
then it sort of makes your brain say, "No, that's not right."
*******************

But yeah, you make good points -- it can be more important to do things
aligned with the rest of the code base.

Had they used names like "value" and "pointer", there would be no confusion
and no need for that explanation.

[...]

   autoptr<Thing> thingAP;
   sharedptr<Thing> thingSP;
   dumbptr<Thing> thingDp;

but that may reflect on my ability to deal with C++s smart pointers.
{for the non-C++ those pointers probably all do different things to
the object they point at when they go out of scope)

Great. Now we need a new language, you just broke the old one ;-p

Thus, "strchr()" not "chr()" (after all, what if you wanted to find a
character in something other than a string?), but "s", not
"strArgumentString1".

Apart from Seebs's remarks about the distinction between functions
and (local) variables, functions need to have distinct names, and
there are often multiple versions of a given function that operate
on different types.  The 'f' on sqrtf() is more for the compiler's
(and linker's) benefit than for the reader's benefit.

(Yes, I'm responding seriously to what was probably at least partly
written in jest, but there are serious points to be made.)

The switching of functions for variables was indeed not very subtle
sleight of hand too, but as I'd just seen "do_some_things() rather
than doSomeThings()", I thought I could conflate the two objections.

And I would have got away with it if it wasn't for you pesky meddling
regs ;-p

   integer size buffer;
   variable argument start (arg list, size text);

"ALGOL 60 was a language so far ahead of its time that it
was not only an improvement on its predecessors but also
on nearly all its successors".
                --C.A.R. Hoare