No format string passed to variable argument list function

[Adam]

Hi,

I have a simple printf-like function:

int print(const char *format, ...)
{
char buffer[1024];
va_list argptr;
int i;

va_start(argptr , format);
i = vsnprintf(buffe r, sizeof(buffer), format, argptr);
va_end(argptr);

buffer[sizeof(buffer)-1] = '\0';

printf("%s\n",b uffer); /* this bit just for the sake of testing */

return i;
}

If I call the function using something like:
char message[50];
strcpy(message, "hi there");
print("%s",mess age);

everything works, but if I do:
print(message);

it doesn't (program crashes with an abort).

Is there something wrong with what I'm doing, or should I be looking
elsewhere to work out the cause of my crash?

Thanks a lot,
Adam

[Adam]

On 20 Oct, 20:09, jameskuy...@ver izon.net wrote:

Reading and understanding
the documentation of the vsnprintf() function is the best way. The
standard's description of vsnprintf() cross-references snprintf(). The
description of snprintf() says "a null character is written at the end
of the characters actually written into the array." The documentation
that comes with your compiler should say roughly the same thing.

At the time I was doing the investigating I had trouble finding the
documentation. :( If someone can point me at exactly this item, given
I'm using GCC (what other information is needed?), it would probably
help me in future...

Thanks,
Adam

[jameskuyper]

Adam wrote:

On 20 Oct, 20:09, jameskuy...@ver izon.net wrote:

Reading and understanding
the documentation of the vsnprintf() function is the best way. The
standard's description of vsnprintf() cross-references snprintf(). The
description of snprintf() says "a null character is written at the end
of the characters actually written into the array." The documentation
that comes with your compiler should say roughly the same thing.

At the time I was doing the investigating I had trouble finding the
documentation. :( If someone can point me at exactly this item, given
I'm using GCC (what other information is needed?), it would probably
help me in future...

On any unix-like platform where gcc has been installed, there's a good
chance that you'll find correct documentation by typing 'man
vsnprintf'. I'm not sure of the best approach on other platforms.

[Nick Keighley]

On 20 Oct, 19:07, Adam <n...@snowstone .org.ukwrote:

On 16 Oct, 00:50, Nate Eldredge <[e-mail] nwrote:

Adam <n...@snowstone .org.ukwrites:

I have a simple printf-like function:

int print(const char *format, ...)
{
char buffer[1024];
va_list argptr;
int i;

va_start(argptr , format);
i = vsnprintf(buffe r, sizeof(buffer), format, argptr);
va_end(argptr);

buffer[sizeof(buffer)-1] = '\0';

printf("%s\n",b uffer); /* this bit just for the sake of testing */

return i;
}

If I call the function using something like:
char message[50];
strcpy(message, "hi there");
print("%s",mess age);

everything works, but if I do:
print(message);

it doesn't (program crashes with an abort).

I don't see a problem myself. I took your function and added a main
function:

<snip>

and it compiles and runs without problems on three different systems.

Actually, the bit I was wondering about was passing a (char *) to the
print function, rather than a literal string.

should be ok. *If* it contains a valid string. Possible problem
with % characters in the string?

char *message = "the %s are not as indicated\n"
printf (message);

I did find this
page:http://www.eskimo.com/~scs/cclass/int/sx11c.html
...which seems to suggest (in the first paragraph) this might be
wrong.

it says:

"When a function with a variable-length argument list is called, the
variable arguments are passed using C's old ``default argument
promotions.''
These say that types char and short int are automatically promoted to
int,
and type float is automatically promoted to double. Therefore,
varargs
functions will never receive arguments of type char, short int, or
float.
Furthermore, it's an error to ``pass'' the type names char, short int,
or
float as the second argument to the va_arg() macro. Finally, for
vaguely
related reasons, the last fixed argument (the one whose name is passed
as
the second argument to the va_start() macro) should not be of type
char,
short int, or float, either."

I can't see where the problem is. I don't see a mention of char*

There could be something that I'm missing, though, which doesn't show up
on those systems. Can you post a complete program that aborts, and tell
us the system and compiler you're using?

Well, the compiler is GCC. Trouble is, I can't replicate it in a
simple example (and a complex example would take me well out of
comp.lang.c territory). I though perhaps that some undefined behaviour
was causing problems in one case but not in another, but
I guess I need to look elsewhere for my problem.

what does your debugger say? Can you add diagnostic printouts?
(This is in addition to what other posters say about cutting
down your program in stages).

<snip>
--
Nick Keighley

A good designer must rely on experience, on precise, logic thinking;
and on pedantic exactness. No magic will do.
(Wirth)

[Adam]

On 21 Oct, 08:45, Nick Keighley <nick_keighley_ nos...@hotmail. com>
wrote:

On 20 Oct, 19:07, Adam <n...@snowstone .org.ukwrote:

>

On 16 Oct, 00:50, Nate Eldredge <[e-mail] nwrote:

Adam <n...@snowstone .org.ukwrites:
I have a simple printf-like function:

int print(const char *format, ...)
{
* char buffer[1024];
* va_list argptr;
* int i;

* va_start(argptr , format);
* i = vsnprintf(buffe r, sizeof(buffer), format, argptr);
* va_end(argptr);

* buffer[sizeof(buffer)-1] = '\0';

* printf("%s\n",b uffer); /* this bit just for the sake of testing*/

* return i;
}

If I call the function using something like:
char message[50];
strcpy(message, "hi there");
print("%s",mess age);

everything works, but if I do:
print(message);

it doesn't (program crashes with an abort).

I don't see a problem myself. *I took your function and added a main
function:

<snip>

and it compiles and runs without problems on three different systems.

Actually, the bit I was wondering about was passing a (char *) to the
print function, rather than a literal string.

should be ok. *If* it contains a valid string. Possible problem
with % characters in the string?

Bingo :) That's exactly what it was. The input to my function was
coming from the GUI element of the app and I hadn't considered
checking for "%" in the string - and that's what was there!

Thanks all,
Adam

[Keith Thompson]

Nick Keighley <ni************ ******@hotmail. comwrites:

On 20 Oct, 19:07, Adam <n...@snowstone .org.ukwrote:

[...]

>I did find this
page:http://www.eskimo.com/~scs/cclass/int/sx11c.html
...which seems to suggest (in the first paragraph) this might be
wrong.

it says:

"When a function with a variable-length argument list is called, the
variable arguments are passed using C's old ``default argument
promotions.'' These say that types char and short int are
automatically promoted to int, and type float is automatically
promoted to double. Therefore, varargs functions will never receive
arguments of type char, short int, or float. Furthermore, it's an
error to ``pass'' the type names char, short int, or float as the
second argument to the va_arg() macro. Finally, for vaguely related
reasons, the last fixed argument (the one whose name is passed as
the second argument to the va_start() macro) should not be of type
char, short int, or float, either."

What's the basis for that last sentence? I'm fairly sure that, as far
as the standard is concerned, using a char, short, or float as the
last fixed argument is perfectly ok. Perhaps some early compilers got
this wrong?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Huibert Bol]

Keith Thompson wrote:

Nick Keighley <ni************ ******@hotmail. comwrites:

>Finally, for vaguely related reasons, the last fixed argument (the
one whose name is passed as the second argument to the va_start()
macro) should not be of type char, short int, or float, either."

What's the basis for that last sentence? I'm fairly sure that, as far
as the standard is concerned, using a char, short, or float as the
last fixed argument is perfectly ok.

From the description of va_start:

If the parameter parmN is declared (...) with a type that is not
compatible with the type that results after application of the default
argument promotions, the behavior is unde�ned.

Perhaps some early compilers got this wrong?

Big-endian machine usually get this wrong: the data is passed in the
"wrong" part a word. To compensate the compiler offsets the value
returned by the & operator.

--
Huibert
"Hey! HEY! Curious cat, here!" -- Krosp I (GG)

[Keith Thompson]

Huibert Bol <hu*********@qu icknet.nlwrites :

Keith Thompson wrote:

>Nick Keighley <ni************ ******@hotmail. comwrites:

>>Finally, for vaguely related reasons, the last fixed argument (the
one whose name is passed as the second argument to the va_start()
macro) should not be of type char, short int, or float, either."

What's the basis for that last sentence? I'm fairly sure that, as far
as the standard is concerned, using a char, short, or float as the
last fixed argument is perfectly ok.

From the description of va_start:

If the parameter parmN is declared (...) with a type that is not
compatible with the type that results after application of the default
argument promotions, the behavior is undeÞned.

>Perhaps some early compilers got this wrong?

Big-endian machine usually get this wrong: the data is passed in the
"wrong" part a word. To compensate the compiler offsets the value
returned by the & operator.

You know, I was thinking just after I wrote the above, and just before
I sent it, that maybe I should check the standard first. I really
should pay more attention to myself when I think things like that.

It would have been nice if the language had some type-safe built-in
mechanism for dealing with variadic functions. Instead, <stdarg.his
designed to be compatible with each of the various ugly kludges that
are necessary on different platforms. It's not too surprising that it
has little inconsistencies like this. Well, not quite
inconsistencies , but things that would undoubtedly be more consistent
if they were designed from scratch.

We'll know better next time we invent C from scratch. 8-)}

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Tim Rentsch]

Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail. comwrites:

On Thu, 16 Oct 2008 08:18:38 +0000, Kenny McCormack wrote:

In article
<51************ *************** *******@l33g200 0pri.googlegrou ps.com>,
Peter Nilsson <ai***@acay.com .auwrote:

>There's no upper or lower limit on automatic
storage, but I prefer not to allocate more than 256 bytes in a single
function.

(CLC pedant mode)

I would imagine that the lower limit is 0 in most cases.

Are you aware of any implementations that require at least one automatic
object?

(Continued pedant mode)

I think whatever location is used to store the return address qualifies as
an object, [...]

A return address is not a C value; hence storage for it is not
an object.

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sun, 09 Nov 2008 23:21:56 -0800, Tim Rentsch wrote:

Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail. comwrites:

>On Thu, 16 Oct 2008 08:18:38 +0000, Kenny McCormack wrote:

Are you aware of any implementations that require at least one
automatic object?

(Continued pedant mode)

I think whatever location is used to store the return address qualifies
as an object, [...]

A return address is not a C value; hence storage for it is not an
object.

The storage for the return address is usually an object:

object:
region of data storage in the execution environment, the contents of
which can represent values

Note how it says "can" represent values. If the same register or memory
location is ever used to store a definite C value, then that location is
an object. I'll admit that a dedicated return address register probably
doesn't qualify, though.

It doesn't matter whether the return address itself qualifies as a value,
and I think you may be right that it doesn't.

[Tim Rentsch]

Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail. comwrites:

On Sun, 09 Nov 2008 23:21:56 -0800, Tim Rentsch wrote:

Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail. comwrites:

On Thu, 16 Oct 2008 08:18:38 +0000, Kenny McCormack wrote:
Are you aware of any implementations that require at least one
automatic object?

(Continued pedant mode)

I think whatever location is used to store the return address qualifies
as an object, [...]

A return address is not a C value; hence storage for it is not an
object.

The storage for the return address is usually an object:

object:
region of data storage in the execution environment, the contents of
which can represent values

Note how it says "can" represent values. If the same register or memory
location is ever used to store a definite C value, then that location is
an object. I'll admit that a dedicated return address register probably
doesn't qualify, though.

Hmmm. Interesting argument.

Despite 3.14 being worded the way it is, it seems clear that the term
"object" as it is used in the standard should be read as not including
return-address memory. Considering the requirements of 6.2.4, for
example, it needn't have a constant address (or any address at all, in
the C sense), nor does it have a well-defined lifetime. Also, just
because a certain memory location was an object in the past doesn't
mean it's an object now. Machines with segmented addressing, for
example, can have portions of the virtual address space disappear,
which removes any object-ness of that memory; similarly, automatic
variables past the end of their lifetimes may have their storage
locations cease being objects at any time, either because of page
invalidation, address range checking, or being overlaid with
differently sized objects of another function. Considering all these
aspects, the quoted reasoning given above isn't convincing.

So, I still find the proposition that "the term 'object' doesn't
include return-address memory" to be more consistent with all that the
standard says about objects, and therefore more compelling.