473,405 Members | 2,261 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,405 software developers and data experts.

size_t or int for malloc-type functions?

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

jacob
Dec 31 '06
318 12671
On Fri, 26 Jan 2007 11:52:31 -0500, Wojtek Lerch wrote:
>"CBFalconer" <cb********@yahoo.comwrote in message
news:45**************@yahoo.com...
>Wojtek Lerch wrote:
>>>>Wojtek Lerch wrote:

>But is there an inexpensive way to compute the "width" of a
>given integer in C?
>>[...] In other words, I was looking for a
formula that takes a positive integer value X and produces W such
that X >(W-1) == 1.

I think rounding up log2 covers it.

Is it likely to be less expensive than an integer division?
For some reason I had assumed that you wanted to do the computation at
compile time, which I don't know how to achieve in C (it's fairly easy
in C++ instead). But if you are happy with a run-time calculation you
might want to adapt this one:
<http://boost.cvs.sourceforge.net/boost/boost/boost/pending/integer_log2.hpp?view=log>

Genny.
Jan 27 '07 #301
"Gennaro Prota" <ge***********@yahoo.coma écrit dans le message de news:
t9********************************@4ax.com...
On Fri, 26 Jan 2007 11:52:31 -0500, Wojtek Lerch wrote:
>>"CBFalconer" <cb********@yahoo.comwrote in message
news:45**************@yahoo.com...
>>Wojtek Lerch wrote:
>Wojtek Lerch wrote:

>>But is there an inexpensive way to compute the "width" of a
>>given integer in C?
>>>[...] In other words, I was looking for a
formula that takes a positive integer value X and produces W such
that X >(W-1) == 1.

I think rounding up log2 covers it.

Is it likely to be less expensive than an integer division?

For some reason I had assumed that you wanted to do the computation at
compile time, which I don't know how to achieve in C (it's fairly easy
in C++ instead). But if you are happy with a run-time calculation you
might want to adapt this one:
<http://boost.cvs.sourceforge.net/boost/boost/boost/pending/integer_log2.hpp?view=log>
Yak ! my keyboard is all slimey now ! Please keep this stuff out of
comp.std.c

Chqrlie.
Feb 9 '07 #302

"Wojtek Lerch" <Wo******@yahoo.caa écrit dans le message de news:
51*************@mid.individual.net...
"David R Tribble" <da***@tribble.comwrote in message
news:11**********************@m58g2000cwm.googlegr oups.com...
>Charlie Gordon wrote:
>>[...]
Another idea to avoid the division is to compare (n | s) to a value
known to
be less than square root of SIZE_MAX, such as
(((size_t)1 << (CHAR_BIT * sizeof(size_t) / 2)) - 1) but that might not
be
100% portable.

I don't think so. It'll make calloc( 256, 1 ) fail on a system with
SIZE_MAX=65535.
No, the test is not final: if it passes, we know the multiplication will not
overflow, if it fails, we must do the division to check for overflow.
For your example, 65535 / 256 will be larger than 1, therefore no overflow,
try to allocate malloc(256 * 1).
Also note that in my sample code, n is tested against 1 first, as it is a
very common case and cannot overflow.

Chqrlie.
Feb 9 '07 #303
"Harald van D?k" <tr*****@gmail.coma écrit dans le message de news:
11**********************@s48g2000cws.googlegroups. com...
Ben Bacarisse wrote:
>>
Surely CHAR_BIT * sizeof unsigned int does it for unsigned integers?
There are problem with "non-value" bits (probably the wrong term) in
signed integer types, but the OP did not specify.

Almost all signed and unsigned integer types may have padding bits.
That's in theory. In practice, none of them do ;-)

Chqrlie.


Feb 9 '07 #304
"Charlie Gordon" <ne**@chqrlie.orgwrote...
"Harald van D?k" <tr*****@gmail.coma écrit ...
>Almost all signed and unsigned integer types may have padding bits.
That's in theory. In practice, none of them do ;-)
There is at least one C implementation that has padding bits
in some of its integer representations.
Feb 9 '07 #305
"Charlie Gordon" <ne**@chqrlie.orgwrote in message
news:45*********************@news.free.fr...
"Wojtek Lerch" <Wo******@yahoo.caa écrit dans le message de news:
51*************@mid.individual.net...
>"David R Tribble" <da***@tribble.comwrote in message
news:11**********************@m58g2000cwm.googleg roups.com...
>>Charlie Gordon wrote:
[...]
Another idea to avoid the division is to compare (n | s) to a value
known to
be less than square root of SIZE_MAX, such as
(((size_t)1 << (CHAR_BIT * sizeof(size_t) / 2)) - 1) but that might not
be
100% portable.

I don't think so. It'll make calloc( 256, 1 ) fail on a system with
SIZE_MAX=65535.

No, the test is not final: if it passes, we know the multiplication will
not overflow, if it fails, we must do the division to check for overflow.
Ah, so your idea is to *sometimes* avoid the division, not always. That
makes sense -- when the amount of memory you're allocating is sufficiently
big, the cost of the division is negligible compared to the cost of the
memset(). I imagine that on a lot of systems, it's negligible no matter
what.
Feb 9 '07 #306
Charlie Gordon wrote:
"Harald van D?k" <tr*****@gmail.coma écrit dans le message de news:
11**********************@s48g2000cws.googlegroups. com...
>Ben Bacarisse wrote:
>>Surely CHAR_BIT * sizeof unsigned int does it for unsigned integers?
There are problem with "non-value" bits (probably the wrong term) in
signed integer types, but the OP did not specify.
Almost all signed and unsigned integer types may have padding bits.

That's in theory. In practice, none of them do ;-)
Except for the ones that do.
--
Clark S. Cox III
cl*******@gmail.com
Feb 9 '07 #307
"Douglas A. Gwyn" <DA****@null.neta écrit dans le message de news:
s4******************************@comcast.com...
"Charlie Gordon" <ne**@chqrlie.orgwrote...
>"Harald van D?k" <tr*****@gmail.coma écrit ...
>>Almost all signed and unsigned integer types may have padding bits.
That's in theory. In practice, none of them do ;-)

There is at least one C implementation that has padding bits
in some of its integer representations.
Which one is that ? Death Star 9k of sorts or some similar useless junk ?

Chqrlie
Feb 16 '07 #308
"Clark S. Cox III" <cl*******@gmail.coma écrit dans le message de news:
12*************@corp.supernews.com...
Charlie Gordon wrote:
>"Harald van D?k" <tr*****@gmail.coma écrit dans le message de news:
11**********************@s48g2000cws.googlegroups. com...
>>Ben Bacarisse wrote:
Surely CHAR_BIT * sizeof unsigned int does it for unsigned integers?
There are problem with "non-value" bits (probably the wrong term) in
signed integer types, but the OP did not specify.
Almost all signed and unsigned integer types may have padding bits.

That's in theory. In practice, none of them do ;-)

Except for the ones that do.
Interestingly, nobody is willing to shed light on these weird systems that
plague the standard with useless complex counterintuitive and universally
misunderstood garbage.

I pretend that architectures that require padding bits or trap
representations are a thing of the past that belong in computer museums.
Time has come the simplify and remove all that from future versions of the
standard. Who cares if new compilers cannot target obsolete hardware any
more in C201x mode ? Older versions will continue to support older
hardware, and new programs most likely cannot be made to fit on obsolete
hardware anyway.

Chqrlie.
Feb 16 '07 #309
Charlie Gordon wrote:
"Douglas A. Gwyn" <DA****@null.neta écrit dans le message de news:
s4******************************@comcast.com...
>"Charlie Gordon" <ne**@chqrlie.orgwrote...
>>"Harald van D?k" <tr*****@gmail.coma écrit ...
Almost all signed and unsigned integer types may have padding bits.
That's in theory. In practice, none of them do ;-)

There is at least one C implementation that has padding bits
in some of its integer representations.

Which one is that ? Death Star 9k of sorts or some similar useless junk ?
I seem to recall it's a Cray.

--
Chris "electric hedgehog" Dollin
"A facility for quotation covers the absence of original thought." /Gaudy Night/

Feb 16 '07 #310
Charlie Gordon wrote:
I pretend that architectures that require padding bits or trap
representations are a thing of the past that belong in computer museums.
Time has come the simplify and remove all that from future versions of the
standard. Who cares if new compilers cannot target obsolete hardware any
more in C201x mode ? Older versions will continue to support older
hardware, and new programs most likely cannot be made to fit on obsolete
hardware anyway.

Chqrlie.
Amen. Although honestly I think some of the regulars enjoy some of the stupid
limitations expressed above.
Feb 16 '07 #311
Charlie Gordon wrote:
>
.... snip ...
>
Interestingly, nobody is willing to shed light on these weird
systems that plague the standard with useless complex
counterintuitive and universally misunderstood garbage.

I pretend that architectures that require padding bits or trap
representations are a thing of the past that belong in computer
museums. Time has come the simplify and remove all that from
future versions of the standard. Who cares if new compilers
cannot target obsolete hardware any more in C201x mode ? Older
versions will continue to support older hardware, and new
programs most likely cannot be made to fit on obsolete hardware
anyway.
I would be very happy to have hardware with trap values, which
could automatically detect any use of uninitialized variables,
distinguish between malloced pointers and others, etc. However the
penny pinchers have pretty well driven such designs out of the mass
market, similarly the generic use of ECC.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Feb 16 '07 #312
Charlie Gordon wrote:
I pretend that architectures that require padding bits or trap
representations are a thing of the past that belong in computer museums.
Time has come the simplify and remove all that from future versions of the
standard. Who cares if new compilers cannot target obsolete hardware any
more in C201x mode ? Older versions will continue to support older
hardware, and new programs most likely cannot be made to fit on obsolete
hardware anyway.
It's not just older hardware, it's also modern hardware under
various real-world constraints. DSP comes to mind. Padding
bits are sometimes needed in the middle of a wide integer type,
in order to skip over the sign bit in the middle of a multiword
representation. If the sign bit had to be used as part of the
binary numeration system representation of the value, it could
force much slower run-time arithmetic, completely contrary to
the design goals of that hardware.

It is simply not necessary to pretend that all architectures
follow some simple-minded model. It is very rare that a C
programmer needs to worry about the existence of padding bits,
and in C99 we gave you a standard way to specify unpadded,
twos-complement integer types if you really have to have them.
(But if the implementation doesn't provide them, either your
program won't be usable on that platform, or you'll have to
provide an alternate algorithm anyway.)
Feb 16 '07 #313
CBFalconer wrote:
I would be very happy to have hardware with trap values, which
could automatically detect any use of uninitialized variables,
distinguish between malloced pointers and others, etc. However the
penny pinchers have pretty well driven such designs out of the mass
market, similarly the generic use of ECC.
Largely it's a matter of maximizing computational speed.
Almost any kind of checking does not come "free", from
that perspective. Generally, customers tend to be more
concerned over speed than in detecting poor program
quality as a side effect of execution.
Feb 16 '07 #314
"Douglas A. Gwyn" wrote:
CBFalconer wrote:
>I would be very happy to have hardware with trap values, which
could automatically detect any use of uninitialized variables,
distinguish between malloced pointers and others, etc. However the
penny pinchers have pretty well driven such designs out of the mass
market, similarly the generic use of ECC.

Largely it's a matter of maximizing computational speed. Almost
any kind of checking does not come "free", from that perspective.
Generally, customers tend to be more concerned over speed than in
detecting poor program quality as a side effect of execution.
ECC can cause a (very) slight degradation in performance, but not a
trap mechanism. ECC has to correct in line, but trapping can be
done on or during instruction completion, by separate paths, etc.
It's purely a passive monitoring of data paths.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Feb 17 '07 #315
"Douglas A. Gwyn" <DA****@null.neta écrit dans le message de news:
45***************@null.net...
Charlie Gordon wrote:
>I pretend that architectures that require padding bits or trap
representations are a thing of the past that belong in computer museums.
Time has come the simplify and remove all that from future versions of
the
standard. Who cares if new compilers cannot target obsolete hardware any
more in C201x mode ? Older versions will continue to support older
hardware, and new programs most likely cannot be made to fit on obsolete
hardware anyway.

It's not just older hardware, it's also modern hardware under
various real-world constraints. DSP comes to mind. Padding
bits are sometimes needed in the middle of a wide integer type,
in order to skip over the sign bit in the middle of a multiword
representation. If the sign bit had to be used as part of the
binary numeration system representation of the value, it could
force much slower run-time arithmetic, completely contrary to
the design goals of that hardware.
Real world DSPs don't do that, and such lack of symmetry is actually more
expensive to implement in hardware and more painful to support in software .
It is simply not necessary to pretend that all architectures
follow some simple-minded model. It is very rare that a C
programmer needs to worry about the existence of padding bits,
and in C99 we gave you a standard way to specify unpadded,
twos-complement integer types if you really have to have them.
(But if the implementation doesn't provide them, either your
program won't be usable on that platform, or you'll have to
provide an alternate algorithm anyway.)
Why even bother to standardize such oddities ?
Simple concepts are not necessarily simple-minded.
Useless complexity breeds broken and bloated software.

Chqrlie.
Feb 18 '07 #316
On Sun, 18 Feb 2007 06:20:31 +0100, "Charlie Gordon"
<ne**@chqrlie.orgwrote:
>"Douglas A. Gwyn" <DA****@null.neta écrit dans le message de news:
45***************@null.net...
>Charlie Gordon wrote:
>>I pretend that architectures that require padding bits or trap
representations are a thing of the past that belong in computer museums.
Time has come the simplify and remove all that from future versions of
the
standard. Who cares if new compilers cannot target obsolete hardware any
more in C201x mode ? Older versions will continue to support older
hardware, and new programs most likely cannot be made to fit on obsolete
hardware anyway.

It's not just older hardware, it's also modern hardware under
various real-world constraints. DSP comes to mind. Padding
bits are sometimes needed in the middle of a wide integer type,
in order to skip over the sign bit in the middle of a multiword
representation. If the sign bit had to be used as part of the
binary numeration system representation of the value, it could
force much slower run-time arithmetic, completely contrary to
the design goals of that hardware.

Real world DSPs don't do that, and such lack of symmetry is actually more
expensive to implement in hardware and more painful to support in software .
if some variable has the need of pad-bits and there is not the problem
on memory size, it is possible to use 2 variables "contigui" one for
store and one for pading bits
>It is simply not necessary to pretend that all architectures
follow some simple-minded model. It is very rare that a C
programmer needs to worry about the existence of padding bits,
and in C99 we gave you a standard way to specify unpadded,
twos-complement integer types if you really have to have them.
(But if the implementation doesn't provide them, either your
program won't be usable on that platform, or you'll have to
provide an alternate algorithm anyway.)

Why even bother to standardize such oddities ?
Simple concepts are not necessarily simple-minded.
Useless complexity breeds broken and bloated software.

Chqrlie.
Feb 18 '07 #317
On Sun, 18 Feb 2007 06:20:31 +0100, "Charlie Gordon"
<ne**@chqrlie.orgwrote:
>"Douglas A. Gwyn" <DA****@null.neta écrit dans le message de news:
45***************@null.net...
>Charlie Gordon wrote:
>>I pretend that architectures that require padding bits or trap
representations are a thing of the past that belong in computer museums.
Time has come the simplify and remove all that from future versions of
the
standard. Who cares if new compilers cannot target obsolete hardware any
more in C201x mode ? Older versions will continue to support older
hardware, and new programs most likely cannot be made to fit on obsolete
hardware anyway.

It's not just older hardware, it's also modern hardware under
various real-world constraints. DSP comes to mind. Padding
bits are sometimes needed in the middle of a wide integer type,
in order to skip over the sign bit in the middle of a multiword
representation. If the sign bit had to be used as part of the
binary numeration system representation of the value, it could
force much slower run-time arithmetic, completely contrary to
the design goals of that hardware.

Real world DSPs don't do that, and such lack of symmetry is actually more
expensive to implement in hardware and more painful to support in software .
if some variable has the need of pad-bits and there is not the problem
on memory size, it is possible to use 2 variables "contigui" one for
store and one for pading bits
>It is simply not necessary to pretend that all architectures
follow some simple-minded model. It is very rare that a C
programmer needs to worry about the existence of padding bits,
and in C99 we gave you a standard way to specify unpadded,
twos-complement integer types if you really have to have them.
(But if the implementation doesn't provide them, either your
program won't be usable on that platform, or you'll have to
provide an alternate algorithm anyway.)

Why even bother to standardize such oddities ?
Simple concepts are not necessarily simple-minded.
Useless complexity breeds broken and bloated software.

Chqrlie.
Feb 18 '07 #318
"Charlie Gordon" <ne**@chqrlie.orgwrote in message
news:45**********************@news.free.fr...
Why even bother to standardize such oddities ?
I already explained that. Some architectures need the latitude
in order to conform to the standard and yet generate fast code.
Simple concepts are not necessarily simple-minded.
They are when you insist that they be applied where they don't fit.
Useless complexity breeds broken and bloated software.
Platitudes are no substitute for thought. If a C implementor
doesn't need to embed padding bits in a datatype, he certainly
won't be doing so -- no different from your simple model.
On the other hand, if he needs to reserve some padding bits
to fit the particular architectural properties, there would be
complexity added (and execution speed lost) if he had to force
the representation to fit the simple model (since e.g. the sign bit
in a signed-magnitude representation is hard to use as part of
a binary numeration for the magnitude) and there is a very real
danger that the implementor would opt to not conform on that
point, which would very likely lead to further nonconformance,
and which would be doing the programmer no good if the
standard guarantee of no padding were being trusted in some
essential way. *That* would be broken software. Nothing
is broken by allowing for the possibility of padding bits (which
normally doesn't even have to be thought about), whether or
not padding bits actually occur.
Feb 18 '07 #319

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Adam Warner | last post by:
Hi all! When dealing with dynamically adjusted objects are you ever concerned that you'll double the requested size of the object and overflow size_t so that the requested size e.g. becomes...
34
by: Alawna | last post by:
Hi, i was reading a chapter about c pointers in "c++builder complete reference" and it is said there that malloc returns a pointer to the start of the memory allocated but i see the prototype of...
40
by: Confused User | last post by:
I am curious what the origins of size_t are. I see that it is usually typedef'd to be the native integer size of a particular machine. I also see that routines like strncpy(char *t, const char *s,...
18
by: rayw | last post by:
I used to believe that size_t was something to do with integral types, and the std. Something along the lines of .. a char is 8 bits, a int >= a char a long >= int
12
by: Alex Vinokur | last post by:
Why was the size_t type defined in compilers in addition to unsigned int/long? When/why should one use size_t? Alex Vinokur email: alex DOT vinokur AT gmail DOT com...
20
by: ramasubramanian.rahul | last post by:
hi folks i have a peculiar problem. i have to allocate more than size_t consequtive bytes on a system . after i do a malloc .. i am unable to do a realloc because it takes size_t as a new size...
13
by: sam_cit | last post by:
Hi Everyone, I was looking at the function prototype of malloc() function in stdlib.h and i found that to be, void *malloc(size_t size); so what is size_t is it a pre-defined typedef to...
73
by: Yevgen Muntyan | last post by:
Hey, I was reading C99 Rationale, and it has the following two QUIET CHANGE paragraphs: 6.5.3.4: "With the introduction of the long long and extended integer types, the sizeof operator may...
409
by: jacob navia | last post by:
I am trying to compile as much code in 64 bit mode as possible to test the 64 bit version of lcc-win. The problem appears now that size_t is now 64 bits. Fine. It has to be since there are...
21
by: pereges | last post by:
For eg : struct mesh { size_t nvert; /* number of vertices */ size_t ntri; /* number of triangles */ ..... }; The reason I want to use size_t is because I've read that it is
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.