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

Request

P: n/a
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

Jan 2 '07 #1
Share this Question
Share on Google+
149 Replies


P: n/a
jacob navia <ja***@jacob.remcomp.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
Jan 2 '07 #2

P: n/a
In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.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
Jan 2 '07 #3

P: n/a
Walter Roberson a écrit :
In article <45***********************@news.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.

Jan 3 '07 #4

P: n/a
In article <45**********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.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)
Jan 3 '07 #5

P: n/a
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."

Jan 3 '07 #6

P: n/a
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
Jan 3 '07 #7

P: n/a
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 misunderstanding 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,65552))
printf("BUG!!!!\n");
return 0; // For C89 compilers
}
Jan 3 '07 #8

P: n/a
jacob navia <ja***@jacob.remcomp.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 ___ jt@toerring.de
\__________________________ http://toerring.de
Jan 3 '07 #9

P: n/a
Jens Thoms Toerring wrote:
jacob navia <ja***@jacob.remcomp.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)
You got it backwards , if "BUG" isn't printed then it is
a NULL pointer.
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.
Not surprising since you try dereferencing a NULL pointer.

Jan 3 '07 #10

P: n/a
user923005 a écrit :
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
This is irrelevant. Those links refer as to how
to use certain flags in the boot.ini to allow
*3GB* if user space. (!!!!!!!)

And 3GB is well below a 32 bit size_t.

With a 32 bit size_t and pointer size how can you
address more than 4GB?

But this is a well known tactic.

Since I present the code, I do the effort of making all those
measurements, it is so easy to just sit by and say

"A system with 32 bit size_t could allocate more than 4GB
memory. A system like that COULD exist."

So WHAT?

Can you please tell me where that system is????

If not, just do not participate. Thanks for your
correction. A system where this test gives a false
positive COULD exist. It is conceivable.
Jan 3 '07 #11

P: n/a
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 misunderstanding 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,65552))
printf("BUG!!!!\n");
return 0; // For C89 compilers
}
Jan 3 '07 #12

P: n/a
Spiros Bousbouras a écrit :
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 misunderstanding 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 ?
where sizeof(void *) == sizeof(size_t) == 4 and CHAR_BIT is 8

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.
File pointers use 64 bit integers this days when it is
impossible to buy a hard disk of 32 GB only :-)

This makes the system not 64 bits!
Jan 3 '07 #13

P: n/a
Jens Thoms Toerring a écrit :
[snip]

Please see the answer of Mr Spiros Bousburas in this same thread
and try to understand what I want before jumping to conclusions.

Thanks

P.S. if you do not want to participate it is OK but please do not
send noise.
Jan 3 '07 #14

P: n/a
Spiros Bousbouras <sp****@gmail.comwrote:
Jens Thoms Toerring wrote:
jacob navia <ja***@jacob.remcomp.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)
You got it backwards , if "BUG" isn't printed then it is
a NULL pointer.
Grrr;-) Right you are - I played around with it too much (with
disruptions by my cat), loosing track of what I had been trying
out. Time to go to bed...
Regards, Jens
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
Jan 3 '07 #15

P: n/a
Spiros Bousbouras a écrit :
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 ?
if size_t is 32 bits, it would be highly surprising that
an allocator returns an object of size 33 bits at least.

You are just saying here that such a system *could* exist.
This doesn't make it any more real.

OK. In those hypothetical systems my test would fail.
>
>>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.
because if an object of size 4GB could exist, sizeof
(that returns a size_t) would not work.
>
>>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.
You can't be bothered to be honest?

I hope you mean

To be honest, I can't be bothered...

:-)

BUG!!!!
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.
Excuse me but what calloc does is not measured. I just
test the result. If it is the system's fault or whatever
this is not relevant.

Jan 3 '07 #16

P: n/a
jacob navia wrote:
user923005 a écrit :
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

This is irrelevant. Those links refer as to how
to use certain flags in the boot.ini to allow
*3GB* if user space. (!!!!!!!)

And 3GB is well below a 32 bit size_t.

With a 32 bit size_t and pointer size how can you
address more than 4GB?

But this is a well known tactic.
A tactic to achieve what ?
>
Since I present the code, I do the effort of making all those
measurements, it is so easy to just sit by and say

"A system with 32 bit size_t could allocate more than 4GB
memory. A system like that COULD exist."

So WHAT?
I don't know "so WHAT". You see the problem here is
that you have not explained what your point is. In
addition to making the effort (actually not that much
effort it seems to me) of making the measurements, it
would have been very nice if you had explained what point
the measurements are meant to illustrate/investigate.

I'll take a guess: your point is that calloc should check
whether the multiplication (if that's what it does) yields
a value so big that the system cannot possibly have that
much memory. Perhaps it should , or perhaps the programmer
should , it seems like a matter of taste to me and I won't
enter into an endless argument about it. But the main problem
as I pointed out in a previous post is that your experiments
even done on a 32 bit system (whatever that means) don't
tell us for sure what checks the calloc implementations on
those systems do. As I said you would need to check the code
of calloc to verify that.
Can you please tell me where that system is????

If not, just do not participate. Thanks for your
correction. A system where this test gives a false
positive COULD exist. It is conceivable.
You cannot set arbitrary rules about when people
cannot participate in the threads you start. If your
point in the above paragraph (see ? I have to *guess*
again what your point is because you don't spell it out)
is that people should only participate if they're going
to address your main point in the thread, then I can kind
of see this as a reasonable requirement but you need to
explain first what your point is and you haven't done that.

Jan 3 '07 #17

P: n/a
jacob navia wrote:
user923005 a écrit :
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

This is irrelevant. Those links refer as to how
to use certain flags in the boot.ini to allow
*3GB* if user space. (!!!!!!!)
That is either 8 GB user space or 32 GB, not 3 GB. I suggest you read
again -- this time with comprehension enabled... Here is a quote from
that page that you may find helpful:
"SQL Server 2000 Enterprise Edition introduces support for the use of
Microsoft Windows 2000 Address Windowing Extensions (AWE) to address
approximately 8 GB of memory for instances that run on Microsoft
Windows 2000 Advanced Server, and approximately 32 GB for instances
that run on Microsoft Windows 2000 Datacenter."

P.S.
These operating systems are 32 bits.
And 3GB is well below a 32 bit size_t.
You seem to have a bit of a comprehension problem.
With a 32 bit size_t and pointer size how can you
address more than 4GB?
There are lots of ways to do it.
But this is a well known tactic.

Since I present the code, I do the effort of making all those
measurements, it is so easy to just sit by and say

"A system with 32 bit size_t could allocate more than 4GB
memory. A system like that COULD exist."

So WHAT?
So that is all that is needed to show that your test is flawed.
Can you please tell me where that system is????
I mentioned one above that uses 32 bit addressing lines and yet can
address 32 GB or RAM. The way it does it is with memory models at the
low level. Just like back in the bad old days when MS-DOS programmers
had to model with large, medium or small memory models because of 16
bit addressing, in a similar way you can use 32 bit segments and
offsets to address (potentially) 64 GB of RAM or any other scheme you
like.
If not, just do not participate. Thanks for your
correction. A system where this test gives a false
positive COULD exist. It is conceivable.
Your test has no merit that I can imagine.
Systems that will allocate 2^64 pages of ram could return a failure
result if the user space is less than 4GB. So what have we learned
from your code? Nothing.

Jan 3 '07 #18

P: n/a
Spiros Bousbouras a écrit :
jacob navia wrote:
>>user923005 a écrit :
>>>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

This is irrelevant. Those links refer as to how
to use certain flags in the boot.ini to allow
*3GB* if user space. (!!!!!!!)

And 3GB is well below a 32 bit size_t.

With a 32 bit size_t and pointer size how can you
address more than 4GB?

But this is a well known tactic.


A tactic to achieve what ?

>>Since I present the code, I do the effort of making all those
measurements, it is so easy to just sit by and say

"A system with 32 bit size_t could allocate more than 4GB
memory. A system like that COULD exist."

So WHAT?


I don't know "so WHAT". You see the problem here is
that you have not explained what your point is. In
addition to making the effort (actually not that much
effort it seems to me) of making the measurements, it
would have been very nice if you had explained what point
the measurements are meant to illustrate/investigate.

I'll take a guess: your point is that calloc should check
whether the multiplication (if that's what it does) yields
a value so big that the system cannot possibly have that
much memory. Perhaps it should , or perhaps the programmer
should , it seems like a matter of taste to me and I won't
enter into an endless argument about it. But the main problem
as I pointed out in a previous post is that your experiments
even done on a 32 bit system (whatever that means) don't
tell us for sure what checks the calloc implementations on
those systems do. As I said you would need to check the code
of calloc to verify that.

>>Can you please tell me where that system is????

If not, just do not participate. Thanks for your
correction. A system where this test gives a false
positive COULD exist. It is conceivable.


You cannot set arbitrary rules about when people
cannot participate in the threads you start. If your
point in the above paragraph (see ? I have to *guess*
again what your point is because you don't spell it out)
is that people should only participate if they're going
to address your main point in the thread, then I can kind
of see this as a reasonable requirement but you need to
explain first what your point is and you haven't done that.
My objective is to

1) make a list of all the buggy systems that
is here in clc and everybody can see.

2) Make people aware of this bug in their implementations.
(if any)
Jan 3 '07 #19

P: n/a
P.S.
I forgot to spell out clearly the objective of this tests.

My objective is to

1) make a list of all the buggy systems that
is here in clc and everybody can see.

2) Make people aware of this bug in their implementations.
(if any)

Jan 3 '07 #20

P: n/a
jacob navia wrote:
Spiros Bousbouras a écrit :
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 misunderstanding 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 ?

where sizeof(void *) == sizeof(size_t) == 4 and CHAR_BIT is 8
Since calloc returns pointer to void I can see why
sizeof(void *) is relevant but I still don't see the
connection between sizeof(size_t) and what calloc
returns or allocates.

Jan 3 '07 #21

P: n/a
user923005 a écrit :
That is either 8 GB user space or 32 GB, not 3 GB. I suggest you read
again -- this time with comprehension enabled... Here is a quote from
that page that you may find helpful:
"SQL Server 2000 Enterprise Edition introduces support for the use of
Microsoft Windows 2000 Address Windowing Extensions (AWE) to address
approximately 8 GB of memory for instances that run on Microsoft
Windows 2000 Advanced Server, and approximately 32 GB for instances
that run on Microsoft Windows 2000 Datacenter."

P.S.
These operating systems are 32 bits.
So what?

I do not talk about SQL server!

I am talking about calloc, quite a different beast.

Maybe SQL server can allocate a lot of memory but
this is not relevant to calloc I am sure.
>>With a 32 bit size_t and pointer size how can you
address more than 4GB?


There are lots of ways to do it.
No. If you mean using segmented 32:48 bit pointers they
are no longer 32 bit!

I mentioned one above that uses 32 bit addressing lines and yet can
address 32 GB or RAM. The way it does it is with memory models at the
low level. Just like back in the bad old days when MS-DOS programmers
had to model with large, medium or small memory models because of 16
bit addressing, in a similar way you can use 32 bit segments and
offsets to address (potentially) 64 GB of RAM or any other scheme you
like.
But those aren't 32 bit pointers but 48 bit pointers.
>
>>If not, just do not participate. Thanks for your
correction. A system where this test gives a false
positive COULD exist. It is conceivable.


Your test has no merit that I can imagine.
OK
Systems that will allocate 2^64 pages of ram could return a failure
result if the user space is less than 4GB. So what have we learned
from your code? Nothing.
OK

Thanks for your input

Jan 3 '07 #22

P: n/a
In article <11*********************@v33g2000cwv.googlegroups. com>,
user923005 <dc*****@connx.comwrote:
>BTW, there are definitely 32 bit systems that will allocate memory in
excess of 32 bits. For example:
There are many 32-bit systems that allow more than 2^32 bytes of
memory to be used, but none that I know of that allow a block that big
to be accessed through calls to C standard allocation functions.
>http://support.microsoft.com/kb/274750
And as far as I can see, this is not a counter-example.
>Why? The calloc() call has two parameters. There is no reason that
the total allocation cannot exceed the value of a size_t.
Obviously if that were the case, pointers would have to be larger than
32 bits. Even if Jacob is not precise, he obviously means systems
with 32-bit pointers. Constantly attacking for imprecision, when he's
trying to make a serious point about faulty implementations, seems
pointless.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jan 3 '07 #23

P: n/a
Richard Tobin a écrit :
In article <11*********************@v33g2000cwv.googlegroups. com>,
user923005 <dc*****@connx.comwrote:

>>BTW, there are definitely 32 bit systems that will allocate memory in
excess of 32 bits. For example:


There are many 32-bit systems that allow more than 2^32 bytes of
memory to be used, but none that I know of that allow a block that big
to be accessed through calls to C standard allocation functions.

>>http://support.microsoft.com/kb/274750


And as far as I can see, this is not a counter-example.
SQL server surely doesn't use calloc for allocating 32GB of
RAM, since it needs 48 bit pointers (16:32 pointers with
a segmented architecture like in the msdos days of 16:16)
>
>>Why? The calloc() call has two parameters. There is no reason that
the total allocation cannot exceed the value of a size_t.


Obviously if that were the case, pointers would have to be larger than
32 bits. Even if Jacob is not precise, he obviously means systems
with 32-bit pointers. Constantly attacking for imprecision, when he's
trying to make a serious point about faulty implementations, seems
pointless.
Thanks. this is precisely what I meant.

sizeof returns a size_t. If an object larger than 4GB
could exist then size_t can't be 32 bits.

Jan 3 '07 #24

P: n/a
jacob navia wrote:
Spiros Bousbouras a écrit :
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 ?

if size_t is 32 bits, it would be highly surprising that
an allocator returns an object of size 33 bits at least.

You are just saying here that such a system *could* exist.
This doesn't make it any more real.

OK. In those hypothetical systems my test would fail.
But how do you know that the systems that you tried
are not one of those "hypothetical" systems ?
>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.

because if an object of size 4GB could exist, sizeof
(that returns a size_t) would not work.
You could not declare an array which has size 4GB
but it doesn't necessarily impose restrictions on what
calloc can return. But I agree it would be surprising.
>
>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.

You can't be bothered to be honest?

I hope you mean

To be honest, I can't be bothered...

:-)
I meant "I can't be bothered , to be honest , ..."
;-)
>
BUG!!!!
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.

Excuse me but what calloc does is not measured. I just
test the result. If it is the system's fault or whatever
this is not relevant.
This answers my second point but not my first , that your
test doesn't tell you for sure how much memory has been
allocated.

Jan 3 '07 #25

P: n/a
In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>Maybe people with other compilers/implementations
would compile this program and send the results?
To my surprise, it has the bug on MacOS X Tiger with gcc 4.0.1 (x86)
and 4.0.0 (ppc). It also has the bug on Dragonfly 1.2 with gcc 2.95,
but that's a rather out-of-date system. It behaves correctly on
FreeBSD 6.1 x86 with gcc 3.4.4. I have a vague recollection of seeing
discussions about fixing this very problem in *BSD within the last
year or so.

In all cases I think the version of gcc is irrelevant; rather it is
the version of the C library that matter and the OS version determines
that. (The situation is likely to be more complicated for Linux,
where I believe people mix and match kernel and glibc versions.) All
these systems have sizeof(char *) == 4, sizeof(size_t) == 4, and
CHAR_BIT == 8.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jan 3 '07 #26

P: n/a
Richard Tobin wrote:
In article <11*********************@v33g2000cwv.googlegroups. com>,
user923005 <dc*****@connx.comwrote:
Why? The calloc() call has two parameters. There is no reason that
the total allocation cannot exceed the value of a size_t.

Obviously if that were the case, pointers would have to be larger than
32 bits. Even if Jacob is not precise, he obviously means systems
with 32-bit pointers. Constantly attacking for imprecision, when he's
trying to make a serious point about faulty implementations, seems
pointless.
Well it wasn't obvious to me from his first post. Even
if some people here were out to get him, so to speak, he
could still try to offer them less possibilities by being
precise and clear.

Jan 3 '07 #27

P: n/a
In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>sizeof returns a size_t. If an object larger than 4GB
could exist then size_t can't be 32 bits.
To be pedantic, that doesn't quite follow. You can't apply sizeof to
the block returned by calloc(). I'm not sure whether you can legally
have a system in which calloc() can return an object with more bytes
than size_t can count.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jan 3 '07 #28

P: n/a
jacob navia wrote:
P.S.
I forgot to spell out clearly the objective of this tests.

My objective is to

1) make a list of all the buggy systems that
is here in clc and everybody can see.

2) Make people aware of this bug in their implementations.
(if any)
Ok , now we're getting somewhere.

So the central question is:

If some code contains a call of the form calloc(n,m)
where n*m 2**( sizeof(void*) * CHAR_BIT) then is it
the obligation of the calloc implementation to detect
this and return NULL ?

If the answer to the question is yes then you can say
that the implementations which don't do it are buggy.
>From the practical point of view , if I ever needed to
write something like calloc(n,m) where n*m >= 2**31
on a 32 bits system , alarm bells would start to ring
in my mind and I would wonder if it would work. I
would probably write some small test programme to
see if the allocation would succeed. I'm far from infallible
but my view is that a competent C programmer should
be alert to such issues and not rely on protection from
the calloc implementation *even* if the standard demands
that calloc detects this sort of thing. That's because this
is the kind of thing that an implementor can get wrong.
So I would write a test programme which not only tests
that the allocation succeeded but also assign some random
values to the allocated memory and make sure that everything
went ok.

Jan 3 '07 #29

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
[...]
But this is a well known tactic.

Since I present the code, I do the effort of making all those
measurements, it is so easy to just sit by and say

"A system with 32 bit size_t could allocate more than 4GB
memory. A system like that COULD exist."

So WHAT?

Can you please tell me where that system is????

If not, just do not participate. Thanks for your
correction. A system where this test gives a false
positive COULD exist. It is conceivable.
So you acknowledge that a false positive could exist, but when someone
points it out you ask him not to participate in the discussion.

Try being just a little bit less arrogant.

--
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.
Jan 3 '07 #30

P: n/a
Spiros Bousbouras wrote:
Richard Tobin wrote:
In article <11*********************@v33g2000cwv.googlegroups. com>,
user923005 <dc*****@connx.comwrote:
>Why? The calloc() call has two parameters. There is no reason that
>the total allocation cannot exceed the value of a size_t.
Obviously if that were the case, pointers would have to be larger than
32 bits. Even if Jacob is not precise, he obviously means systems
with 32-bit pointers. Constantly attacking for imprecision, when he's
trying to make a serious point about faulty implementations, seems
pointless.

Well it wasn't obvious to me from his first post. Even
if some people here were out to get him, so to speak, he
could still try to offer them less possibilities by being
precise and clear.
His code does not demonstrate anything useful.
For instance, it does not show how big a size_t can be or how large of
an allocation is possible or anything of the sort.

Imagine the following:
void *p =calloc(128000, 128000);

Suppose that under the cover, the allocation created an array of 128000
void pointers.
Then, it allocated 128000 separate 128000 byte objects and pointed
those pointers to the objects.
Then it memset each of the 128000 distinct 128000 byte objects with
zero.
We do not need greater than 4GB to cover the stride of the pointer
list.
We do not need greater than 4 GB for any individual object.
Would that implementation be conforming?

We might also use a hash map to associate pointers and allocated ram.

We might allocate in blocksizes of more than one byte. We could use
(for instance) 16 byte pages and still address 4GB*16 bytes with an
unsigned 32 bit integer.

We have lots of 64 bit computers here where I work. I can calloc()
more than 4 GB as su, but if I log on as some other user, I cannot
allocate more than (e.g.) 100 MB. What would his program tell you?

I don't think it shows what he thinks it shows and if it did the way he
thinks it should it still woudn't.

IMO-YMMV.

Jan 3 '07 #31

P: n/a
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...
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");
}
My system (Red Hat Enterprise Linux 4.X with all errata applied) reports no
bug. The details are below.

Please note that I have subtly modified your test program by adding an
"else" clause. I don't think you'll object.

It isn't immediately clear to me why the call has to fail. 2^16 * 2^16 is
2^32 (4 gigabytes). My system has more virtual memory than that.

Dave.
----------

[nouser@pamc ~]$ cat test2.c
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *p=calloc(65521,65552);
if (p)
printf("BUG!!!!\n");
else
printf("NO BUG!!!!\n");
}
[nouser@pamc ~]$ gcc test2.c
[nouser@pamc ~]$ ./a.out
NO BUG!!!!
[nouser@pamc ~]$ rpm -q -a|grep gcc
gcc-c++-3.4.6-3
gcc-objc-3.4.6-3
gcc-3.4.6-3
gcc-java-3.4.6-3
compat-gcc-32-3.2.3-47.3
libgcc-3.4.6-3
gcc-gnat-3.4.6-3
compat-libgcc-296-2.96-132.7.2
gcc-g77-3.4.6-3
[nouser@pamc ~]$
Jan 3 '07 #32

P: n/a
"Spiros Bousbouras" <sp****@gmail.comwrites:
jacob navia wrote:
>P.S.
I forgot to spell out clearly the objective of this tests.

My objective is to

1) make a list of all the buggy systems that
is here in clc and everybody can see.

2) Make people aware of this bug in their implementations.
(if any)

Ok , now we're getting somewhere.

So the central question is:

If some code contains a call of the form calloc(n,m)
where n*m 2**( sizeof(void*) * CHAR_BIT) then is it
the obligation of the calloc implementation to detect
this and return NULL ?

If the answer to the question is yes then you can say
that the implementations which don't do it are buggy.
[...]

I won't try to speak for jacob, but there is a valid point that's
similar to what he's talking about.

I'll use the same notation I introduced here recently: an expression
enclosed in "<<" and ">>" is intended to be interpreted as if all
operations were performed over the full infinite set of integers, with
no overflow or wraparound.

If some code contains a call of the form calloc(n, m), then the system
should either successfully allocate <<n*m>bytes or return a null
pointer.

If <<n*m>exceeds SIZE_MAX, and the system is actually able to
allocate that many bytes, that's ok.

There is a bug that some systems seem to have, where calloc()
internally multiplies its two parameters yielding a result of type
size_t, and ignores the possibility that the result could wrap around.
On such systems, for certain values of n and m, a call calloc(n, m)
might successfully allocate <<(n * m) % SIZE_MAX>bytes, which is
less than <<n * m>>.

jacob's test program (in either version) does not detect this bug with
100% reliability, but if it reports "BUG!!!!" on a given system, it's
probably a good idea to investigate further.

There's a related potential bug, where something like
p = malloc(COUNT * sizeof *p);
can successfully allocate fewer bytes than intended, but in this case
the bug is in the user code; there's not really anything the malloc()
implementation can do about it.

--
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.
Jan 3 '07 #33

P: n/a
"David T. Ashley" <dt*@e3ft.comwrote in message
news:8c******************************@giganews.com ...
>
It isn't immediately clear to me why the call has to fail. 2^16 * 2^16 is
2^32 (4 gigabytes). My system has more virtual memory than that.
Well, just out of curiousity, I tried it out to see what the largest
approximate value is. Results below.

54135^2 is going to be on the order of 2.5G. That is a pretty fair hunk of
memory.

---------

[nouser@pamc ~]$ cat test3.c
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *p;
int i;

for (i=65535; i>0; i--)
{
if (p = calloc(i,i))
{
printf("%d is apparently the largest integer that will succeed.\n",
i);
break;
}
}
}
[nouser@pamc ~]$ gcc test3.c
[nouser@pamc ~]$ ./a.out
54135 is apparently the largest integer that will succeed.
[nouser@pamc ~]$
Jan 3 '07 #34

P: n/a
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>>sizeof returns a size_t. If an object larger than 4GB
could exist then size_t can't be 32 bits.

To be pedantic, that doesn't quite follow. You can't apply sizeof to
the block returned by calloc().
Agreed.
I'm not sure whether you can legally
have a system in which calloc() can return an object with more bytes
than size_t can count.
I think you can, but such a system would have to have pointers bigger
than size_t. calloc() allocates an object; each byte of that object
must have a unique address of type char* or void*. Making size_t
smaller than void* is probably legal, but I can't think of a good
reason to do it (perhaps the DS9K does this).

--
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.
Jan 3 '07 #35

P: n/a
"user923005" <dc*****@connx.comwrites:
[...]
Imagine the following:
void *p =calloc(128000, 128000);

Suppose that under the cover, the allocation created an array of 128000
void pointers.
Then, it allocated 128000 separate 128000 byte objects and pointed
those pointers to the objects.
Then it memset each of the 128000 distinct 128000 byte objects with
zero.
We do not need greater than 4GB to cover the stride of the pointer
list.
We do not need greater than 4 GB for any individual object.
Would that implementation be conforming?
I don't believe so. calloc() must allocate a single contiguous object
(which happens to be an array object). Each byte of this object (or
equivalently, each byte of each element of the array) must have a
unique address.

--
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.
Jan 3 '07 #36

P: n/a
Keith Thompson wrote:
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
>In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>>sizeof returns a size_t. If an object larger than 4GB
could exist then size_t can't be 32 bits.
To be pedantic, that doesn't quite follow. You can't apply sizeof to
the block returned by calloc().

Agreed.
> I'm not sure whether you can legally
have a system in which calloc() can return an object with more bytes
than size_t can count.

I think you can, but such a system would have to have pointers bigger
than size_t. calloc() allocates an object; each byte of that object
must have a unique address of type char* or void*. Making size_t
smaller than void* is probably legal, but I can't think of a good
reason to do it (perhaps the DS9K does this).
Isn't this similar with the far/near pointers from Turbo C?

--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)
Jan 3 '07 #37

P: n/a
Spiros Bousbouras said:

<snip>
>
Even
if some people here were out to get him, so to speak, he
could still try to offer them less possibilities by being
precise and clear.
"Fewer", my dear chap - "fewer". :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jan 3 '07 #38

P: n/a
"David T. Ashley" <dt*@e3ft.comwrites:
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...
>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");
}

My system (Red Hat Enterprise Linux 4.X with all errata applied) reports no
bug. The details are below.

Please note that I have subtly modified your test program by adding an
"else" clause. I don't think you'll object.

It isn't immediately clear to me why the call has to fail. 2^16 * 2^16 is
2^32 (4 gigabytes). My system has more virtual memory than that.
Really? Is it a 64-bit system? jacob's test program is intended to
apply only to systems with 32-bit size_t.

If your system has more than 4 gigabytes of virtual memory, but only a
32-bit size_t, that might cause some problems. (Or it might not, if
no single object can be bigger than 4 gigabytes.)

--
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.
Jan 3 '07 #39

P: n/a
Seems to me a simpler test might be:

size_t count; /* for calloc() count, eventually */
size_t size; /* for calloc() object size, eventually */
/* the square root of the biggest size_t is a hint that we may be over
the edge */
const size_t sqrtstm = (size_t)sqrt(double(size_t(-1)));

....
if (count sqrtstm || size sqrtstm)
{
double dcount = count;
double dsize = size;
double dproduct = dcount * dsize;
if (dproduct ((size_t)-1))
{
raise_bloody_heck();
}
}

or something of that ilk.
Relying on undocumented (at best) behavior seems a bit strange to me.
I guess that {for instance} passing two (size_t)-1 values into calloc()
will result in undefined behavior. I guess that calloc() could
conceivably be clever enough to catch it, but I am very sure that it
would not be portable.

Jan 3 '07 #40

P: n/a
av
On 3 Jan 2007 01:54:44 GMT, Richard Tobin wrote:
>In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>>Maybe people with other compilers/implementations
would compile this program and send the results?

To my surprise, it has the bug on MacOS X Tiger with gcc 4.0.1 (x86)
and 4.0.0 (ppc). It also has the bug on Dragonfly 1.2 with gcc 2.95,
but that's a rather out-of-date system. It behaves correctly on
FreeBSD 6.1 x86 with gcc 3.4.4. I have a vague recollection of seeing
discussions about fixing this very problem in *BSD within the last
year or so.
the "problem" is not in calloc or malloc but it is in the mathemaical
model ("modello matematico") used for size_t
Jan 3 '07 #41

P: n/a
av
On Tue, 02 Jan 2007 19:38:14 -0800, Keith Thompson wrote:
>jacob's test program (in either version) does not detect this bug with
100% reliability, but if it reports "BUG!!!!" on a given system, it's
probably a good idea to investigate further.

There's a related potential bug, where something like
p = malloc(COUNT * sizeof *p);
can successfully allocate fewer bytes than intended, but in this case
the bug is in the user code; there's not really anything the malloc()
implementation can do about it.
there is the same "bug" if there is some "calculus" on a size_t
variable "var" that use the mod definition
and then that variable "var" is passed to some standard c function
that has as parameter size_t (and it seems there are many function
that use size_t)
Jan 3 '07 #42

P: n/a
jacob navia wrote:
>
.... snip ...
>
OK This is a misunderstanding 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,65552))
printf("BUG!!!!\n");
return 0; // For C89 compilers
}
Wrong. A size_t object can include other padding bits. You need
to work with SIZE_MAX or (size_t)-1. Don't you care enough about
your posts to format them properly?

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Jan 3 '07 #43

P: n/a
user923005 wrote:
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.
Yes there is. Fragment follows:

#define N 65600
#define M 65530

long n, m;
char *p;

if (p = calloc(N, M)
for (n = N; n, n--)
for (m = M; m, m--)
if (p[n * m]) puts("BUG")
puts("OK");

if n * m exceeds SIZE_MAX, how is the program going to access that
storage? Since it can't, why even attempt to allocate it.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Jan 3 '07 #44

P: n/a
jacob navia wrote:
Jens Thoms Toerring a écrit :
[snip]

Please see the answer of Mr Spiros Bousburas in this same thread
and try to understand what I want before jumping to conclusions.

Thanks

P.S. if you do not want to participate it is OK but please do not
send noise.
Do you ever read your own posts? I'm sure Herr Toerring is
overjoyed and relieved to have your permission to participate in a
*public* newsgroup.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Jan 3 '07 #45

P: n/a
jacob navia wrote:
>
.... snip ...
>
My objective is to

1) make a list of all the buggy systems that
is here in clc and everybody can see.
2) Make people aware of this bug in their implementations.
(if any)
Do you really want people to start testing and publicizing bugs in
LCC-win32? Bugs being defined as failure to meet the C99 standard
(which you claim to meet) and/or failure to accurately diagnose
errors. Consider your answer carefully, in the light of having
annoyed many of the most knowledgeable here, whose reports will
probably not be designed to help finding the bug cause.

The results might be the beginning of a GPLd standard C test suite,
after de-obfuscation.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Jan 3 '07 #46

P: n/a
"David T. Ashley" wrote:
>
.... snip ...
>
54135^2 is going to be on the order of 2.5G. That is a pretty
fair hunk of memory.

---------

[nouser@pamc ~]$ cat test3.c
#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *p;
int i;

for (i=65535; i>0; i--)
{
if (p = calloc(i,i))
{
printf("%d is apparently the largest integer that will succeed.\n",
i);
break;
}
}
}
[nouser@pamc ~]$ gcc test3.c
[nouser@pamc ~]$ ./a.out
54135 is apparently the largest integer that will succeed.
[nouser@pamc ~]$
With DJGPP 2.03 (specifies the library) that crashes immediately in
memset. With nmalloc linked in in place of the library it yields
23093.

Advisory cross-post to comp.os.msdos.djgpp, f'ups set to clc.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>
Jan 3 '07 #47

P: n/a
av
On 3 Jan 2007 01:54:44 GMT, Richard Tobin wrote:
>In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>>Maybe people with other compilers/implementations
would compile this program and send the results?

To my surprise, it has the bug on MacOS X Tiger with gcc 4.0.1 (x86)
and 4.0.0 (ppc). It also has the bug on Dragonfly 1.2 with gcc 2.95,
but that's a rather out-of-date system. It behaves correctly on
FreeBSD 6.1 x86 with gcc 3.4.4. I have a vague recollection of seeing
discussions about fixing this very problem in *BSD within the last
year or so.
the "problem" is not in calloc or malloc but it is in the mathemaical
model ("modello matematico") used for size_t
Jan 3 '07 #48

P: n/a
av said:

<snip>
the "problem" is not in calloc or malloc but it is in the mathemaical
model ("modello matematico") used for size_t
That's not a problem at all. It's simple and well-defined. The problem is in
failing to understand that limits exist.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jan 3 '07 #49

P: n/a
I cannot help you... :-(

But I found nmalloc on your page and it looks interesting. I am using
latest 2.04 (alpha/beta?) binary and think, that it isn't included there?
Then I would like to use it in my own project.

Bye
--
Florian Xaver

Webdesign, Sword, oZone, personal site: <http://www.flox.at.tf>
Dr-DOS Wiki: <http://www.drdos.org>

Jan 3 '07 #50

149 Replies

This discussion thread is closed

Replies have been disabled for this discussion.