Can calloc() allocate more than SIZE

up vote
8
down vote

favorite

In a recent code review, it was claimed that

On select systems, calloc() can allocate more than SIZE_MAX total bytes whereas malloc() is limited.

My claim is that that's mistaken, because calloc() creates space for an array of objects - which, being an array, is itself an object. And no object can be larger in size than SIZE_MAX.

So which of us is correct? On a (possibly hypothetical) system with address space larger than the range of size_t, is calloc() allowed to succeed when called with arguments whose product is greater than SIZE_MAX?

To make it more concrete: will the following program ever exit with a non-zero status?

#include <stdint.h>
#include <stdlib.h>

int main()

 return calloc(SIZE_MAX, 2) != NULL;

edited 1 hour ago

asked 2 hours ago

Toby Speight

15.3k133762

more quote : "A good calloc(n, size) will detect products of n * size greater the SIZE_MAX". This actually looks like an opinion. Standard does not mention something like "good calloc" and says nothing about detection of "n * size greater the SIZE_MAX" situation
â€“Â VTT
2 hours ago

I would assume, that he means, that the argument passed to malloc contains the product from the size and the amount of objects created, which can be larger than SIZE_MAX, but in calloc you have two parameters for that (so you can allocate SIZE_MAX elements with 4 bytes each.
â€“Â hellow
2 hours ago

@hellow, exactly. I don't believe that's a valid call, because such an array violates the rule that size_t can represent the size of any object.
â€“Â Toby Speight
2 hours ago

2

DR266 seems to be related. Only found this: DR-266 RM position is sizeof never overflows. DG - ignore the calloc problem. PJ - size_t must be representable, cannot overflow, by definition. Attempt to overflow s/be a constraint violation / undefined behavior.
â€“Â Kamil Cuk
1 hour ago

2

Here's the link to DR-266.
â€“Â P.P.
1 hour ago

Â |Â
show 11 more comments

up vote
8
down vote

favorite

In a recent code review, it was claimed that

On select systems, calloc() can allocate more than SIZE_MAX total bytes whereas malloc() is limited.

My claim is that that's mistaken, because calloc() creates space for an array of objects - which, being an array, is itself an object. And no object can be larger in size than SIZE_MAX.

To make it more concrete: will the following program ever exit with a non-zero status?

#include <stdint.h>
#include <stdlib.h>

int main()

 return calloc(SIZE_MAX, 2) != NULL;

edited 1 hour ago

asked 2 hours ago

Toby Speight

15.3k133762

more quote : "A good calloc(n, size) will detect products of n * size greater the SIZE_MAX". This actually looks like an opinion. Standard does not mention something like "good calloc" and says nothing about detection of "n * size greater the SIZE_MAX" situation
â€“Â VTT
2 hours ago

I would assume, that he means, that the argument passed to malloc contains the product from the size and the amount of objects created, which can be larger than SIZE_MAX, but in calloc you have two parameters for that (so you can allocate SIZE_MAX elements with 4 bytes each.
â€“Â hellow
2 hours ago

@hellow, exactly. I don't believe that's a valid call, because such an array violates the rule that size_t can represent the size of any object.
â€“Â Toby Speight
2 hours ago

2

DR266 seems to be related. Only found this: DR-266 RM position is sizeof never overflows. DG - ignore the calloc problem. PJ - size_t must be representable, cannot overflow, by definition. Attempt to overflow s/be a constraint violation / undefined behavior.
â€“Â Kamil Cuk
1 hour ago

2

Here's the link to DR-266.
â€“Â P.P.
1 hour ago

Â |Â
show 11 more comments

up vote
8
down vote

favorite

In a recent code review, it was claimed that

On select systems, calloc() can allocate more than SIZE_MAX total bytes whereas malloc() is limited.

My claim is that that's mistaken, because calloc() creates space for an array of objects - which, being an array, is itself an object. And no object can be larger in size than SIZE_MAX.

To make it more concrete: will the following program ever exit with a non-zero status?

#include <stdint.h>
#include <stdlib.h>

int main()

 return calloc(SIZE_MAX, 2) != NULL;

edited 1 hour ago

asked 2 hours ago

Toby Speight

15.3k133762

In a recent code review, it was claimed that

On select systems, calloc() can allocate more than SIZE_MAX total bytes whereas malloc() is limited.

My claim is that that's mistaken, because calloc() creates space for an array of objects - which, being an array, is itself an object. And no object can be larger in size than SIZE_MAX.

To make it more concrete: will the following program ever exit with a non-zero status?

#include <stdint.h>
#include <stdlib.h>

int main()

 return calloc(SIZE_MAX, 2) != NULL;

c language-lawyer

edited 1 hour ago

asked 2 hours ago

Toby Speight

15.3k133762

edited 1 hour ago

asked 2 hours ago

Toby Speight

15.3k133762

edited 1 hour ago

asked 2 hours ago

Toby Speight

15.3k133762

asked 2 hours ago

Toby Speight

15.3k133762

asked 2 hours ago

Toby Speight

15.3k133762

more quote : "A good calloc(n, size) will detect products of n * size greater the SIZE_MAX". This actually looks like an opinion. Standard does not mention something like "good calloc" and says nothing about detection of "n * size greater the SIZE_MAX" situation
â€“Â VTT
2 hours ago

I would assume, that he means, that the argument passed to malloc contains the product from the size and the amount of objects created, which can be larger than SIZE_MAX, but in calloc you have two parameters for that (so you can allocate SIZE_MAX elements with 4 bytes each.
â€“Â hellow
2 hours ago

@hellow, exactly. I don't believe that's a valid call, because such an array violates the rule that size_t can represent the size of any object.
â€“Â Toby Speight
2 hours ago

2

DR266 seems to be related. Only found this: DR-266 RM position is sizeof never overflows. DG - ignore the calloc problem. PJ - size_t must be representable, cannot overflow, by definition. Attempt to overflow s/be a constraint violation / undefined behavior.
â€“Â Kamil Cuk
1 hour ago

2

Here's the link to DR-266.
â€“Â P.P.
1 hour ago

Â |Â
show 11 more comments

more quote : "A good calloc(n, size) will detect products of n * size greater the SIZE_MAX". This actually looks like an opinion. Standard does not mention something like "good calloc" and says nothing about detection of "n * size greater the SIZE_MAX" situation
â€“Â VTT
2 hours ago

I would assume, that he means, that the argument passed to malloc contains the product from the size and the amount of objects created, which can be larger than SIZE_MAX, but in calloc you have two parameters for that (so you can allocate SIZE_MAX elements with 4 bytes each.
â€“Â hellow
2 hours ago

@hellow, exactly. I don't believe that's a valid call, because such an array violates the rule that size_t can represent the size of any object.
â€“Â Toby Speight
2 hours ago

2

DR266 seems to be related. Only found this: DR-266 RM position is sizeof never overflows. DG - ignore the calloc problem. PJ - size_t must be representable, cannot overflow, by definition. Attempt to overflow s/be a constraint violation / undefined behavior.
â€“Â Kamil Cuk
1 hour ago

2

Here's the link to DR-266.
â€“Â P.P.
1 hour ago

more quote : "A good calloc(n, size) will detect products of n * size greater the SIZE_MAX". This actually looks like an opinion. Standard does not mention something like "good calloc" and says nothing about detection of "n * size greater the SIZE_MAX" situation
â€“Â VTT
2 hours ago

I would assume, that he means, that the argument passed to malloc contains the product from the size and the amount of objects created, which can be larger than SIZE_MAX, but in calloc you have two parameters for that (so you can allocate SIZE_MAX elements with 4 bytes each.
â€“Â hellow
2 hours ago

@hellow, exactly. I don't believe that's a valid call, because such an array violates the rule that size_t can represent the size of any object.
â€“Â Toby Speight
2 hours ago

DR266 seems to be related. Only found this:

DR-266 RM position is sizeof never overflows. DG - ignore the calloc problem. PJ - size_t must be representable, cannot overflow, by definition. Attempt to overflow s/be a constraint violation / undefined behavior.

â€“Â Kamil Cuk
1 hour ago

DR266 seems to be related. Only found this:

DR-266 RM position is sizeof never overflows. DG - ignore the calloc problem. PJ - size_t must be representable, cannot overflow, by definition. Attempt to overflow s/be a constraint violation / undefined behavior.

â€“Â Kamil Cuk
1 hour ago

Here's the link to DR-266.
â€“Â P.P.
1 hour ago

Â |Â
show 11 more comments

4 Answers
4

active

oldest

votes

up vote
3
down vote

SIZE_MAX doesn't necessary specify the maximum size of an object, but rather the maximum value of size_t, which is not necessarily the same thing. See Why is the maximum size of an array "too large"?,

But obviously, it isn't well-defined to pass a larger value than SIZE_MAX to a function expecting a size_t parameter. So in theory SIZE_MAX is the limit, and in in theory calloc would allow for SIZE_MAX * SIZE_MAX bytes to allocated.

The thing with malloc/calloc is that they allocate objects without a type. Objects with a type have restrictions, such as never being larger than a certain limit like SIZE_MAX. But the data pointed-at by the result from these functions does not have a type. It is not (yet) an array.

Formally, the data has no declared type, but as you store something inside the allocated data, it gets the effective type of the data access used for storage (C17 6.5 Ã‚Â§6).

This in turn means that it would be possible for calloc to allocate more memory than any type in C can hold, because what's allocated does not (yet) have a type.

Therefore, as far as the C standard is concerned, it is perfectly fine for calloc(SIZE_MAX, 2) to return a value different from NULL. How to actually use that allocated memory in a sensible way, or which systems that even support such large chunks of memory on the heap, is another story.

answered 54 mins ago

Lundin

102k16149251

This does suggest, I think, a peculiar relationship between SIZE_MAX and ptrdiff_t, since on a system where calloc could behave as described, ptrdiff_t would have to be large enough to cope.
â€“Â Steve Summit
38 mins ago

1

@SteveSummit Yeah that's the catch, as explained by the accepted answer in the linked post, that SIZE_MAX and PTRDIFF_MAX always have to follow, and the latter being a signed type. However, given a SIZE_MAX 2^n, the standard doesn't restrict the compiler to have a PTRDIFF_MAX which is 2^(n+1). It's just very inconvenient for the compiler to have such a burdensome type system so in practice it isn't implemented like that. Overall, the C standard doesn't handle the problems with these two types very well, but leaves the thinking "to the implementation".
â€“Â Lundin
22 mins ago

add a commentÂ |Â

up vote
2
down vote

Can calloc() allocate more than SIZE_MAX in total?

As the assertion "On select systems, calloc() can allocate more than SIZE_MAX total bytes whereas malloc() is limited." came from a comment I posted, I will explain my rational.

size_t

size_t is some unsigned type of at least 16 bits.

size_t which is the unsigned integer type of the result of the sizeof operator; C11dr Ã‚Â§7.19 2

"Its implementation-defined value shall be equal to or greater in magnitude
... than the corresponding value given below" ... limit of size_t SIZE_MAX ... 65535 Ã‚Â§7.20.3 2

sizeof

The sizeof operator yields the size (in bytes) of its operand Ã‚Â§6.5.3.4 2

calloc

void *calloc(size_t nmemb, size_t size);

The calloc function allocates space for an array of nmemb objects, each of whose size is size. Ã‚Â§7.22.3.2 2

Consider a situation where nmemb * size well exceeds SIZE_MAX.

size_t alot = SIZE_MAX/2;
double *p = calloc(alot, sizeof *p); // assume `double` is 8 bytes.

If p != NULL is true, what spec did this violate?

The size of each element, (each object) is representable.

// Nicely reports the size of a pointer and an element.
printf("sizeof p:%zu, sizeof *p:%zun", sizeof p, sizeof *p);

Each element can be accessed.

// Nicely reports the value of an `element` and the address of the element
for (size_t i = 0; i<alot; i++) 
 printf("value a[%zu]:%g, address:%pn", i, p[i], (void*) &p[i]);

calloc() details

"space for an array of nmemb objects": This is certainly a key point of contention. Does the "allocates space for the array" require <= SIZE_MAX? I found nothing in the C spec to require this limit and so conclude:

calloc() may allocate more than SIZE_MAX in total.

It is certainly uncommon for calloc() with large arguments to return non-NULL - compliant or not. Usually such allocations exceed memory available, so the issue is moot. The only case I've encountered was with the Huge memory model where size_t was 16 bit and the object pointer was 32 bit.

edited 9 mins ago

answered 16 mins ago

chux

75.2k864136

I suspect some discussion will ensue. I'll address various comments as able later today.
â€“Â chux
15 mins ago

add a commentÂ |Â

up vote
1
down vote

From

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

Returns

3 The calloc function returns either a null pointer or a pointer to the allocated space.

I fail to see why the space allocated should be limited to SIZE_MAX bytes.

edited 1 hour ago

answered 2 hours ago

Swordfish

4,174729

3

My reasoning is that calloc() allocates space for an array of objects. An array is an object, therefore it must be measurable using a size_t.
â€“Â Toby Speight
2 hours ago

add a commentÂ |Â

up vote
0
down vote

If a program exceeds implementation limits, behavior is undefined. This follows from the definition of an implementation limit as a restriction imposed upon programs by the implementation (3.13 in C11). The standard also says that strictly-conforming programs must adhere to implementation limits (4p5 in C11). But this also implies to programs in general because the standard does not say what happens when most implementation limits are exceeded (so it is the other kind of undefined behavior, where the standard does not specify what happens).

The standard also does not define what implementation limits may exist, so this a bit of carte blanche, but I think it is reasonable that the maximum object size is actually relevant to object allocations. (The maximum object size is typically smaller than SIZE_MAX, by the way, because the difference of pointers-to-char within the object must be representable in ptrdiff_t.)

This leads us to the following observation: A call to calloc (SIZE_MAX, 2) exceeds the maximum object size limit, so an implementation could return an arbitrary value while still conforming to the standard.

Some implementations will actually return a pointer which is not null for a call like calloc (SIZE_MAX / 2 + 2, 2) because the implementation does not check that the multiplication result does not fit into a size_t value. Whether this a good idea is a different matter, given that the implementation limit can be checked so easily in this case, and there is a perfectly fine way to report errors. Personally, I consider the lack of overflow checking in calloc an implementation bug, and have reported bugs to implementors when I saw them, but technically, it's merely a quality-of-implementation issue.

For variable-length arrays on the stack, the rule about exceeding implementation limits resulting in undefined behavior is more obvious:

size_t length = SIZE_MAX / 2 + 2;
short object[length];

There is really nothing an implementation can do here, so it has to be undefined.

edited 1 hour ago

answered 1 hour ago

Florian Weimer

13.5k2942

Can you back that up with references to the standard?
â€“Â Werner Henze
1 hour ago

And why do you bring in implementation limits? In J.3.12 in the C standard I do not see any implementation defined limits for calloc other than "Whether the calloc, malloc, and realloc functions return a null pointer or a pointer to an allocated object when the size requested is zero (7.22.3)."
â€“Â Werner Henze
1 hour ago

As noted in DR-266, translation limits do not apply to runtime/allocated objects. So not sure if translation limits apply to calloc.
â€“Â P.P.
1 hour ago

@WernerHenze I added some references. Most of this is undefined because the standard does not say what happens, so it is difficult to back up things with references.
â€“Â Florian Weimer
1 hour ago

SIZE_MAX does not necessarily exceed the maximum object size. It is fine for an implementation to have a PTRDIFF_MAX that is 2^33 signed while at the same time it has a SIZE_MAX which is 2^32 unsigned. It's just very inconvenient for the compiler to have a type system like that, but the standard doesn't care [didn't even consider the problem].
â€“Â Lundin
48 mins ago

add a commentÂ |Â

Your Answer

StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: true,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);

);

draft saved

draft discarded

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52699574%2fcan-calloc-allocate-more-than-size-max-in-total%23new-answer', 'question_page');

);

Post as a guest

Name

4 Answers
4

active

oldest

votes

4 Answers
4

active

oldest

votes

up vote
3
down vote

Formally, the data has no declared type, but as you store something inside the allocated data, it gets the effective type of the data access used for storage (C17 6.5 Ã‚Â§6).

This in turn means that it would be possible for calloc to allocate more memory than any type in C can hold, because what's allocated does not (yet) have a type.

answered 54 mins ago

Lundin

102k16149251

This does suggest, I think, a peculiar relationship between SIZE_MAX and ptrdiff_t, since on a system where calloc could behave as described, ptrdiff_t would have to be large enough to cope.
â€“Â Steve Summit
38 mins ago

1

@SteveSummit Yeah that's the catch, as explained by the accepted answer in the linked post, that SIZE_MAX and PTRDIFF_MAX always have to follow, and the latter being a signed type. However, given a SIZE_MAX 2^n, the standard doesn't restrict the compiler to have a PTRDIFF_MAX which is 2^(n+1). It's just very inconvenient for the compiler to have such a burdensome type system so in practice it isn't implemented like that. Overall, the C standard doesn't handle the problems with these two types very well, but leaves the thinking "to the implementation".
â€“Â Lundin
22 mins ago

add a commentÂ |Â

up vote
3
down vote

Formally, the data has no declared type, but as you store something inside the allocated data, it gets the effective type of the data access used for storage (C17 6.5 Ã‚Â§6).

This in turn means that it would be possible for calloc to allocate more memory than any type in C can hold, because what's allocated does not (yet) have a type.

answered 54 mins ago

Lundin

102k16149251

This does suggest, I think, a peculiar relationship between SIZE_MAX and ptrdiff_t, since on a system where calloc could behave as described, ptrdiff_t would have to be large enough to cope.
â€“Â Steve Summit
38 mins ago

1

@SteveSummit Yeah that's the catch, as explained by the accepted answer in the linked post, that SIZE_MAX and PTRDIFF_MAX always have to follow, and the latter being a signed type. However, given a SIZE_MAX 2^n, the standard doesn't restrict the compiler to have a PTRDIFF_MAX which is 2^(n+1). It's just very inconvenient for the compiler to have such a burdensome type system so in practice it isn't implemented like that. Overall, the C standard doesn't handle the problems with these two types very well, but leaves the thinking "to the implementation".
â€“Â Lundin
22 mins ago

add a commentÂ |Â

up vote
3
down vote

Formally, the data has no declared type, but as you store something inside the allocated data, it gets the effective type of the data access used for storage (C17 6.5 Ã‚Â§6).

This in turn means that it would be possible for calloc to allocate more memory than any type in C can hold, because what's allocated does not (yet) have a type.

answered 54 mins ago

Lundin

102k16149251

Formally, the data has no declared type, but as you store something inside the allocated data, it gets the effective type of the data access used for storage (C17 6.5 Ã‚Â§6).

This in turn means that it would be possible for calloc to allocate more memory than any type in C can hold, because what's allocated does not (yet) have a type.

answered 54 mins ago

Lundin

102k16149251

answered 54 mins ago

Lundin

102k16149251

answered 54 mins ago

Lundin

102k16149251

answered 54 mins ago

Lundin

102k16149251

This does suggest, I think, a peculiar relationship between SIZE_MAX and ptrdiff_t, since on a system where calloc could behave as described, ptrdiff_t would have to be large enough to cope.
â€“Â Steve Summit
38 mins ago

1

@SteveSummit Yeah that's the catch, as explained by the accepted answer in the linked post, that SIZE_MAX and PTRDIFF_MAX always have to follow, and the latter being a signed type. However, given a SIZE_MAX 2^n, the standard doesn't restrict the compiler to have a PTRDIFF_MAX which is 2^(n+1). It's just very inconvenient for the compiler to have such a burdensome type system so in practice it isn't implemented like that. Overall, the C standard doesn't handle the problems with these two types very well, but leaves the thinking "to the implementation".
â€“Â Lundin
22 mins ago

add a commentÂ |Â

This does suggest, I think, a peculiar relationship between SIZE_MAX and ptrdiff_t, since on a system where calloc could behave as described, ptrdiff_t would have to be large enough to cope.
â€“Â Steve Summit
38 mins ago

1

@SteveSummit Yeah that's the catch, as explained by the accepted answer in the linked post, that SIZE_MAX and PTRDIFF_MAX always have to follow, and the latter being a signed type. However, given a SIZE_MAX 2^n, the standard doesn't restrict the compiler to have a PTRDIFF_MAX which is 2^(n+1). It's just very inconvenient for the compiler to have such a burdensome type system so in practice it isn't implemented like that. Overall, the C standard doesn't handle the problems with these two types very well, but leaves the thinking "to the implementation".
â€“Â Lundin
22 mins ago

This does suggest, I think, a peculiar relationship between SIZE_MAX and ptrdiff_t, since on a system where calloc could behave as described, ptrdiff_t would have to be large enough to cope.
â€“Â Steve Summit
38 mins ago

@SteveSummit Yeah that's the catch, as explained by the accepted answer in the linked post, that SIZE_MAX and PTRDIFF_MAX always have to follow, and the latter being a signed type. However, given a SIZE_MAX 2^n, the standard doesn't restrict the compiler to have a PTRDIFF_MAX which is 2^(n+1). It's just very inconvenient for the compiler to have such a burdensome type system so in practice it isn't implemented like that. Overall, the C standard doesn't handle the problems with these two types very well, but leaves the thinking "to the implementation".
â€“Â Lundin
22 mins ago

add a commentÂ |Â

up vote
2
down vote

Can calloc() allocate more than SIZE_MAX in total?

As the assertion "On select systems, calloc() can allocate more than SIZE_MAX total bytes whereas malloc() is limited." came from a comment I posted, I will explain my rational.

size_t

size_t is some unsigned type of at least 16 bits.

size_t which is the unsigned integer type of the result of the sizeof operator; C11dr Ã‚Â§7.19 2

"Its implementation-defined value shall be equal to or greater in magnitude
... than the corresponding value given below" ... limit of size_t SIZE_MAX ... 65535 Ã‚Â§7.20.3 2

sizeof

The sizeof operator yields the size (in bytes) of its operand Ã‚Â§6.5.3.4 2

calloc

void *calloc(size_t nmemb, size_t size);

The calloc function allocates space for an array of nmemb objects, each of whose size is size. Ã‚Â§7.22.3.2 2

Consider a situation where nmemb * size well exceeds SIZE_MAX.

size_t alot = SIZE_MAX/2;
double *p = calloc(alot, sizeof *p); // assume `double` is 8 bytes.

If p != NULL is true, what spec did this violate?

The size of each element, (each object) is representable.

// Nicely reports the size of a pointer and an element.
printf("sizeof p:%zu, sizeof *p:%zun", sizeof p, sizeof *p);

Each element can be accessed.

// Nicely reports the value of an `element` and the address of the element
for (size_t i = 0; i<alot; i++) 
 printf("value a[%zu]:%g, address:%pn", i, p[i], (void*) &p[i]);

calloc() details

calloc() may allocate more than SIZE_MAX in total.

edited 9 mins ago

answered 16 mins ago

chux

75.2k864136

I suspect some discussion will ensue. I'll address various comments as able later today.
â€“Â chux
15 mins ago

add a commentÂ |Â

up vote
2
down vote

Can calloc() allocate more than SIZE_MAX in total?

As the assertion "On select systems, calloc() can allocate more than SIZE_MAX total bytes whereas malloc() is limited." came from a comment I posted, I will explain my rational.

size_t

size_t is some unsigned type of at least 16 bits.

size_t which is the unsigned integer type of the result of the sizeof operator; C11dr Ã‚Â§7.19 2

"Its implementation-defined value shall be equal to or greater in magnitude
... than the corresponding value given below" ... limit of size_t SIZE_MAX ... 65535 Ã‚Â§7.20.3 2

sizeof

The sizeof operator yields the size (in bytes) of its operand Ã‚Â§6.5.3.4 2

calloc

void *calloc(size_t nmemb, size_t size);

The calloc function allocates space for an array of nmemb objects, each of whose size is size. Ã‚Â§7.22.3.2 2

Consider a situation where nmemb * size well exceeds SIZE_MAX.

size_t alot = SIZE_MAX/2;
double *p = calloc(alot, sizeof *p); // assume `double` is 8 bytes.

If p != NULL is true, what spec did this violate?

The size of each element, (each object) is representable.

// Nicely reports the size of a pointer and an element.
printf("sizeof p:%zu, sizeof *p:%zun", sizeof p, sizeof *p);

Each element can be accessed.

// Nicely reports the value of an `element` and the address of the element
for (size_t i = 0; i<alot; i++) 
 printf("value a[%zu]:%g, address:%pn", i, p[i], (void*) &p[i]);

calloc() details

calloc() may allocate more than SIZE_MAX in total.

edited 9 mins ago

answered 16 mins ago

chux

75.2k864136

I suspect some discussion will ensue. I'll address various comments as able later today.
â€“Â chux
15 mins ago

add a commentÂ |Â

up vote
2
down vote

Can calloc() allocate more than SIZE_MAX in total?

As the assertion "On select systems, calloc() can allocate more than SIZE_MAX total bytes whereas malloc() is limited." came from a comment I posted, I will explain my rational.

size_t

size_t is some unsigned type of at least 16 bits.

size_t which is the unsigned integer type of the result of the sizeof operator; C11dr Ã‚Â§7.19 2

"Its implementation-defined value shall be equal to or greater in magnitude
... than the corresponding value given below" ... limit of size_t SIZE_MAX ... 65535 Ã‚Â§7.20.3 2

sizeof

The sizeof operator yields the size (in bytes) of its operand Ã‚Â§6.5.3.4 2

calloc

void *calloc(size_t nmemb, size_t size);

The calloc function allocates space for an array of nmemb objects, each of whose size is size. Ã‚Â§7.22.3.2 2

Consider a situation where nmemb * size well exceeds SIZE_MAX.

size_t alot = SIZE_MAX/2;
double *p = calloc(alot, sizeof *p); // assume `double` is 8 bytes.

If p != NULL is true, what spec did this violate?

The size of each element, (each object) is representable.

// Nicely reports the size of a pointer and an element.
printf("sizeof p:%zu, sizeof *p:%zun", sizeof p, sizeof *p);

Each element can be accessed.

// Nicely reports the value of an `element` and the address of the element
for (size_t i = 0; i<alot; i++) 
 printf("value a[%zu]:%g, address:%pn", i, p[i], (void*) &p[i]);

calloc() details

calloc() may allocate more than SIZE_MAX in total.

edited 9 mins ago

answered 16 mins ago

chux

75.2k864136

Can calloc() allocate more than SIZE_MAX in total?

As the assertion "On select systems, calloc() can allocate more than SIZE_MAX total bytes whereas malloc() is limited." came from a comment I posted, I will explain my rational.

size_t

size_t is some unsigned type of at least 16 bits.

size_t which is the unsigned integer type of the result of the sizeof operator; C11dr Ã‚Â§7.19 2

"Its implementation-defined value shall be equal to or greater in magnitude
... than the corresponding value given below" ... limit of size_t SIZE_MAX ... 65535 Ã‚Â§7.20.3 2

sizeof

The sizeof operator yields the size (in bytes) of its operand Ã‚Â§6.5.3.4 2

calloc

void *calloc(size_t nmemb, size_t size);

The calloc function allocates space for an array of nmemb objects, each of whose size is size. Ã‚Â§7.22.3.2 2

Consider a situation where nmemb * size well exceeds SIZE_MAX.

size_t alot = SIZE_MAX/2;
double *p = calloc(alot, sizeof *p); // assume `double` is 8 bytes.

If p != NULL is true, what spec did this violate?

The size of each element, (each object) is representable.

// Nicely reports the size of a pointer and an element.
printf("sizeof p:%zu, sizeof *p:%zun", sizeof p, sizeof *p);

Each element can be accessed.

// Nicely reports the value of an `element` and the address of the element
for (size_t i = 0; i<alot; i++) 
 printf("value a[%zu]:%g, address:%pn", i, p[i], (void*) &p[i]);

calloc() details

calloc() may allocate more than SIZE_MAX in total.

edited 9 mins ago

answered 16 mins ago

chux

75.2k864136

edited 9 mins ago

answered 16 mins ago

chux

75.2k864136

answered 16 mins ago

chux

75.2k864136

answered 16 mins ago

chux

75.2k864136

I suspect some discussion will ensue. I'll address various comments as able later today.
â€“Â chux
15 mins ago

add a commentÂ |Â

I suspect some discussion will ensue. I'll address various comments as able later today.
â€“Â chux
15 mins ago

I suspect some discussion will ensue. I'll address various comments as able later today.
â€“Â chux
15 mins ago

add a commentÂ |Â

up vote
1
down vote

From

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

Returns

3 The calloc function returns either a null pointer or a pointer to the allocated space.

I fail to see why the space allocated should be limited to SIZE_MAX bytes.

edited 1 hour ago

answered 2 hours ago

Swordfish

4,174729

3

My reasoning is that calloc() allocates space for an array of objects. An array is an object, therefore it must be measurable using a size_t.
â€“Â Toby Speight
2 hours ago

add a commentÂ |Â

up vote
1
down vote

From

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

Returns

3 The calloc function returns either a null pointer or a pointer to the allocated space.

I fail to see why the space allocated should be limited to SIZE_MAX bytes.

edited 1 hour ago

answered 2 hours ago

Swordfish

4,174729

3

My reasoning is that calloc() allocates space for an array of objects. An array is an object, therefore it must be measurable using a size_t.
â€“Â Toby Speight
2 hours ago

add a commentÂ |Â

up vote
1
down vote

From

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

Returns

3 The calloc function returns either a null pointer or a pointer to the allocated space.

I fail to see why the space allocated should be limited to SIZE_MAX bytes.

edited 1 hour ago

answered 2 hours ago

Swordfish

4,174729

From

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

Returns

3 The calloc function returns either a null pointer or a pointer to the allocated space.

I fail to see why the space allocated should be limited to SIZE_MAX bytes.

edited 1 hour ago

answered 2 hours ago

Swordfish

4,174729

edited 1 hour ago

answered 2 hours ago

Swordfish

4,174729

answered 2 hours ago

Swordfish

4,174729

answered 2 hours ago

Swordfish

4,174729

3

My reasoning is that calloc() allocates space for an array of objects. An array is an object, therefore it must be measurable using a size_t.
â€“Â Toby Speight
2 hours ago

add a commentÂ |Â

3

My reasoning is that calloc() allocates space for an array of objects. An array is an object, therefore it must be measurable using a size_t.
â€“Â Toby Speight
2 hours ago

My reasoning is that calloc() allocates space for an array of objects. An array is an object, therefore it must be measurable using a size_t.
â€“Â Toby Speight
2 hours ago

add a commentÂ |Â

up vote
0
down vote

For variable-length arrays on the stack, the rule about exceeding implementation limits resulting in undefined behavior is more obvious:

size_t length = SIZE_MAX / 2 + 2;
short object[length];

There is really nothing an implementation can do here, so it has to be undefined.

edited 1 hour ago

answered 1 hour ago

Florian Weimer

13.5k2942

Can you back that up with references to the standard?
â€“Â Werner Henze
1 hour ago

And why do you bring in implementation limits? In J.3.12 in the C standard I do not see any implementation defined limits for calloc other than "Whether the calloc, malloc, and realloc functions return a null pointer or a pointer to an allocated object when the size requested is zero (7.22.3)."
â€“Â Werner Henze
1 hour ago

As noted in DR-266, translation limits do not apply to runtime/allocated objects. So not sure if translation limits apply to calloc.
â€“Â P.P.
1 hour ago

@WernerHenze I added some references. Most of this is undefined because the standard does not say what happens, so it is difficult to back up things with references.
â€“Â Florian Weimer
1 hour ago

SIZE_MAX does not necessarily exceed the maximum object size. It is fine for an implementation to have a PTRDIFF_MAX that is 2^33 signed while at the same time it has a SIZE_MAX which is 2^32 unsigned. It's just very inconvenient for the compiler to have a type system like that, but the standard doesn't care [didn't even consider the problem].
â€“Â Lundin
48 mins ago

add a commentÂ |Â

up vote
0
down vote

For variable-length arrays on the stack, the rule about exceeding implementation limits resulting in undefined behavior is more obvious:

size_t length = SIZE_MAX / 2 + 2;
short object[length];

There is really nothing an implementation can do here, so it has to be undefined.

edited 1 hour ago

answered 1 hour ago

Florian Weimer

13.5k2942

Can you back that up with references to the standard?
â€“Â Werner Henze
1 hour ago

And why do you bring in implementation limits? In J.3.12 in the C standard I do not see any implementation defined limits for calloc other than "Whether the calloc, malloc, and realloc functions return a null pointer or a pointer to an allocated object when the size requested is zero (7.22.3)."
â€“Â Werner Henze
1 hour ago

As noted in DR-266, translation limits do not apply to runtime/allocated objects. So not sure if translation limits apply to calloc.
â€“Â P.P.
1 hour ago

@WernerHenze I added some references. Most of this is undefined because the standard does not say what happens, so it is difficult to back up things with references.
â€“Â Florian Weimer
1 hour ago

SIZE_MAX does not necessarily exceed the maximum object size. It is fine for an implementation to have a PTRDIFF_MAX that is 2^33 signed while at the same time it has a SIZE_MAX which is 2^32 unsigned. It's just very inconvenient for the compiler to have a type system like that, but the standard doesn't care [didn't even consider the problem].
â€“Â Lundin
48 mins ago

add a commentÂ |Â

up vote
0
down vote

For variable-length arrays on the stack, the rule about exceeding implementation limits resulting in undefined behavior is more obvious:

size_t length = SIZE_MAX / 2 + 2;
short object[length];

There is really nothing an implementation can do here, so it has to be undefined.

edited 1 hour ago

answered 1 hour ago

Florian Weimer

13.5k2942

For variable-length arrays on the stack, the rule about exceeding implementation limits resulting in undefined behavior is more obvious:

size_t length = SIZE_MAX / 2 + 2;
short object[length];

There is really nothing an implementation can do here, so it has to be undefined.

edited 1 hour ago

answered 1 hour ago

Florian Weimer

13.5k2942

edited 1 hour ago

answered 1 hour ago

Florian Weimer

13.5k2942

answered 1 hour ago

Florian Weimer

13.5k2942

answered 1 hour ago

Florian Weimer

13.5k2942

Can you back that up with references to the standard?
â€“Â Werner Henze
1 hour ago

And why do you bring in implementation limits? In J.3.12 in the C standard I do not see any implementation defined limits for calloc other than "Whether the calloc, malloc, and realloc functions return a null pointer or a pointer to an allocated object when the size requested is zero (7.22.3)."
â€“Â Werner Henze
1 hour ago

As noted in DR-266, translation limits do not apply to runtime/allocated objects. So not sure if translation limits apply to calloc.
â€“Â P.P.
1 hour ago

@WernerHenze I added some references. Most of this is undefined because the standard does not say what happens, so it is difficult to back up things with references.
â€“Â Florian Weimer
1 hour ago

SIZE_MAX does not necessarily exceed the maximum object size. It is fine for an implementation to have a PTRDIFF_MAX that is 2^33 signed while at the same time it has a SIZE_MAX which is 2^32 unsigned. It's just very inconvenient for the compiler to have a type system like that, but the standard doesn't care [didn't even consider the problem].
â€“Â Lundin
48 mins ago

add a commentÂ |Â

Can you back that up with references to the standard?
â€“Â Werner Henze
1 hour ago

And why do you bring in implementation limits? In J.3.12 in the C standard I do not see any implementation defined limits for calloc other than "Whether the calloc, malloc, and realloc functions return a null pointer or a pointer to an allocated object when the size requested is zero (7.22.3)."
â€“Â Werner Henze
1 hour ago

As noted in DR-266, translation limits do not apply to runtime/allocated objects. So not sure if translation limits apply to calloc.
â€“Â P.P.
1 hour ago

@WernerHenze I added some references. Most of this is undefined because the standard does not say what happens, so it is difficult to back up things with references.
â€“Â Florian Weimer
1 hour ago

SIZE_MAX does not necessarily exceed the maximum object size. It is fine for an implementation to have a PTRDIFF_MAX that is 2^33 signed while at the same time it has a SIZE_MAX which is 2^32 unsigned. It's just very inconvenient for the compiler to have a type system like that, but the standard doesn't care [didn't even consider the problem].
â€“Â Lundin
48 mins ago

Can you back that up with references to the standard?
â€“Â Werner Henze
1 hour ago

And why do you bring in implementation limits? In J.3.12 in the C standard I do not see any implementation defined limits for calloc other than "Whether the calloc, malloc, and realloc functions return a null pointer or a pointer to an allocated object when the size requested is zero (7.22.3)."
â€“Â Werner Henze
1 hour ago

As noted in DR-266, translation limits do not apply to runtime/allocated objects. So not sure if translation limits apply to calloc.
â€“Â P.P.
1 hour ago

@WernerHenze I added some references. Most of this is undefined because the standard does not say what happens, so it is difficult to back up things with references.
â€“Â Florian Weimer
1 hour ago

SIZE_MAX does not necessarily exceed the maximum object size. It is fine for an implementation to have a PTRDIFF_MAX that is 2^33 signed while at the same time it has a SIZE_MAX which is 2^32 unsigned. It's just very inconvenient for the compiler to have a type system like that, but the standard doesn't care [didn't even consider the problem].
â€“Â Lundin
48 mins ago

add a commentÂ |Â

draft saved

draft discarded

draft saved

draft discarded

Post as a guest

Name

Search This Blog

Iyfjky