Request

[jacob navia]

As a consequence of a heavy discussion in another thread,
I wrote this program:
#include <stdlib.h>
int main(void)
{
char *p=calloc(65521 ,65552);
if (p)
printf("BUG!!!! \n");
}

The multiplication will give an erroneus result
in 32 bit size_t systems. I have tested this
in several systems with several compilers.

Maybe people with other compilers/implementations
would compile this program and send the results?

The results I have so far are:

LINUX
GCC 2.95
HAS THE BUG

GCC-4.02
NO BUGS

GCC-3.x
NO BUGS

WINDOWS
cygwin gcc 3.4.4
NO bugs
pelles c:
HAS THE BUG
Microsoft
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42
for 80x86
NO BUGS (If the multiplication overflows it will trap. Very good
behavior)

AIX
IBM-cc (compiling in 32 bit mode)
NO BUGS
gcc 4.0.0 (compiling in 32 bit mode)
NO BUGS
Thanks in advance for your cooperation

[Ben Pfaff]

jacob navia <ja***@jacob.re mcomp.frwrites:

LINUX
GCC 2.95
HAS THE BUG

GCC is not a complete C implementation. In particular, it lacks
a C library. Thus, it doesn't make sense to say that GCC 2.95
has a bug in its calloc function. In fact, when I run your test
program here, using GCC 2.95.4 on top of a Linux kernel, I don't
see the bug you claim to be present. This probably means that we
are using different C libraries.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Walter Roberson]

In article <45************ ***********@new s.orange.fr>,
jacob navia <ja***@jacob.re mcomp.frwrote:

>As a consequence of a heavy discussion in another thread,
I wrote this program:
#include <stdlib.h>
int main(void)
{
char *p=calloc(65521 ,65552);
if (p)
printf("BUG!!!! \n");
}

You appear to be missing a prototype for printf(), and you
appear to be relying on C99 behaviour upon running off the
end of main().

>The multiplication will give an erroneus result
in 32 bit size_t systems.

That may or may not be the case, but that isn't what you
are testing.

Your program would claim as a BUG any system
on which size_t was able to accomedate 65521 * 65552 and was
able to allocate that much memory.

The ability to allocate that much memory may depend upon the memory and
swap space installed in the system, and may depend upon any resource
usage limitations that have been put in place. Some of those limits
may be "soft" limits that can be removed with a simple command or two;
some of the limits might be "hard" limits imposed by the systems
administrator on systems that would have otherwise have sufficient
resources.

>I have tested this
in several systems with several compilers.

>Maybe people with other compilers/implementations
would compile this program and send the results?

SGI IRIX MipsPro 7.3.1.2:
With -o32 or -n32, size_t is 32 and
the implementation does not allocate the memory. With -64,
size_t is 64 and the particular system I'm running on
has enough resources that the system is able to allocate the
full extent of the memory.

According to your program, that means that the above compiler both
has and does not have the bug (it's the same compiler in all
the cases.)

If I were me, I would conclude that your methodology is flawed.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer

[jacob navia]

Walter Roberson a écrit :

In article <45************ ***********@new s.orange.fr>,

You appear to be missing a prototype for printf(), and you
appear to be relying on C99 behaviour upon running off the
end of main().

Yes, add them at will.

>

>>The multiplication will give an erroneus result
in 32 bit size_t systems.

That may or may not be the case, but that isn't what you
are testing.

Your program would claim as a BUG any system
on which size_t was able to accomedate 65521 * 65552 and was
able to allocate that much memory.

With a 32 bit size_t as I said, it would be interesting that
the system allocates a size_t of 33 bits...

I may be missing something... BUT!!!

The ability to allocate that much memory may depend upon the memory and
swap space installed in the system, and may depend upon any resource
usage limitations that have been put in place. Some of those limits
may be "soft" limits that can be removed with a simple command or two;
some of the limits might be "hard" limits imposed by the systems
administrator on systems that would have otherwise have sufficient
resources.

No, this is impossible in 32 bit size_t systems!!!

SGI IRIX MipsPro 7.3.1.2:
With -o32 or -n32, size_t is 32 and
the implementation does not allocate the memory.

Fine We can add that SGI IRIX has NOT the bug.

Thanks

With -64,
size_t is 64 and the particular system I'm running on
has enough resources that the system is able to allocate the
full extent of the memory.

Excuse me but you haven't a 32 bit size_t but a 64 bit
size_t when compiling in 64 bit mode. If you care to see my table
I compiled explicitely in 32 bit mode in AIX systems!!!

According to your program, that means that the above compiler both
has and does not have the bug (it's the same compiler in all
the cases.)

It is not the same size_t!!!

I said:
32 bit size_t!!!

If I were me, I would conclude that your methodology is flawed.

I am glad that you are you and I am me

:-)

What would happen If i were you? I would try to read
what I am writi,ng and not trying to find inexistent
bugs

Thanks for your input in any case Walter.

[Walter Roberson]

In article <45************ **********@news .orange.fr>,
jacob navia <ja***@jacob.re mcomp.frwrote:

>Walter Roberson a écrit :

>>>The multiplication will give an erroneus result
in 32 bit size_t systems.

>That may or may not be the case, but that isn't what you
are testing.

>Your program would claim as a BUG any system
on which size_t was able to accomedate 65521 * 65552 and was
able to allocate that much memory.

>With a 32 bit size_t as I said, it would be interesting that
the system allocates a size_t of 33 bits...

>I may be missing something... BUT!!!

You *are* missing something. What you wrote was that,

"The multiplication will give an erroneus result in 32 bit size_t systems."

You did NOT, however, restrict the testing to systems with size_t
of 32 bits: you merely made an assertion about what would happen
on systems on which size_t is 32 bits. The proof is in the code,
and your code declares as a bug any system and option and
environment combination which is able to allocate the required amount
of memory.

If you care to see my table
I compiled explicitely in 32 bit mode in AIX systems!!!

Irrelevant, since you did not restrict the scope of the test
to 32 bit mode.
--
"law -- it's a commodity"
-- Andrew Ryan (The Globe and Mail, 2005/11/26)

[user923005]

jacob navia wrote:

No, this is impossible in 32 bit size_t systems!!!

Why? The calloc() call has two parameters. There is no reason that
the total allocation cannot exceed the value of a size_t.

BTW, there are definitely 32 bit systems that will allocate memory in
excess of 32 bits. For example:
http://support.microsoft.com/kb/274750

>From this, I do not see any restriction that the allocation must fail

if nmemb*size SIZE_MAX:
"7.20.3.1 The calloc function
Synopsis
1 #include <stdlib.h>
void *calloc(size_t nmemb, size_t size);
Description
2 The calloc function allocates space for an array of nmemb objects,
each of whose size
is size. The space is initialized to all bits zero.252)
Returns
3 The calloc function returns either a null pointer or a pointer to the
allocated space."

[Spiros Bousbouras]

jacob navia wrote:

As a consequence of a heavy discussion in another thread,
I wrote this program:
#include <stdlib.h>
int main(void)
{
char *p=calloc(65521 ,65552);
if (p)
printf("BUG!!!! \n");
}

What bug are you claiming exists ? If you're
saying that only 65296 bytes have been allocated
how do you know ?

The multiplication will give an erroneus result
in 32 bit size_t systems. I have tested this
in several systems with several compilers.

How do you know what the calloc implementation does
upon receiving the arguments 65521 and 65552 ? It is
reasonable to assume that it multiplies them but how
do you know that the result of the multiplication is limited
to 32 bits ? I don't see what relevance the width of size_t
has.

Maybe people with other compilers/implementations
would compile this program and send the results?

I can't be bothered to be honest because I don't see the
point. As far as I can see , even if calloc returns a non NULL
pointer you can't know how much memory has been allocated
unless you have seen the code of the calloc implementation.
Note that even if you know for sure that the system cannot
allocate 65521*65552 bytes and calloc returns non NULL you
still cannot be sure that it is calloc which has the bug. It may
be that calloc uses some platform specific system call to get
the memory and it is the system call which has the bug.

RESULTS OF TEST SNIPPED

[jacob navia]

Walter Roberson a écrit :

>
You *are* missing something. What you wrote was that,

"The multiplication will give an erroneus result in 32 bit size_t systems."

You did NOT, however, restrict the testing to systems with size_t
of 32 bits

I thought that that restriction would be evident from the restriction
of size_t to 32 bits.

OK This is a misunderstandin g then. The test is intended only
for 32 bit systems

Updated version:

#include <stdlib.h>
#include <limits.h>
#include <stdio.h// for printf
int main(void)
{
int s = sizeof(size_t)* CHAR_BIT;
if (s == 32 && NULL != calloc(65521,65 552))
printf("BUG!!!! \n");
return 0; // For C89 compilers
}

[Jens Thoms Toerring]

jacob navia <ja***@jacob.re mcomp.frwrote:

As a consequence of a heavy discussion in another thread,
I wrote this program:
#include <stdlib.h>
int main(void)
{
char *p=calloc(65521 ,65552);
if (p)
printf("BUG!!!! \n");
}

The multiplication will give an erroneus result
in 32 bit size_t systems.

I think that assuming that a 32 bit multiplication is the sole
reason is a bit premature. At least I don't see convincing evi-
dence of that.

I have tested this
in several systems with several compilers.

Maybe people with other compilers/implementations
would compile this program and send the results?

The results I have so far are:

LINUX
GCC 2.95
HAS THE BUG

GCC-4.02
NO BUGS

GCC-3.x
NO BUGS

I have 3.3.1 and get the opposite result (with no overcommitment
enabled). Things get even more interesting if I try to print out
the pointers value (of course after including <stdio.h>;-): While
the test of p tells that it's not zero ("BUG!!!!" isn't printed)
a line like

printf( "%p\n", ( void * ) p );

gives me "(nil)", the same result as if I had a NULL pointer. And,
if, on top of it, I try to assign a value to the memory (even the
very first byte of it) then a segmentation fault is the result.

I guess that indicates that a bit more than a simple unsigned 32
bit multiplication that overflows and isn't detected in time is
going on behind the scenes...
Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\______________ ____________ http://toerring.de

[Spiros Bousbouras]

jacob navia wrote:

Walter Roberson a écrit :

You *are* missing something. What you wrote was that,

"The multiplication will give an erroneus result in 32 bit size_t systems."

You did NOT, however, restrict the testing to systems with size_t
of 32 bits

I thought that that restriction would be evident from the restriction
of size_t to 32 bits.

OK This is a misunderstandin g then. The test is intended only
for 32 bit systems

What do you mean by 32 bit system ? One that cannot
address more than 32 bits of physical memory ? What
if the system is connected to a hard disk which has more
than 2**32 bytes of space. Surely then it would be possible
to somehow address the whole of it even if it meant using
special libraries to do arithmetic on more than 32 bits.

Updated version:

#include <stdlib.h>
#include <limits.h>
#include <stdio.h// for printf
int main(void)
{
int s = sizeof(size_t)* CHAR_BIT;
if (s == 32 && NULL != calloc(65521,65 552))
printf("BUG!!!! \n");
return 0; // For C89 compilers
}