How much memory does malloc(0) allocate?

[BGB]

Almost every integer should be int. Since integers usually end up indexing
arrays (even a char, when you think about it, will probably eventually
end up as an index into a glyph table of some sort), that means that int
needs to be able to index an arbitrary array. Then you don't need any other
types, except to save memory, or for a few algorithms that need huge integers.

We don't need twenty plus integer types in C.

well, there is a problem:
often the size of these integer types is relevant for things like
file-formats, and often for memory use.

there is actually lots of code which will break at present if 'int' is
anything other than 32 bits.

but, OTOH, sometimes one may need to deal with arrays larger than 2 or
4G on 64-bit targets, and it is still mostly overkill for characters.


also annoying is the still not yet universal availability of 'stdint.h', ...


then there are other annoyances:
there is still no good way to have 'specific' format integer types, for
example:
"32-bit signed twos complement big-endian" or "64-bit unsigned twos
complement little-endian".

as-is, the majority of code for reading/writing data from files often
ends up with code for jerking around with getting numbers into the
correct endianess, where if the exactly format of the numbers was
settled, a person could safely read/write structs more directly, and not
need a bunch of logic for encoding/decoding any contained integers.

but, even if added to the standards, it would probably be a decade or
more before it had widespread implementation support, ...

so, alas, no good solutions to the problems of integers.


FWIW: in my scripting language, it is possible to qualify the endianess
of integer types, but made partly pointless in that I don't generally
use it for file IO (and the VM still falls a fair bit short of being
performance competitive with a C compiler, *1). nevermind some still
ugly language-design issues (*2), ...

*1: the current JIT also mostly just spits out threaded code, and the
current IR still isn't really ideal for what is needed for good
performance (mostly it is a time/priority issue).

*2: ugly AS3-like declaration syntax, semantics issues, sometimes
excessive verbosity, ...


or such...

 

[Ian Collins]

Almost every integer should be int. Since integers usually end up indexing
arrays (even a char, when you think about it, will probably eventually
end up as an index into a glyph table of some sort), that means that int
needs to be able to index an arbitrary array. Then you don't need any other
types, except to save memory, or for a few algorithms that need huge integers.

We don't need twenty plus integer types in C.

There speaks someone who has never worked in the embedded world (most C
these days) or on drivers or any other in memory data applications.

 

[Keith Thompson]

Almost every integer should be int. Since integers usually end up indexing
arrays (even a char, when you think about it, will probably eventually
end up as an index into a glyph table of some sort), that means that int
needs to be able to index an arbitrary array. Then you don't need any other
types, except to save memory, or for a few algorithms that need huge integers.

We don't need twenty plus integer types in C.

I was talking about what C has, not what it should have.

I disagree with your point, but even if I agreed it would still be a bad
idea to confuse the terms "int" and "integer".

 

[glen herrmannsfeldt]

(snip)

My point was that size_t is unsigned. I was not
thinking about the actual size of size_t. I would
prefer all modern day usage of this kind of data
to be 64 bit. At least.

So, for the real question, does C require size_t to
be unsigned?

For 32 bit systems with 24 or 31 bit addressing, it could just as
well be signed and still address (or size) everything.

Many systems with 32 bit addresses save enough addressing space
for the OS, such that user space could be sized in 31 bits.

-- glen

 

[James Kuyper]

(snip)


So, for the real question, does C require size_t to
be unsigned?

Yes:
"The header <stddef.h> defines the following macros and declares the
following types.
....
size_t

which is the unsigned integer type of the result of the sizeof
operator;" 7.19p1-2

 

[Phil Carmody]

Sigh... That's the level of debate you prefer?

Let's start with clearly defined or otherwise unambiguous terms, and
see if we can progress from there.

Phil

 

[David Thompson]

Probably better style but not required.

What's a "solid" assert? assert() is one of the most ephemeral
bits of code it's possible to write in C.

I'd bet he meant the clear and visible abort() caused by a failed
assert() -- often with a coredump or somesuch -- instead of continuing
without error indication or at most a warning which people ignore.
This is often called fail-fast or fail-hard.

 

[Eric Sosman]

Probably better style but not required.

For his purpose (to wit: Treating an attempted zero-length
allocation as an assertion failure), it's required.

 

[Kleuske]

Probably better style but not required.

I'd bet he meant the clear and visible abort() caused by a failed
assert() -- often with a coredump or somesuch -- instead of continuing
without error indication or at most a warning which people ignore. This
is often called fail-fast or fail-hard.

Thank you.

 

[Kleuske]

For his purpose (to wit: Treating an attempted zero-length
allocation as an assertion failure), it's required.

Correct, apart from the "he"-issue (still female last time i checked). I
considered that implied, but if you want to state that explicitly, that's
fine, too.

Addendum: It does no make much of a difference, but it is nicer not to
allocate first and assert() afterwards. "Required", therefore, is a bit
strong, but i would certainly not accept it in a code review.