Re: size_t or int for malloc-type functions?

"jacob navia" <jacob@xxxxxxxxxxxxxxxx> wrote in message
news:4597b950$0$27413$ba4acef3@xxxxxxxxxxxxxxxxx

Rcently I posted code in this group, to help a user
that asked to know how he could find out the size of
a block allocated with malloc.

As always when I post something, the same group
of people started to try to find possible errors,
a harmless passtime they seem to enjoy.

One of their remarks was that I used "int" instead of
"size_t" for the input of my allocator function.

As I explained, I prefer a signed type to the
unsigned size_t because small negative number will be
confused with huge integers when interpreted as unsigned.

I researched a bit the subject, and I found a type

ssize_t

The name is defined for instance in
http://www.delorie.com/gnu/docs/glibc/libc_239.html

Data Type: ssize_t
This data type is used to represent the sizes of blocks that can be
read or written in a single operation. It is similar to size_t, but must
be a signed type.

Another reference to this type appears in:
http://bochs.sourceforge.net/cgi-bin/lxr/ident?i=ssize_t
with
#define ssize_t long

This concern with the usage of an unsigned type that can be
easily lead to errors (of course only for people that do
make errors like me...) is also expressed in the document
ISO/IEC JTC1 SC22 WG14 N1135 :
"Specification for Safer, More Secure C Library Functions"
where they propose:

Extremely large object sizes are frequently a sign that an object?s size
was calculated incorrectly. For example, negative numbers appear as very
large positive numbers when converted to an unsigned type like size_t.

Also, some implementations do not support objects as large as the
maximum value that can be represented by type size_t.

For those reasons, it is sometimes beneficial to restrict the range of
object sizes to detect programming errors.

They propose having an unsigned rsize_t, but a macro RSIZE_MAX that
would limit the range of the object size.

I post this to document why having an "int" as an argument to a
malloc-type function is not such a bad idea.

Your opinion may differ.

The problem with int is that it throws away half the address space.
This is a *big* issue with 16-bit address spaces, but of course
such machines are largely relegated to embedded systems, and small
ones at that. Nevertheless, I regularly need to deal with objects
bigger than half the address space even today, perhaps because I
write so much systems code. So I find the choice of slicing the
address space in half arbitrary and potentially dangerous.

That's why I pushed for the notion of an RSIZE_MAX to accompany
the unsigned rsize_t that Microsoft put forth in TR 24731. You
can set it to:

-- (size_t)-1 >> 2 if you want the same protection as a signed
byte count

-- some other value if you know how big objects can really be,
and get maximum protection against silly sizes

-- (size_t)-1 if you want to turn the damned checking off

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


.

Relevant Pages

  • Re: Cipher Lab / Syntech
    ... this is not Google Groups. ... The "simple" library without malloc is needed because I was told ... void foo { ... int dprintf { ...
    (comp.lang.c)
  • Re: why still use C?
    ... I was talking about the malloc expression, ... >>the assignment expression. ... >>enum parameter is not an error in C, but in my coding style it's a mistake). ... I took it you meant "int where an enum" is expected, ...
    (comp.lang.c)
  • Re: malloc + 4??
    ... >>information into the malloc is solid. ... The variable inSize is a plain int and has ... > the loop will never terminate. ... > yet also return the special marker value EOF. ...
    (comp.lang.c)
  • Re: Unknown function
    ... How can the function call of 'malloc' work at all if it is unknown? ... I thought that each function that is unknown to the compiler at a specific ... returns an int. ... problem since malloc actually takes size_t and returns void *. ...
    (comp.lang.c)
  • Re: Dynamically-allocated Multi-dimensional Arrays
    ... If the malloc() succeeds, ... a "variable length array" or VLA. ... of int" instad of "pointer to VLA of int"). ... struct int_matrix *mp; ...
    (comp.lang.c)