关于malloc套管的问题 [英] Question regarding malloc casing
问题描述
大家好，
我有一个关于malloc返回值的问题。
我了解到我们不应该投回报malloc的价值因为
它是bug hider。
但我的问题如下所述。
让我说我没有包括stdlib.h在我的程序中我仍在使用
malloc所以编译器将抛出warring因为没有原型
编译器假定该函数被声明为extern int
malloc（）。假设我忽略了那个警告但没有投出回报
值
现在在链接时间我的代码将链接到确切的
malloc的实现返回void *。所以在这种情况下会是一个问题吗？
问候，
Somenath
somenath< somenath ... @ gmail.comwrote：
大家好，
我有一个关于malloc返回值的问题。
我了解到我们不应该转换malloc的返回值
因为它是臭虫隐藏。
但我的问题如下所述。
让我说我还没有把stdlib.h包含在我的程序中我还是
我正在使用malloc所以编译器将抛出warring，因为原型编译器假定函数被声明为
extern int malloc（）。
。
如果你忽略了这个bug，那么bug仍然存在。即使没有
的解释，我也不能成为Good Thing（TM）。
假设我忽略了那个警告并且没有投出回报
值
现在在链接时间我的代码将链接到malloc的确切
实现，返回void *。那么在这个
案例中会出现问题吗？
是的。
在典型的motorola 68k工具上，图书馆将返回
返回指针在A0中，而你的代码在D0中需要
。
在基于堆栈的实现中，void *是64位
和int是32位，你可能会发现库函数将会b / b
清理过多堆栈。
事实是，未能声明原型很多人都喜欢用C语言表达这样的弱点b / b
告诉他们的编译器错误调用
unprototyped命名函数，即使它打破了编译器的符合性。有些甚至可以使用
C ++而不是C.
-
Peter
12月2日上午10：02，Peter Nilsson< ai ... @ acay.com.auwrote：
somenath< ; somenath ... @ gmail.comwrote：
大家好，
I有一个关于malloc的返回值的问题。
我了解到我们不应该转换malloc
的返回值，因为它是bug hider。
但我的问题如下所述。
假设我没有在程序中包含stdlib.h我仍然使用malloc所以编译器会抛出warring因为使用
原型编译器假定函数被声明为
作为extern int malloc（）。
如果你忽略了这个bug，那么bug仍然存在。即使没有
的解释，我也不能成为Good Thing（TM）。
假设我忽略了那个警告并且没有投出回报
值
现在在链接时间我的代码将链接到malloc的确切
实现，返回void *。那么在这个
案例中会出现问题吗？
是的。
在典型的motorola 68k工具上，图书馆将返回
返回指针在A0中，而你的代码在D0中需要
。
非常感谢你的回复。我只是理解这一点。
使用原型编译器假设malloc返回int。但是在链接时间它将链接到正确的malloc定义，
返回（void *）。然后在运行时它将返回（void
*）。我的理解错了吗？
基于堆栈实现其中void *是64位
和int是32位，你可能会发现库函数将
清理太多堆栈。
我也没有得到这一点。怎么回事？你能否请b
请说明这一点。
事实是，未能宣布原型被视为这样的
$很多人喜欢用C语言表达b $ ba
告诉他们的编译器调用
非原型命名函数是错误的，即使它打破了
编译器的一致性。有些甚至可以使用
C ++而不是C.
好的。这是我理解的唯一一点。
somenath< somenath ... @ gmail.comwrote：
Peter Nilsson< ai ... @ acay.com.auwrote：
somenath< somenath ... @ gmail.comwrote：
我了解到我们不应该转换
malloc的返回值，因为它是bug hider。 ...
让我说我没有在我的程序中包含stdlib.h
我仍在使用malloc所以编译器会抛出warring
因为使用原型编译器假定
函数声明为extern int malloc（）。
如果你忽略了这个bug，那么bug仍然存在。即使没有
的解释，我也不能成为Good Thing（TM）。
假设我忽略了那个警告并且没有投出
返回值
现在在链接时，我的代码将链接到malloc的确切的
实现，返回void *。那么在
这种情况下会出现问题吗？
是的。
在典型的motorola 68k工具上，图书馆将返回
返回指针在A0中，而你的代码在D0中期望为
。
非常感谢您的回复。我只是明白了这一点。
。
请谷歌搜索中文私语。
C通常作为一系列流程实施
（大致遵循
标准中规定的翻译阶段。）这些流程中的每一个通常都带有信任元素。
编译器信任程序员。
链接器信任编译器。
主机系统信任链接器。
弱点在于开始。如果你骗到
编译器，每个人都相互信任，直到程序实际运行并且问题浮出水面。
使用原型编译器假设malloc返回
int。
是的，它会产生一些汇编程序_assumes_
类型的值，当它调用malloc是一个int时。
在某些系统上，这意味着假设它来自数据
寄存器，而不是地址寄存器。在其他系统上
它假设需要在堆栈上分配32位，
而不是64.在其他系统上，它假设它将
抵达起居室而不是车库。
不同的系统有不同的呼叫约定。一些
系统使用机器寄存器，一些使用硬件堆栈，
其他有两者的组合，还有一些使用
甚至更狡猾的机制。
但基本的一点是，如果
编译器使用了这些调用
约定（通常非常快）错了。
正确的唯一线索来自程序员。
但在链接时间内它将被链接到正确的
malloc的定义，返回（void *）。然后在
运行时它将返回（void *）。
但是_where_返回此void *至关重要。由于
编译器已被告知通过一个完全
不同的类型，所以不能保证它产生的汇编
代码将正确匹配
函数实际返回值的方式。
我的理解错了吗？
您错过了C是静态
类型语言的观点。函数的返回类型不是在运行时确定的，而是在编译时固定的。在这方面，
，C与许多现代语言不同，
喜欢在运行时弄清楚。
呼叫a功能就像一个消息系统。你
将参数传递给函数，并返回一个
给你（如果它是像malloc这样的非空函数）。
如何通过
预付款同意这些消息的传达方式。你偏离了约定的通信线路
，这将带来你的危险。
想象一下，你发送快递给我发消息
to Malloc Pty Ltd要求提供内存。你
告诉你的助手拿到退回的包裹
巴士总站的15号门。但是Malloc Pty有限公司总是在12号门提供
。所以你错过了这个包。
基于堆栈的实现，其中void *是64
位和int是32位，你可能会发现库
函数会清理太多的堆栈。
我也没有得到这一点。这是怎么回事？
能不能再详细说明这一点了。
假设您将一辆家用旅行车送到Malloc Pty
有限公司领取包裹。然后，他们将2吨
包裹放回到后面，然后你的轮胎爆炸，然后你甚至离开了捡拾码头。如果您同意
发送一辆小型实用卡车，您就发送了一辆旅行车，并且现在已经支付了这笔费用。
-
彼得
Hi All,
I have one question regarding return value cast of malloc.
I learned that we should not cast the return value of malloc because
it is bug hider.
But my question is as mentioned bellow .
Lets say I have not included stdlib.h in my program still I am using
malloc so compiler will throw warring because with out prototype
compiler assumes that function is declared as extern int
malloc() .Suppose I ignore that warning and did not cast the return
value
Now during linking time my code will be linked to exact
implementation of malloc which returns void * . So in this case will
it be a problem?
Regards,
Somenath
somenath <somenath...@gmail.comwrote:Hi All,
I have one question regarding return value cast of malloc.
I learned that we should not cast the return value of malloc
because it is bug hider.
But my question is as mentioned bellow .
Lets say I have not included stdlib.h in my program still I
am using malloc so compiler will throw warring because with
out prototype compiler assumes that function is declared
as extern int malloc().If you ignore the bug, the bug remains. Even without an
explanation, I can''t this as ever being a Good Thing (TM).
Suppose I ignore that warning and did not cast the return
value
Now during linking time my code will be linked to exact
implementation of malloc which returns void * . So in this
case will it be a problem?Yes.
On a typical motorola 68k implementaion, the library will
return the pointer in A0, whereas your code will expect
it in D0.
On a stack based implementation where void * is 64 bits
and int is 32-bits, you may find the library function will
clean up too much stack.
Fact is, failing to declare a prototype is seen as such
a weakness in the C language that many people prefer to
tell their compilers to make it an error to call an
unprototyped named function, even though it breaks the
conformance of the compiler. Some even go so far as use
C++ instead of C.
--
Peter
On Dec 2, 10:02 am, Peter Nilsson <ai...@acay.com.auwrote:somenath <somenath...@gmail.comwrote:Hi All,
I have one question regarding return value cast of malloc.
I learned that we should not cast the return value of malloc
because it is bug hider.
But my question is as mentioned bellow .
Lets say I have not included stdlib.h in my program still I
am using malloc so compiler will throw warring because with
out prototype compiler assumes that function is declared
as extern int malloc().
If you ignore the bug, the bug remains. Even without an
explanation, I can''t this as ever being a Good Thing (TM).
Suppose I ignore that warning and did not cast the return
value
Now during linking time my code will be linked to exact
implementation of malloc which returns void * . So in this
case will it be a problem?
Yes.
On a typical motorola 68k implementaion, the library will
return the pointer in A0, whereas your code will expect
it in D0.
Many thanks for the response. I just fell to understand this point.
With out prototype compiler assumes that malloc returns int. But
during linking time it will be linked to correct definition of malloc,
which returns (void *). Then in run time it will be returning (void
*) .Is my understanding wrong ?
On a stack based implementation where void * is 64 bits
and int is 32-bits, you may find the library function will
clean up too much stack.
I did not get this point either . How it is a problem ? Could you
please illustrate this point bit more .
Fact is, failing to declare a prototype is seen as such
a weakness in the C language that many people prefer to
tell their compilers to make it an error to call an
unprototyped named function, even though it breaks the
conformance of the compiler. Some even go so far as use
C++ instead of C.Ok . This is the only point I understood.
somenath <somenath...@gmail.comwrote:Peter Nilsson <ai...@acay.com.auwrote:somenath <somenath...@gmail.comwrote:I learned that we should not cast the return value of
malloc because it is bug hider. ...
Lets say I have not included stdlib.h in my program
still I am using malloc so compiler will throw warring
because with out prototype compiler assumes that
function is declared as extern int malloc().If you ignore the bug, the bug remains. Even without an
explanation, I can''t this as ever being a Good Thing (TM).
Suppose I ignore that warning and did not cast the
return value
Now during linking time my code will be linked to exact
implementation of malloc which returns void * . So in
this case will it be a problem?Yes.
On a typical motorola 68k implementaion, the library will
return the pointer in A0, whereas your code will expect
it in D0.
Many thanks for the response. I just fell to understand
this point.Do a google for "chinese whispers".
C is typically implemented as a series of processes
(roughly following the translation phases set out in
the standard.) Each of these processes typically
carries an element of trust.
The compiler trusts you the programmer.
The linker trusts the compiler.
The host system trusts the linker.
The weak point is at the beginning. If you lie to the
compiler, everyone trusts each other until the program
actually runs and problems surface.
With out prototype compiler assumes that malloc returns
int.Yes, and it produces some assembler that _assumes_ the
type of value returned when it calls malloc is an int.
On some systems, that means assuming it comes via a data
register, rather than an address register. On other systems
it assumes that 32 bits need to be allocated on a stack,
instead of 64. On still other systems, it assumes it will
arrive in the living room rather than the garage.
Different systems have different calling conventions. Some
systems use machine registers, some use a hardware stack,
others have combinations of the two, and still others use
even wierder mechanisms.
The fundamental point though is that these calling
conventions fall down (usually quite quickly) if the
compiler uses the wrong one. The only clue to the
correct one comes from you the programmer.
But during linking time it will be linked to correct
definition of malloc, which returns (void *). Then in
run time it will be returning (void *) .But _where_ this void * is returned is crucial. Since the
compiler has been told to expect it via a completely
different type, there is no guarantee that the assembly
code it produces will correctly match up with how the
function actually returns the value.
Is my understanding wrong ?You are missing the point that C is a statically
typed language. The return type of a function is not
determined at runtime, it is fixed at compile time. In
this regard, C differs from many modern languages that
prefer to figure things out as they run.
Calling a function is like a messaging system. You
pass arguments to the function and it returns one
back to you (if it''s a non-void function like malloc).
How those messages are communicated are agreed to in
advance. You stray from the agreed communication lines
at your peril.
Imagine you send off your courier to deliver a message
to Malloc Pty Ltd asking for a delivery of Memory. You
tell your assistant to pick up the returned package at
Gate 15 of bus terminal. But Malloc Pty Ltd always
delivers at Gate 12. So you miss the package.
On a stack based implementation where void * is 64
bits and int is 32-bits, you may find the library
function will clean up too much stack.
I did not get this point either. How it is a problem?
Could you please illustrate this point bit more .Suppose you send a family wagon over to Malloc Pty
Ltd to pick up a package. They then put 2 tonnes of
packages into the back and your tyres blow out before
you even leave the pick up dock. Where you agreed to
send a small utility truck, you sent a wagon, and
now you''ve paid the cost.
--
Peter
这篇关于关于malloc套管的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
