malloc类型函数的size_t或int？ [英] size_t or int for malloc-type functions?
问题描述
Rcently我在这个小组中发布了代码，以帮助用户
，让他知道如何找出分配了malloc的
a块的大小。 />
和我发布的东西一样，同一群人
的人开始试图找到可能的错误，
a看起来无害的通行时间享受。
他们的一句话是我使用了int而不是
" size_t"输入我的分配器功能。
正如我解释的那样，我更喜欢签名类型为
unsigned size_t，因为小的负数将是
被解释为无符号时与大整数混淆。
我研究了一下这个主题，我找到了一个类型
ssize_t
名称的定义例如在
http://www.delorie.com/gnu/docs/glibc/libc_239.html
数据类型：ssize_t
此数据类型用于表示可在单个操作中读取或写入的块的大小。它类似于size_t，但必须
是签名类型。
此类型的另一个引用出现在：
http://bochs.sourceforge.net/cgi-bin...dent ？i = ssize_t
with
#define ssize_t long
这与使用无符号类型有关这可能是
容易导致错误（当然只适用于那些做出像我这样的错误的b $ b）也会在文件中表达
ISO / IEC JTC1 SC22 WG14 N1135：
更安全，更安全的C库函数规范
他们建议：
极大的物体尺寸通常表示物体的大小
计算错误。例如，当转换为像size_t这样的无符号类型时，负数显示为非常大的正数。
此外，某些实现不支持大对象as
最大值，可以用size_t类型表示。
由于这些原因，限制
$的范围有时是有益的。 b $ b对象大小来检测编程错误。
他们建议使用未签名的rsize_t，但是宏的RSIZE_MAX
会限制对象大小的范围。
我发布这个来记录为什么有一个int作为
malloc-type函数的一个参数并不是一个坏主意。
您的意见可能有所不同。
jacob
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
推荐答案
" jacob navia" < ja *** @ jacob.remcomp.frwrote in message
news：45 *********************** @ news .orange.fr ...
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...
Rcently我在这个组中发布了代码，以帮助用户
，让他知道他怎么做找出用malloc分配的
a块的大小。
像往常一样，当我发布一些东西时，同一群人
的人开始试图找到可能的错误，
a他们似乎很享受无害的通行时间。
他们的一个评论是我使用了int而不是
" size_t"输入我的分配器功能。
正如我解释的那样，我更喜欢签名类型为
unsigned size_t，因为小的负数将是
被解释为无符号时与大整数混淆。
我研究了一下这个主题，我找到了一个类型
ssize_t
名称的定义例如在
http://www.delorie.com/gnu/docs/glibc/libc_239.html
数据类型：ssize_t
此数据类型用于表示可在单个操作中读取或写入的块的大小。它类似于size_t，但必须
是签名类型。
此类型的另一个引用出现在：
http://bochs.sourceforge.net/cgi-bin...dent ？i = ssize_t
with
#define ssize_t long
这与使用无符号类型有关这可能是
容易导致错误（当然只适用于那些做出像我这样的错误的b $ b）也会在文件中表达
ISO / IEC JTC1 SC22 WG14 N1135：
更安全，更安全的C库函数规范
他们建议：
极大的物体尺寸通常表示物体的大小
计算错误。例如，当转换为像size_t这样的无符号类型时，负数显示为非常大的正数。
此外，某些实现不支持大对象as
最大值，可以用size_t类型表示。
由于这些原因，限制
$的范围有时是有益的。 b $ b对象大小来检测编程错误。
他们建议使用未签名的rsize_t，但是宏的RSIZE_MAX
会限制对象大小的范围。
我发布这个来记录为什么有一个int作为一个
malloc-type函数的参数并不是一个坏主意。
您的意见可能有所不同。
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.
int的问题在于它丢弃了一半的地址空间。
这是一个带有16位地址的*大*问题空间，但当然
这样的机器很大程度上已经降级到嵌入式系统，并且很小的就是这些机器。尽管如此，我经常需要处理大于地址空间一半的对象，或许是因为我写了这么多系统代码。所以我发现可以选择将
地址空间切成两半并且有潜在危险。
这就是为什么我推动了RSIZE_MAX的概念陪同
微软在TR 24731中提出的未签名的rsize_t。你
可以设置为：
- （ size_t）-1> 2如果你想要像签名的那样保护
字节数
- 如果你知道大的物体有多大可以真的是，
并获得最大程度的保护，防止愚蠢的尺寸
- （size_t）-1如果你想要关闭该死的检查
PJ Plauger
Dinkumware，Ltd。
http://www.dinkumware.com
PJ Plaugeraécrit：
P.J. Plauger a écrit :
>
int的问题在于它丢弃了一半的地址空间。
这是一个带有16位地址空间的*大*问题，但当然这些机器很大程度上都归功于嵌入式系统，而且这些机器很少.b
。
>
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.
是的。我认为这也是一个问题，但是，在这么小的系统中，ram的数量也会非常小，而且情况保持不变。
在我去年使用的DSP中，RAM的总量是
4K，所以sizeof（int）16位我有足够的空间
无论如何:-)
Yes. I see this too as a problem, but then, in such small
systems, the amount of ram tends to be very small too, and
the situation remains the same.
In a DSP I used last year the total amount of RAM was
4K, so a sizeof(int) 16 bits I had plenty of space
anyway :-)
尽管如此，我经常需要处理物品
大于一半即使在今天的地址空间，也许是因为我写了这么多系统代码。
Nevertheless, I regularly need to deal with objects
bigger than half the address space even today, perhaps because I
write so much systems code.
在这种情况下，有两组malloc函数可能很有用
可能，一个用于小分配，另一个用于小分配big
。
In that case it can be useful to have two sets of malloc functions
maybe, one for the small allocations, and another for the "big"
ones.
所以我找到了将
地址空间切成两半的选择任意且有潜在危险。
这就是为什么我推动RSIZE_MAX的概念伴随着微软在TR 24731中提出的未签名的rsize_t
你可以将
设置为：
- （size_t）-1> 2如果你想要一个像签名一样的保护
字节数
- 如果你知道大的物体真的有多大的其他价值，
并获得最大程度的保护，防止愚蠢的尺寸
- （size_t）-1如果你想关闭该死的检查
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
检查可能会令人讨厌，但它可以有时是一种优势。它的价格取决于具体情况。
感谢您的投入。
jacob
Checking can be a nuisance but it can be an advantage sometimes. It
depends on the situation.
Thanks for your input.
jacob
jacob navia说：
< snip>
jacob navia said:
<snip>
正如我解释的那样，我更喜欢签名类型的
unsigned size_t，因为当被解释为无符号时，小的负数将与巨大的整数混淆。
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.
为什么你需要一个小的负数作为malloc的参数？你试图分配负数的内存是否为
？
Why would you need a small negative number as an argument to malloc? Are you
trying to allocate a negative amount of memory?
>
我研究了一下主题，我找到了一个类型
ssize_t
名称的定义例如在
http://www.delorie.com/gnu/docs/glibc/libc_239.html
它是POSIX类型，而不是C类型。试试comp.unix.programmer。
< snip>
-
Richard Heathfield
Usenet是一个奇怪的地方 - dmr 29/7/1999
http://www.cpax.org.uk
电子邮件：rjh在上述域名中， - www。
It''s a POSIX type, not a C type. Try comp.unix.programmer.
<snip>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
这篇关于malloc类型函数的size_t或int？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
