By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,154 Members | 1,037 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,154 IT Pros & Developers. It's quick & easy.

Portable way to printf() a size_t instance

P: n/a

Hello,

I have code which makses use of variables of type size_t. The code is
originally developed on a 32 bit machine, but now it is run on both a
32 bit and a 64 bit machine.

In the code have statements like this:

size_t buffer_size;
printf("Total buffer size: %ud bytes \n",buffer_size);

Now the format "%ud" works nicely on the 32 bit computer; it actually
works on the 64 bit computer as well, but the compiler spits out
warning message. On the 64 bit computer it would have prefered:

printf("Total buffer size: %uld bytes \n",buffer_size); /* Or udl? */

As I said it works, but I would really prefer the program to compile
without warnings, as it is now I get *many* warnings of the type

file.c:line: warning: unsigned int format, different type arg (arg 1).

And, on several occasion this has actually led me to miss more
important warnings.
Any tips appreciated.
Joakim
--
Joakim Hove
hove AT ift uib no /
Tlf: +47 (55 5)8 27 90 / Stabburveien 18
Fax: +47 (55 5)8 94 40 / N-5231 Paradis
http://www.ift.uib.no/~hove/ / 55 91 28 18 / 92 68 57 04
Nov 14 '05 #1
Share this Question
Share on Google+
25 Replies


P: n/a
Joakim Hove wrote:

Hello,

I have code which makses use of variables of type size_t. The code is
originally developed on a 32 bit machine, but now it is run on both a
32 bit and a 64 bit machine.

In the code have statements like this:

size_t buffer_size;
printf("Total buffer size: %ud bytes \n",buffer_size);

Now the format "%ud" works nicely on the 32 bit computer; it actually
works on the 64 bit computer as well, but the compiler spits out
warning message. On the 64 bit computer it would have prefered:

printf("Total buffer size: %uld bytes \n",buffer_size); /* Or udl? */

As I said it works, but I would really prefer the program to compile
without warnings, as it is now I get *many* warnings of the type

file.c:line: warning: unsigned int format, different type arg (arg 1).

And, on several occasion this has actually led me to miss more
important warnings.

Any tips appreciated.


For C89, convert to long unsigned.

printf("sizeof(int) is %lu\n", (long unsigned)sizeof(int));

--
pete
Nov 14 '05 #2

P: n/a
Joakim Hove wrote:
Hello,

I have code which makses use of variables of type size_t. The code is
originally developed on a 32 bit machine, but now it is run on both a
32 bit and a 64 bit machine.

In the code have statements like this:

size_t buffer_size;
printf("Total buffer size: %ud bytes \n",buffer_size);

Now the format "%ud" works nicely on the 32 bit computer;
It shouldn't. The %<qualifier>d are the conversion specifiers for signed
integers; the %<qualifier>u are the conversion specifiers for unsigned
integers. 'u' is not a qualifier for %d.

it actually
works on the 64 bit computer as well, but the compiler spits out
warning message.
Something like "%ud doesn't mean anything"?
On the 64 bit computer it would have prefered:

printf("Total buffer size: %uld bytes \n",buffer_size); /* Or udl? */


I doubt it. The printf routine rarely "wants" meaningless specifiers.
If you have an up-to-date library, you could use
printf("Total buffer size: %zu bytes \n",buffer_size);

Otherwise, try
printf("Total buffer size: %lu bytes \n",
(long unsigned)buffer_size);
or
printf("Total buffer size: %llu bytes \n",
(long long unsigned) buffer_size);

That is, use an (properly written) unsigned specifier and cast the
size_t argument to the same size unsigned.
Nov 14 '05 #3

P: n/a
Martin Ambuhl wrote (and now clarifies):
Joakim Hove wrote: [...]
Now the format "%ud" works nicely on the 32 bit computer;

It shouldn't. The %<qualifier>d are the conversion specifiers for signed
integers; the %<qualifier>u are the conversion specifiers for unsigned
integers. 'u' is not a qualifier for %d.


I should have been clearer. "%u" is the specifier you are using. The
"d" is a literal portion of the output string. See the example below
and note the extra 'd' at the end of the string:

#include <stdio.h>
int main(void)
{
printf("Printing an unsigned value using %%ud: %ud\n", 5u);
return 0;
}

Printing an unsigned value using %ud: 5d
Nov 14 '05 #4

P: n/a
Joakim Hove <ho**@ift.uib.no> writes:
I have code which makses use of variables of type size_t. The code is
originally developed on a 32 bit machine, but now it is run on both a
32 bit and a 64 bit machine.

In the code have statements like this:

size_t buffer_size;
printf("Total buffer size: %ud bytes \n",buffer_size);
I think you mean "%u", not "%ud". "%d" is for (signed) int; "%u" is
for unsigned int.
Now the format "%ud" works nicely on the 32 bit computer; it actually
works on the 64 bit computer as well, but the compiler spits out
warning message. On the 64 bit computer it would have prefered:

printf("Total buffer size: %uld bytes \n",buffer_size); /* Or udl? */


The format for unsigned long is "%lu".

In C90, the best way to print a size_t value is to convert it
to unsigned long and use "%lu":

printf("Total buffer size: %lu bytes\n", (unsigned long)buffer_size);

C99 adds a 'z' modifier specifically for size_t:

printf("Total buffer size: %zu bytes\n", buffer_size);

but many printf implementations don't support it. (Even if your
compiler supports C99 and defines __STDC_VERSION__ appropriately,
that's not, practically speaking, a guarantee that the library also
conforms to C99.)

Even in C99, the "%lu" method will work unless size_t is bigger than
unsigned long *and* the value being printed exceeds ULONG_MAX, which
is unlikely to happen in practice.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #5

P: n/a
Me
%z is the specifier for size_t in C99 but I assume you want to be
backwards compatible with older and broken implementations. Here is the
smart way to go about this (untested, use at your own risk):

#if __STDC_VERSION__ >= 199901L

#include <stdint.h>

#else

#include <limits.h>

#ifdef LLONG_MAX
typedef long long intmax_t;
typedef unsigned long long uintmax_t;
#define INTMAX_MIN LLONG_MIN
#define INTMAX_MAX LLONG_MAX
#define UINTMAX_MAX ULLONG_MAX
#elif defined(_I64_MAX)
typedef __int64 intmax_t;
typedef __uint64 uintmax_t;
#define INTMAX_MIN _I64_MIN
#define INTMAX_MAX _I64_MAX
#define UINTMAX_MAX _UI64_MAX
#else
typedef long intmax_t;
typedef unsigned long uintmax_t;
#define INTMAX_MIN LONG_MIN
#define INTMAX_MAX LONG_MAX
#define UINTMAX_MAX ULONG_MAX
#endif

#endif

or something similar for an implementation specific [u]intmax_t type
somewhat portably defined. There are several ways to do the next part
but here is one simple way is to create another implementation specific
header file:

#if __STDC_VERSION__ >= 199901L

#include <inttypes.h>

#else

#ifdef LLONG_MAX
#define PRIiMAX "%lli"
#define PRIuMAX "%llu"
#elif defined(_I64_MAX)
#define PRIiMAX "%I64i"
#define PRIuMAX "%I64u"
#else
#define PRIiMAX "%li"
#define PRIuMAX "%lu"
#endif

#endif

And for all your printf calls do:

printf("Total size: " PRIuMAX " bytes\n", (uintmax_t)size);

Another simple way is to create printf specifier for size_t similar to
the above using another implementation specific header that you have to
keep in sync with: "%z" for C99, "%Iu" for visual studio's runtime,
etc. or however you want to go about doing it.

Nov 14 '05 #6

P: n/a
On Sun, 12 Jun 2005 08:07:07 +0200, Joakim Hove
<ho**@ift.uib.no> wrote:
I have code which makses use of variables of type size_t. The code is
originally developed on a 32 bit machine, but now it is run on both a
32 bit and a 64 bit machine.

In the code have statements like this:

size_t buffer_size;
printf("Total buffer size: %ud bytes \n",buffer_size);
That is undefined, because %u expects an int. Quite why you want to
print a 'd' after the number I don't know, but it's your choice...
Now the format "%ud" works nicely on the 32 bit computer; it actually
works on the 64 bit computer as well, but the compiler spits out
warning message. On the 64 bit computer it would have prefered:

printf("Total buffer size: %uld bytes \n",buffer_size); /* Or udl? */
You probably mean %lu -- but it's still undefined behaviour because
size_t is not the same as an unsigned long except by accident (well,
implementers' choice, but something over which you have no control and
the next version of the compiler could change it).
As I said it works, but I would really prefer the program to compile
without warnings, as it is now I get *many* warnings of the type

file.c:line: warning: unsigned int format, different type arg (arg 1).
Heed them. Your code is incorrect. Try, for instance,

size_t buffer_size = 123;
printf("%u %d\n", buffer_size, 42);

On the 32 bit machine it may work (and give "123 42"), but on the 64 bit
machine it may give you something like "123 0" (or possibly "0 123", or
some other strange result).
And, on several occasion this has actually led me to miss more
important warnings.


So correct the printf code.

If your library is C99 compliant you can use the z conversion specifier
for size_t:

printf("%zu\n", buffer_size);

Note that the /library/ must be compliant, not the actual compiler, and
since gcc for instance uses printf from the underlying system it may not
be supported (as I recall it was on Linux but wasn't on Solaris when I
tried it). If the compiler doesn't support it then you may still get
warnings, of course.

Alternatively, cast the size to a known and supported type. For most
purposes long is sufficient:

printf("%lu\n", (long)buffer_size);

That will get rid of the warnings (because there is no longer any
mismatch) and allow for at least 32 bit sizes even on 16 bit machines.

Chris C
Nov 14 '05 #7

P: n/a
Keith Thompson wrote:
Joakim Hove <ho**@ift.uib.no> writes:
I have code which makses use of variables of type size_t. The
code is originally developed on a 32 bit machine, but now it is
run on both a 32 bit and a 64 bit machine.

In the code have statements like this:

size_t buffer_size;
printf("Total buffer size: %ud bytes \n",buffer_size);


I think you mean "%u", not "%ud". "%d" is for (signed) int; "%u"
is for unsigned int.
Now the format "%ud" works nicely on the 32 bit computer; it
actually works on the 64 bit computer as well, but the compiler
spits out warning message. On the 64 bit computer it would have
prefered:

printf("Total buffer size: %uld bytes \n",buffer_size); /* Or udl? */


The format for unsigned long is "%lu".

In C90, the best way to print a size_t value is to convert it
to unsigned long and use "%lu":

printf("Total buffer size: %lu bytes\n", (unsigned long)buffer_size);

C99 adds a 'z' modifier specifically for size_t:

printf("Total buffer size: %zu bytes\n", buffer_size);

but many printf implementations don't support it. (Even if your
compiler supports C99 and defines __STDC_VERSION__ appropriately,
that's not, practically speaking, a guarantee that the library
also conforms to C99.)

Even in C99, the "%lu" method will work unless size_t is bigger
than unsigned long *and* the value being printed exceeds ULONG_MAX,
which is unlikely to happen in practice.


I was going to reply to the OP, but this covers it better. The
major point is that, for C89 or any lack of full printf C99
coverage in the library, you have to cast the size_t operand to
something, and you have to then make the specifier agree with that
cast. The programmer probably knows how bit his size_t object can
actually become, and so can make the decision about what to cast it
to. The safest is the largest unsigned that the library can
handle.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #8

P: n/a
Chris Croughton wrote:
Alternatively, cast the size to a known and supported type. For most
purposes long is sufficient:

printf("%lu\n", (long)buffer_size);


ITYM

printf("%lu\n", (unsigned long)buffer_size);

--
ade ishs

Nov 14 '05 #9

P: n/a
Chris Croughton <ch***@keristor.net> writes:
On Sun, 12 Jun 2005 08:07:07 +0200, Joakim Hove
<ho**@ift.uib.no> wrote:
I have code which makses use of variables of type size_t. The code is
originally developed on a 32 bit machine, but now it is run on both a
32 bit and a 64 bit machine.

In the code have statements like this:

size_t buffer_size;
printf("Total buffer size: %ud bytes \n",buffer_size);


That is undefined, because %u expects an int. Quite why you want to
print a 'd' after the number I don't know, but it's your choice...

[...]

I think it's only potentially undefined. If size_t happens to be
unsigned int for a given implementation, it's well defined. If you
use a "%u" format, the implementation doesn't care whether you
actually know that the argument is an unsigned int, or you just got
lucky.

It is, of course, unnecessarily non-portable.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #10

P: n/a
On Sun, 12 Jun 2005 15:57:46 +0000, Keith Thompson wrote:
Chris Croughton <ch***@keristor.net> writes:
On Sun, 12 Jun 2005 08:07:07 +0200, Joakim Hove
<ho**@ift.uib.no> wrote:
I have code which makses use of variables of type size_t. The code is
originally developed on a 32 bit machine, but now it is run on both a
32 bit and a 64 bit machine.

In the code have statements like this:

size_t buffer_size;
printf("Total buffer size: %ud bytes \n",buffer_size);
That is undefined, because %u expects an int. Quite why you want to
print a 'd' after the number I don't know, but it's your choice...

[...]

I think it's only potentially undefined.


In the context of comp.lang.c that makes it undefined.
If size_t happens to be
unsigned int for a given implementation, it's well defined.
But without the context of of the specific inplementation it is undefined.
If you
use a "%u" format, the implementation doesn't care whether you
actually know that the argument is an unsigned int, or you just got
lucky.


Undefined doesn't mean that it won't do what you wanted on some
implementation.

Lawrence
Nov 14 '05 #11

P: n/a
Lawrence Kirby <lk****@netactive.co.uk> writes:
On Sun, 12 Jun 2005 15:57:46 +0000, Keith Thompson wrote:
Chris Croughton <ch***@keristor.net> writes:
On Sun, 12 Jun 2005 08:07:07 +0200, Joakim Hove
<ho**@ift.uib.no> wrote:

I have code which makses use of variables of type size_t. The code is
originally developed on a 32 bit machine, but now it is run on both a
32 bit and a 64 bit machine.

In the code have statements like this:

size_t buffer_size;
printf("Total buffer size: %ud bytes \n",buffer_size);

That is undefined, because %u expects an int. Quite why you want to
print a 'd' after the number I don't know, but it's your choice...

[...]

I think it's only potentially undefined.


In the context of comp.lang.c that makes it undefined.


The term "undefined behavior" is defined by the standard, not by the
newsgroup.
If size_t happens to be
unsigned int for a given implementation, it's well defined.


But without the context of of the specific inplementation it is undefined.


Without the context of the specific inplementation, we don't know
whether it's undefined or not.
If you
use a "%u" format, the implementation doesn't care whether you
actually know that the argument is an unsigned int, or you just got
lucky.


Undefined doesn't mean that it won't do what you wanted on some
implementation.


Nor does it merely mean non-portable.

If I declare x as an object of type unsigned int, and initialize it
with some valid value, then the following:

printf("x = %u\n", x);

is well defined. If I instead declare it with a typedef name that
happens to be an alias for unsigned int, it's still well defined. If
the typedef name happens to be size_t, that doesn't make it undefined
-- as long as size_t is an alias for unsigned int. A statement that
assumes size_t is unsigned int is non-portable, and cannot appear in a
strictly conforming program, and it invokes undefined behavior on a
platform where size_t is not unsigned int.

Similarly, the following:

int i = 32767;
i ++;

is non-portable, but it invokes undefined behavior *only* on an
implementation with INT_MAX == 32767; it's perfectly well defined on
any implementation with INT_MAX > 32767.

"Undefined behavior" is a useful concept. We need to be careful not
to weaken it until it merely means "bad code".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #12

P: n/a
Keith Thompson wrote:

Lawrence Kirby <lk****@netactive.co.uk> writes:
On Sun, 12 Jun 2005 15:57:46 +0000, Keith Thompson wrote:
I think it's only potentially undefined.


In the context of comp.lang.c that makes it undefined.


The term "undefined behavior" is defined by the standard, not by the
newsgroup.


Potentially undefined matches the meaning of undefined by the standard.

A program that prints the value of CHAR_BIT has implementation
defined behavior.

A program that only crashes when CHAR_BIT equals eight,
is different from a program with implementation defined behavior.

--
pete
Nov 14 '05 #13

P: n/a
pete <pf*****@mindspring.com> writes:
Keith Thompson wrote:

Lawrence Kirby <lk****@netactive.co.uk> writes:
> On Sun, 12 Jun 2005 15:57:46 +0000, Keith Thompson wrote: >> I think it's only potentially undefined.
>
> In the context of comp.lang.c that makes it undefined.


The term "undefined behavior" is defined by the standard, not by the
newsgroup.


Potentially undefined matches the meaning of undefined by the standard.

A program that prints the value of CHAR_BIT has implementation
defined behavior.

A program that only crashes when CHAR_BIT equals eight,
is different from a program with implementation defined behavior.


The context was something like this:

size_t s = 42;
printf("s = %u\n", s);

The standard defines "undefined behavior" as "behavior, upon use of a
nonportable or erroneous program construct or of erroneous data, for
which this International Standard imposes no requirements".

The standard does impose requirements on the behavior of the above
code; it requires it to print the string "42", followed by a newline,
if size_t is a typedef for unsigned int.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #14

P: n/a
Keith Thompson wrote:
The context was something like this:

size_t s = 42;
printf("s = %u\n", s);

The standard defines "undefined behavior" as "behavior, upon use of a
nonportable or erroneous program construct or of erroneous data, for
which this International Standard imposes no requirements".

The standard does impose requirements on the behavior of the above
code; it requires it to print the string "42", followed by a newline,
if size_t is a typedef for unsigned int.


You don't know if size_t is a typedef for unsigned int.
So, you don't really know what it does, do you?
The code is either defined or undefined when you write it,
not when you finally match it up to a machine
where it does what you want.

--
pete
Nov 14 '05 #15

P: n/a
pete <pf*****@mindspring.com> writes:
Keith Thompson wrote:
The context was something like this:

size_t s = 42;
printf("s = %u\n", s);

The standard defines "undefined behavior" as "behavior, upon use of a
nonportable or erroneous program construct or of erroneous data, for
which this International Standard imposes no requirements".

The standard does impose requirements on the behavior of the above
code; it requires it to print the string "42", followed by a newline,
if size_t is a typedef for unsigned int.
You don't know if size_t is a typedef for unsigned int.


Maybe I do, maybe I don't.
So, you don't really know what it does, do you?
I know exactly what it does *if* I run it on an implementation where
size_t is unsigned int.
The code is either defined or undefined when you write it,
not when you finally match it up to a machine
where it does what you want.


The standard talks about undefined behavior, not undefined code. The
undefined behavior, at least in this case, occurs at run time, not
when I'm entering the code in my text editor. If I don't run the code
on a system where size_t is not unsigned int, there is no behavior,
and therefore there is no undefined behavior.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #16

P: n/a
Keith Thompson wrote:

pete <pf*****@mindspring.com> writes:
Keith Thompson wrote:
The context was something like this:

size_t s = 42;
printf("s = %u\n", s);

The standard defines "undefined behavior" as "behavior, upon use of a
nonportable or erroneous program construct or of erroneous data, for
which this International Standard imposes no requirements".

The standard does impose requirements on the behavior of the above
code; it requires it to print the string "42", followed by a newline,
if size_t is a typedef for unsigned int.
You don't know if size_t is a typedef for unsigned int.


Maybe I do, maybe I don't.
So, you don't really know what it does, do you?


I know exactly what it does *if* I run it on an implementation where
size_t is unsigned int.
The code is either defined or undefined when you write it,
not when you finally match it up to a machine
where it does what you want.


The standard talks about undefined behavior, not undefined code.


Code contains behavior.
The standard catagorizes "correct programs"
according to the behavior that they contain.
The
undefined behavior, at least in this case, occurs at run time, not
when I'm entering the code in my text editor. If I don't run the code
on a system where size_t is not unsigned int, there is no behavior,
and therefore there is no undefined behavior.


If you refuse to ever run the code,
does it become a strictly conforming program?

ISO/IEC 9899:1999
4. Conformance
5
A strictly conforming program shall use only those features of the
language and library specified in this International Standard.
It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.

--
pete
Nov 14 '05 #17

P: n/a
In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:
If you refuse to ever run the code,
does it become a strictly conforming program?


A more interesting question (I think, anyway): if the code refuses
to run itself, does it become strictly conforming?

#include <stdio.h>

void print_a_size_t(size_t val) {
if (sizeof val == sizeof(unsigned))
printf("%u", val);
else if (sizeof val == sizeof(unsigned long))
printf("%lu", val);
else
printf("<can't print size>");
}

int main(void) {
printf("sizeof(int) = ");
print_a_size_t(sizeof(int));
printf("\n");
return 0;
}

I believe the comp.std.c gnomes have already said that a program
that changes its output based on compile-time conditions (like
time-of-compile as stored in __DATE__, or printing the value of
INT_MAX, or whatever) remains strictly conforming, even though the
output changes from machine to machine or compile-time to compile-time.
If so, is the above also strictly conforming? (If simply printing
out INT_MAX renders the program not-strictly-conforming, I withdraw
my question. :-) )
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #18

P: n/a
On Tue, 14 Jun 2005 02:17:07 +0000, Chris Torek wrote:
In article <42***********@mindspring.com>
pete <pf*****@mindspring.com> wrote:
If you refuse to ever run the code,
does it become a strictly conforming program?
A more interesting question (I think, anyway): if the code refuses
to run itself, does it become strictly conforming?


If a program cannot execute code that resunts in undefined behaviour it
can be strictly conforming, e.g.

if (0) 1/0;

can appear in a strictly conforming program.
#include <stdio.h>

void print_a_size_t(size_t val) {
if (sizeof val == sizeof(unsigned))
The size of an type is not enough to uniquely identify that type, so
printf("%u", val);
this could still produce undefined behaviour. Think of an implementation
where sizelf(unsigned)==sizeof(unsigned long) but unsigned has a
smaller range, padding bits and trap representations.
else if (sizeof val == sizeof(unsigned long))
printf("%lu", val);
else
printf("<can't print size>"); }
}
int main(void) {
printf("sizeof(int) = ");
print_a_size_t(sizeof(int));
printf("\n");
return 0;
}
}
I believe the comp.std.c gnomes have already said that a program that
changes its output based on compile-time conditions (like
time-of-compile as stored in __DATE__, or printing the value of INT_MAX,
or whatever) remains strictly conforming, even though the output changes
from machine to machine or compile-time to compile-time.


Agreed, strict conformance is NOT about the output being identical across
implementations. However 5.2.4.2.1 does explicitly label the values of
INT_MAX etc. as implementation-defined which means that (a) the
implementation has to document them and (b) a strictly conforming program
cannot generate output dependent on them.

OTOH the return values of, for example, time() or rand() are not specified
as implementation-defined and a strictly conforming program can produce
output based on those.

Lawrence
Nov 14 '05 #19

P: n/a
Lawrence Kirby wrote:
OTOH the return values of, for example,
time() or rand() are not specified
as implementation-defined
and a strictly conforming program can produce
output based on those.


That sounds more like a correct program
or like a conforming program to me,
than like a strictly conforming program.

ISO/IEC ISO/IEC 9899:1999

4. Conformance
3 A program that is correct in all other aspects,
operating on correct data, containing
unspecified behavior shall be a correct program and
act in accordance with 5.1.2.3.

5 A strictly conforming program shall use only those features
of the language and library specified in this International
Standard. It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.
4)
Conforming programs may depend upon nonportable
features of a conforming implementation.

--
pete
Nov 14 '05 #20

P: n/a
On Tue, 14 Jun 2005 16:13:47 +0000, pete wrote:
Lawrence Kirby wrote:
OTOH the return values of, for example,
time() or rand() are not specified
as implementation-defined
and a strictly conforming program can produce
output based on those.


That sounds more like a correct program
or like a conforming program to me,
than like a strictly conforming program.

ISO/IEC ISO/IEC 9899:1999

4. Conformance
3 A program that is correct in all other aspects,
operating on correct data, containing
unspecified behavior shall be a correct program and
act in accordance with 5.1.2.3.

5 A strictly conforming program shall use only those features
of the language and library specified in this International
Standard. It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.
4)
Conforming programs may depend upon nonportable
features of a conforming implementation.


There is no requirement in para 5 that using rand() or time() would
violate. Note specifically that their return values are not
implementation-defined, unspecified or undefined.

Lawrence

Nov 14 '05 #21

P: n/a
Lawrence Kirby wrote:

On Tue, 14 Jun 2005 16:13:47 +0000, pete wrote:
Lawrence Kirby wrote:
OTOH the return values of, for example,
time() or rand() are not specified
as implementation-defined
and a strictly conforming program can produce
output based on those.


That sounds more like a correct program
or like a conforming program to me,
than like a strictly conforming program.

ISO/IEC ISO/IEC 9899:1999

4. Conformance
3 A program that is correct in all other aspects,
operating on correct data, containing
unspecified behavior shall be a correct program and
act in accordance with 5.1.2.3.

5 A strictly conforming program shall use only those features
of the language and library specified in this International
Standard. It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.
4)
Conforming programs may depend upon nonportable
features of a conforming implementation.


There is no requirement in para 5 that using rand() or time() would
violate. Note specifically that their return values are not
implementation-defined, unspecified or undefined.


Neither are they defined by the C standard.

The return value of rand seems to me to match the description
of unspecified behavior.

C99
3.4.4
1 unspecified behavior
behavior where this International Standard provides
two or more possibilities and imposes no further
requirements on which is chosen in any instance

The two or more possibilities being the return of
any int value from zero to RAND_MAX.

Does behavior need to be labeled "unspecified" in the standard
in order to be recognized as such?

--
pete
Nov 14 '05 #22

P: n/a
On Wed, 15 Jun 2005 17:16:24 +0000, pete wrote:

....
The return value of rand seems to me to match the description
of unspecified behavior.

C99
3.4.4
1 unspecified behavior
behavior where this International Standard provides
two or more possibilities and imposes no further
requirements on which is chosen in any instance

The two or more possibilities being the return of
any int value from zero to RAND_MAX.
However those still fall under the single specification of a
"pseudo-randon integer". Many library function are allowed to return a
success value or a failure code. This doesnt make them unspecified.
Does behavior need to be labeled "unspecified" in the standard
in order to be recognized as such?


Yes. Clause 3 defined "Terms, Definitions and Symbols" used in the
standard. The paragraph above specifies the meaning of the term
unspecified behaviour when it appears in the standard, not conditions
where unspecified behaviour can be inferred. That is also true for the
definitions of implementation-defined behaviour and undefined behaviour
that appear in clause 3. C90 had some specification of when undefined
behaviour occurs in clause 3. Since clause 3 is about definitions of terms
this has been correctly moved to clause 4 in C99.

Annex J lists the cases of Unspecified, Implementation-defined and
undefined behaviour in the standard. While this annex is not normative I
believe it is intended to be exhaustive.

Lawrence
Nov 14 '05 #23

P: n/a
Lawrence Kirby wrote:

On Wed, 15 Jun 2005 17:16:24 +0000, pete wrote:

...
The return value of rand seems to me to match the description
of unspecified behavior.

C99
3.4.4
1 unspecified behavior
behavior where this International Standard provides
two or more possibilities and imposes no further
requirements on which is chosen in any instance

The two or more possibilities being the return of
any int value from zero to RAND_MAX.


However those still fall under the single specification of a
"pseudo-randon integer". Many library function are allowed to return a
success value or a failure code. This doesnt make them unspecified.
Does behavior need to be labeled "unspecified" in the standard
in order to be recognized as such?


Yes. Clause 3 defined "Terms, Definitions and Symbols" used in the
standard. The paragraph above specifies the meaning of the term
unspecified behaviour when it appears in the standard, not conditions
where unspecified behaviour can be inferred. That is also true for the
definitions of implementation-defined behaviour and undefined
behaviour
that appear in clause 3. C90 had some specification of when undefined
behaviour occurs in clause 3.
Since clause 3 is about definitions of terms
this has been correctly moved to clause 4 in C99.

Annex J lists the cases of Unspecified, Implementation-defined and
undefined behaviour in the standard.
While this annex is not normative I
believe it is intended to be exhaustive.


Thank you.

--
pete
Nov 14 '05 #24

P: n/a
Lawrence Kirby <lk****@netactive.co.uk> writes:
On Wed, 15 Jun 2005 17:16:24 +0000, pete wrote:

...
The return value of rand seems to me to match the description
of unspecified behavior.

C99
3.4.4
1 unspecified behavior
behavior where this International Standard provides
two or more possibilities and imposes no further
requirements on which is chosen in any instance

The two or more possibilities being the return of
any int value from zero to RAND_MAX.


However those still fall under the single specification of a
"pseudo-randon integer". Many library function are allowed to return a
success value or a failure code. This doesnt make them unspecified.
Does behavior need to be labeled "unspecified" in the standard
in order to be recognized as such?


Yes. Clause 3 defined "Terms, Definitions and Symbols" used in the
standard. The paragraph above specifies the meaning of the term
unspecified behaviour when it appears in the standard, not conditions
where unspecified behaviour can be inferred. That is also true for the
definitions of implementation-defined behaviour and undefined behaviour
that appear in clause 3. C90 had some specification of when undefined
behaviour occurs in clause 3. Since clause 3 is about definitions of terms
this has been correctly moved to clause 4 in C99.

Annex J lists the cases of Unspecified, Implementation-defined and
undefined behaviour in the standard. While this annex is not normative I
believe it is intended to be exhaustive.


I've seen a number of cases in this newsgroup where a construct
invokes undefined behavior because the standard doesn't define its
behavior, not because it explicitly states that it invokes undefined
behavior. This is consistent with the standard's definition of the
term "undefined behavior"; it doesn't require it to be mentioned
explicitly. (Sorry, no examples spring to mind.) I wouldn't be
surprised to see the same kind of thing for unspecified behavior.

I don't have my copy of the standard handy; I'll look at the wording
more carefully later.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #25

P: n/a
On Thu, 16 Jun 2005 19:46:17 +0000, Keith Thompson wrote:

....
Yes. Clause 3 defined "Terms, Definitions and Symbols" used in the
standard. The paragraph above specifies the meaning of the term
unspecified behaviour when it appears in the standard, not conditions
where unspecified behaviour can be inferred. That is also true for the
definitions of implementation-defined behaviour and undefined behaviour
********** that appear in clause 3. C90 had some specification of when undefined
behaviour occurs in clause 3. Since clause 3 is about definitions of terms
this has been correctly moved to clause 4 in C99. **********
Annex J lists the cases of Unspecified, Implementation-defined and
undefined behaviour in the standard. While this annex is not normative I
believe it is intended to be exhaustive.
I've seen a number of cases in this newsgroup where a construct
invokes undefined behavior because the standard doesn't define its
behavior, not because it explicitly states that it invokes undefined
behavior.


Note the part of my previous response I highlight above. This happens for
undefined behaviour because the standard explicitly states that it does,
in the part I referred to. The wording (now moved to clause 4p2) is:

"If a ''shall'' or ''shall not'' requirement that appears
outside of a constraint is violated, the behavior is undefined. Undefined
behavior is otherwise indicated in this International Standard by the
words ''undefined behavior'' or by the omission of any explicit
definition of behavior. There is no difference in emphasis among these
three; they all describe ''behavior that is undefined''."

This is what defines WHEN undefined behaviour occurs, rather than defining
what the term means when it appears in the standard, which is what clause
3 does. Note specifically the "or by the omission of any explicit
definition of behavior". The standard contains no similar wording for
unspecified or implementation-defined behaviour. They only occur when
the standard explicitly says so.
This is consistent with the standard's definition of the
term "undefined behavior"; it doesn't require it to be mentioned
explicitly. (Sorry, no examples spring to mind.) I wouldn't be
surprised to see the same kind of thing for unspecified behavior.


However that is not how the standard works.

Lawrence
Nov 14 '05 #26

This discussion thread is closed

Replies have been disabled for this discussion.