No format string passed to variable argument list function

[Adam]

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]

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]

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(buffer, sizeof(buffer), format, argptr);
va_end(argptr);
buffer[sizeof(buffer)-1] = '\0';
printf("%s\n",buffer); /* 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",message);
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:

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*

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]

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(buffer, sizeof(buffer), format, argptr);
  va_end(argptr);
  buffer[sizeof(buffer)-1] = '\0';
  printf("%s\n",buffer); /* 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",message);
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:

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]

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?

 

[Huibert Bol]

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.

 

[Keith Thompson]

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.


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.h> is
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. }

 

[Tim Rentsch]

(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 Dijk]

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]

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.

 

[Harald van Dijk]

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

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

That's a good point. Considering those requirements, I can only agree that
the definition of object (or at least my interpretation of it) is too
broad, and whatever location holds a return address isn't or needn't be an
object.