*headdesk*

[stas]

So, you've got a code in C that needs to allocate X objects of size Y. So, you start with malloc(X*Y). Then you discover X*Y may produce overflow, so you make function alloc(X, Y) that checks for overflows.

And then of course everybody starts using it as alloc(1, X*Y). Because it's the same thing, right?

Comments

[anatoly borodin (from livejournal.com)]

*calloc

[stas]

calloc тоже так используют, конечно, calloc(1, size*count). Сплошь и рядом. Но тут специально функцию в API сделали для того, чтобы не было overflow, и всё не впрок.

[ak_47]

Это что-то из мира embedded? Потому что аллокация размеров даже близких к величинам где начинается overflow of X*Y выглядит странно, по меньшей мере.

[kika.livejournal.com]

Странные люди, я всегда calloc() использовал именно как положоно по уставу.

[henic.livejournal.com]

Какие злые люди. :)

[sorhed.livejournal.com]

Язык программирования С должен быть разрушен.

[laoxia.livejournal.com]

в твоем каменте чувствуется обида и зависть, молодой джавист

[valshooter.livejournal.com]

And what's not the same here? Either we have enough memory to allocate or we don't.

Pardon my ignorance (have very little C experience).

[pilpilon.livejournal.com]

you could have enough memory but not enough integers to count it

[trurle.livejournal.com]

Нет, это люди неспособные программировать, должны быть направлены на соответствующие их скромным способностям рабочие места. Впрочем, оно так и происходит.

[trurle.livejournal.com]

Is there are an environment where sizeof(void*) is less than sizeof(size_t)?

[pilpilon.livejournal.com]

I've never dealt with anything like this, but could be, could't it?

[trurle.livejournal.com]

Stranger things happened, indeed.

[manta.livejournal.com]

sizeof() should return long. Problem solved.

[valshooter.livejournal.com]

so basically when I'm calling malloc(X*Y) I need to have X*Y bytes for data + X*4 for pointers?

(4 depends on architecture, I guess)

[irene221b.livejournal.com]

The following code excerpt from OpenSSH 3.3 demonstrates a classic case of integer overflow:

nresp = packet_get_int();
if (nresp > 0) {
response = xmalloc(nresp*sizeof(char*));
for (i = 0; i < nresp; i++)
response[i] = packet_get_string(NULL);
}
If nresp has the value 1073741824 and sizeof(char*) has its typical value of 4, then the result of the operation nresp*sizeof(char*) overflows, and the argument to xmalloc() will be 0. Most malloc() implementations will happily allocate a 0-byte buffer, causing the subsequent loop iterations to overflow the heap buffer response.

[valshooter.livejournal.com]

Thank you.

[avnik.livejournal.com]

и джаву тоже разрущить, оставить только лисп и haskell

[stas]

sizeof should return size_t, as it does, but that helps nothing. Integer overflow is still there. Especially if you add common case of X*Y+Z.

[manta.livejournal.com]

So why a size_t isn't 64-bit on 64-bit systems?

[stas]

It is. Integer overflows exist on any fixed-size number system though (that allows overflows of course, like C does).

[stas]

Если не C, то кот?!

[sorhed.livejournal.com]

C можно оставить: 1) для эмбеда (раньше всё железо было как эмбед, но сейчас-то...) 2) для ковыряния ядра линукса, потому что оно с нами надолго (несмотря на Erlang on Xen и тому подобные замечательные штуки), 3) для исправления секьюрити-багов, которые наоставляли поколения предыдущих C-кодеров.

Всё, что работает на современных компьютерах и серверах, должно писаться не на C. На выбор: Java/Scala/Erlang/Go/Rust/OCaml/любой другой язык с managed memory.

[sorhed.livejournal.com]

Джава и так скоро умрёт. А си вот что-то не собирается, хотя вреда от него больше.

[sorhed.livejournal.com]

Кто без сегфолта, пусть первый бросит в меня камень.