Request

[CBFalconer]

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

 

[CBFalconer]

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.

 

[CBFalconer]

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

 

[CBFalconer]

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.

 

[CBFalconer]

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

 

[av]

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

 

[av]

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)

 

[av]

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

 

[Richard Heathfield]

av said:

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.

 

[Florian Xaver]

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

 

[av]

av said:



That's not a problem at all. It's simple and well-defined. The problem is in
failing to understand that limits exist.

not for me

 

[user923005]

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 exceed (size_t) -1, I would submit that the program probably
already exhibits undefined behavior.

If the loop runs to completion that is not an indication that the
allcation worked correctly. Only that it might have.

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.

His program in no way tests to see if n*m exceeds SIZE_MAX, except by
pure accident.

 

[Richard Tobin]

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

[/QUOTE]

You wouldn't be able to copy large objects with memcpy(), but that
doesn't prove that it's not legal.

Isn't this similar with the far/near pointers from Turbo C?

Yes, but no-one suggests that that conforms to the C standard.

-- Richard

 

[Richard Tobin]

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

It can't access it by indexing from a char * pointer to the start
of the block, but consider the more realistic:

struct foo *p = calloc(large_number, sizeof(*p));

where sizeof(struct foo) > 1.

-- Richard

 

[Richard Tobin]

the "problem" is not in calloc or malloc but it is in the mathemaical
model ("modello matematico") used for size_t

That's true in a sense: the modular arithmetic used for unsigned types
is not appropriate to sizes. But the problem can be fixed in calloc()
without changing the mathematical model used for size_t.

The solution is either to convert the sizes to some other type first,
or to check in some other way that multiplication as size_t would give
the same result as multiplication as (mathematical) integers.

-- Richard

 

[CBFalconer]

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.

Go ahead. Under DJGPP copying license there are virtually no
restrictions. I don't know if you can simply replace the malloc
module in the library. But prelinking malloc.o works under DJGPP.
Report any problems to comp.os.msdos.djgpp and/or to me at the
following address (the address in the zip is obsolete). The lack
of memalign may affect compiling of gcc. Don't really know.

 

[Cesar Rabak]

user923005 escreveu:

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.

But in what part of the text (or the page) there is any information how
a programmer can allocate all this memory in a single chunk?

And in this case would that be via a call to calloc?

 

[Keith Thompson]

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.

There's no *absolute* reason why calloc() can't allocate more than
SIZE_MAX bytes. n and m could be of some type bigger than size_t.
(Array indexing and pointer arithmetic aren't defined in terms of
size_t.)

However, each byte of the allocated object must have a distinct
address, so (ignoring padding bits) char* would have to be bigger than
size_t. I believe this would be legal but silly.

 

[Keith Thompson]

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.

I don't believe he actually claims that lcc-win32 fully conforms to
C99 (though some of his statements here could lead to that
conclusion). When I asked in comp.compilers.lcc-win32 a few months
ago, he replied:

| Designated initializers and structure initializers with the
| dot notation are missing.
|
| I am giving priority to the library, that is kind of
| "mostly" finished. I have probably some problems with
| complex numbers, there hasn't been a good testing of that
| part.
|
| Besides the preprocessor is still missing the variable
| arguments feature.

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

GPL-ing it would, if I'm not mistaken, require explicit permission by
all contributors. I'm not saying it can't or shouldn't be done, but
it would would have to be planned from the beginning.

 

[Keith Thompson]

av said:


That's not a problem at all. It's simple and well-defined. The problem is in
failing to understand that limits exist.

Yes. *Another* problem is the lack of operations on size_t (and
unsigned types in general) that behave in a manner other than the one
chosen by the standard. This inflexibility of the language makes some
useful operations difficult to implement, and in some cases impossible
to implement both portably and efficiently.

On the other hand, "fixing" this "problem" would make the language
more complicated, and it's not entirely sure that it would be worth
it.