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

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

[Nate Eldredge]

Adam <ne**@snowstone.org.ukwrites:

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(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:

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

/* your function */

int main(void) {
print("%s\n", "Hello world!");
print("Goodbye world!\n");
return 0;
}

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

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?

It certainly seems like v*printf should be able to handle a va_list from
a function with no extra arguments, though the standard doesn't
explicitly seem to say so. It's conceivable that there's a bug in your
standard library, but hard to say just yet.

[Keith Thompson]

Adam <ne**@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(buffer, sizeof(buffer), format, argptr);
va_end(argptr);

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

This isn't your problem, but what's the purpose of the above?
vsnprintf() should already write a '\0'-terminated string to buffer;
you're just setting character 1023 (which is likely far beyond the end
of the string) to '\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).

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

It would help if you could post a small, complete, compilable program
that demonstrates the problem. I don't see anything in what you
posted that explains the symptom you're seeing.

--
Keith Thompson (The_Other_Keith) 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"

[Ian Collins]

Adam wrote:

Hi,

I have a simple printf-like function:

Did you include <stdarg.h>?

--
Ian Collins

[Peter Nilsson]

Adam <[e-mail]:

I have a simple printf-like function:

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

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

* va_list argptr;
* int i;

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

Note that [v]snprintf is new in C99. Although many C90
implementations have it as an extension, they may
differ in semantics and prototype.

Did you include the correct header or prototype?
Is print defined before or after use? If after,
did you prototype it correctly before use?

* va_end(argptr);

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

This shouldn't be necessary.

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

puts(buffer) is better since the result string could have
% characters in it that will be subject to conversion.

* return i;
}

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

char message[50] = "hi there";

print("%s",message);

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

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

Post a compilable program that exhibits the problem.

Also try print("%s\n", message);

Is there something wrong with what I'm doing,

Nothing obvious.

or should I be looking elsewhere to work out the
cause of my crash?

If you're using a C90 extension, you should check
the manual on what vsnprintf does.

--
Peter

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

Adam wrote:

>I have a simple printf-like function:

Did you include <stdarg.h>?

He must have; otherwise the identifier "va_arg" wouldn't be visible.

--
Keith Thompson (The_Other_Keith) 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"

[Ian Collins]

Keith Thompson wrote:

Ian Collins <ia******@hotmail.comwrites:

>Adam wrote:

>>I have a simple printf-like function:

Did you include <stdarg.h>?

He must have; otherwise the identifier "va_arg" wouldn't be visible.

Or va_list. Yes it was a silly question!

--
Ian Collins

[Peter Nilsson]

Ian Collins <[e-mail]:

Keith Thompson wrote:

Ian Collins <[e-mail]:

Adam wrote:
I have a simple printf-like function:
>
Did you include <stdarg.h>?

He must have; otherwise the identifier "va_arg"
wouldn't be visible.

Or va_list. *Yes it was a silly question!

Not necessarily. How do you know Adam isn't using
<varargs.h>?

--
Peter

[Ben Bacarisse]

Peter Nilsson <ai***@acay.com.auwrites:

Adam <[e-mail]:

<snip>

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

puts(buffer) is better since the result string could have
% characters in it that will be subject to conversion.

Did you misread the printf? It looks fine to me (though puts probably
has the edge).

--
Ben.

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

Keith Thompson wrote:

>Ian Collins <ia******@hotmail.comwrites:

>>Adam wrote:
I have a simple printf-like function:

Did you include <stdarg.h>?

He must have; otherwise the identifier "va_arg" wouldn't be visible.

Or va_list. Yes it was a silly question!

Yes, I meant va_list.

--
Keith Thompson (The_Other_Keith) 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"

[Ian Collins]

Peter Nilsson wrote:

Ian Collins <[e-mail]:

>Keith Thompson wrote:

>>Ian Collins <[e-mail]:
Adam wrote:
I have a simple printf-like function:
Did you include <stdarg.h>?
He must have; otherwise the identifier "va_arg"
wouldn't be visible.

Or va_list. Yes it was a silly question!

Not necessarily. How do you know Adam isn't using
<varargs.h>?

He would have seen a warning for the va_start with 2 parameters.

--
Ian Collins

[Peter Nilsson]

Ben Bacarisse <[e-mail]:

Peter Nilsson <[e-mail]:

Adam <[e-mail]:

* printf("%s\n",buffer);

puts(buffer) is better since the result string
could have % characters...

Did you misread the printf?

Yes, I did.

>*It looks fine to me

It is. I think I was thinking out aloud about the
later...

print(message);

Thanks for pointing it out.

--
Peter

[Kenny McCormack]

In article <51**********************************@l33g2000pri. googlegroups.com>,
Peter Nilsson <ai***@acay.com.auwrote:

>Adam <[e-mail]:

>I have a simple printf-like function:

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

Maybe make this static. 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?

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

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

In article
<51**********************************@l33g2000pri. googlegroups.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, and while some may have that location fixed (making it a non-
automatic object), plenty of others don't. I'm not aware of
implementations that don't have a lower limit at all, though.

[s0suk3]

On Oct 15, 5:02*pm, Adam <ne**@snowstone.org.ukwrote:

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(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;

}

You're using [v]snprintf() as a "safer [v]sprintf()", which is already
OK, but you should also take advantage of the fact that [v]snprintf()
returns the required length when you pass it zero as the size (the 2nd
argument). That will ensure that the result won't be truncated (in
this case, to 1024 characters).

int print(const char *format, ...)
{
va_list ap;

va_start(ap, format);
int len = vsnprintf(NULL, 0, format, ap); // figure out the length
va_end(ap);

char buffer[len + 1];
va_start(ap, format);
vsnprintf(buffer, len + 1, format, ap);
va_end(ap);

printf("%s\n", buffer);

return len;
}

Sebastian

[Adam]

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

Adam <[e-mail]:

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(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:

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

/* your function */

int main(void) {
* print("%s\n", "Hello world!");
* print("Goodbye world!\n");
* return 0;

}

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

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.
Keith wrote:

This isn't your problem, but what's the purpose of [buffer[sizeof(buffer)-1] = '\0']?

Hmm, well when I originally wrote a function like this I wasn't sure
about the rules for whether it would get terminated or not and it
seemed it didn't if the incoming string was truncated. However, a
similar test now seems to reveal it does work, as you say.
Thanks,
Adam

[Keith Thompson]

Adam <ne**@snowstone.org.ukwrites:
[...]

Keith wrote:

>This isn't your problem, but what's the purpose of [buffer[sizeof(buffer)-1] = '\0']?

Hmm, well when I originally wrote a function like this I wasn't sure
about the rules for whether it would get terminated or not and it
seemed it didn't if the incoming string was truncated. However, a
similar test now seems to reveal it does work, as you say.

Testing doesn't prove anything. The way to confirm that the string
will be properly terminated string is to read the documentation for
the functions you're using.

If you were using a function that *isn't* guaranteed to produce a
properly terminated string, testing will very likely fail to detect
the problem; consider that uninitialized memory is often set to zero
(though that's by no means guaranteed).

--
Keith Thompson (The_Other_Keith) 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"

[jameskuyper]

Adam wrote:

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

Adam <[e-mail]:

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(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 amain function:

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

/* your function */

int main(void) {
� print("%s\n", "Hello world!");
� print("Goodbye world!\n");
� return 0;

}

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

In C, the type of a string literal is char*; when used in this
contexts, (and most other contexts) "message" decays to a char* too.
Therefore, whatever issue might arise with a string literal will also
arise with "message".

The first paragraph that you refer to on that web page talks about the
integer promotions, which only apply to integer types like 'char'.
Pointer types like 'char *' remain unaffected by the integer
promotions.

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

Start with your complicated example, and start simplifying it by
removing things. Test after each removal. When a removal causes the
problem to disappear, put it back in and remove something else. If you
do this systematically, you will either produce a minimum-size program
that demonstrates the problem which you can post to this group, no
matter how long it is; or you'll realize what the problem is. In my
experience, it's usually the second possibility that actually comes
up.

This isn't your problem, but what's the purpose of [buffer[sizeof(buffer)-1] = '\0']?

Hmm, well when I originally wrote a function like this I wasn't sure
about the rules for whether it would get terminated or not and it
seemed it didn't if the incoming string was truncated. However, a
similar test now seems to reveal it does work, as you say.

Performing a test is not a goodway to figure this out. The test will
tell you what your compiler does; it won't tell you whether this a
special case, or something you can rely on. 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.

[vippstar]

On Oct 20, 10:09 pm, [e-mail] wrote:

>
In C, the type of a string literal is char*; when used in this
contexts, (and most other contexts) "message" decays to a char* too.
Therefore, whatever issue might arise with a string literal will also
arise with "message".

The type of a string literal is char [n] where n is size of the string
literal.
What are you talking about? I hope I haven't took this out of context.

[jameskuyper]

[e-mail] wrote:

On Oct 20, 10:09 pm, [e-mail] wrote:

In C, the type of a string literal is char*; when used in this
contexts, (and most other contexts) "message" decays to a char* too.

....

The type of a string literal is char [n] where n is size of the string
literal.
What are you talking about? I hope I haven't took this out of context.

What I should have done is replace the first sentence with:

In C, in this context (and in most other contexts) both string
literals and arrays of char like "message" are converted to char*
pointers.

[Adam]

On 20 Oct, 20:09, [e-mail] 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, [e-mail] 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 <[e-mail]:

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

Adam <[e-mail]:

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:

<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 <[e-mail]>
wrote:

On 20 Oct, 19:07, Adam <[e-mail]:

>

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

Adam <[e-mail]:
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:

<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 <[e-mail]:

[...]

>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_Keith) 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*********@quicknet.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_Keith) 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**********************************@l33g2000pri. googlegroups.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.

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

On Tue, 11 Nov 2008 09:24:14 -0800, Tim Rentsch wrote:

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