来自sig_atomic_t的typdef'ing有效吗？ [英] typdef'ing from sig_atomic_t valid?
问题描述
类型定义是否类似
typedef sig_atomic_t atomic_int;
会产生原子写入/可读类型吗？从我在
标准中读到的内容我猜是的，因为sig_atomic_t本身是由
typedef生成的，而typedef并没有真正引入新类型。对于另一个
问题，如何定义无符号原子类型？如果签名sig_atomic_t是
签名，甚至没有查看signal.h并使用unsigned类型
标准中的任何东西都可以证明它是合理的/>
构造sig_atomic_t，因为它可能有一个
不同的宽度/对象表示。
Mark
所以******* *****@yahoo.com （Mark Piffer）在
新闻中写道：cc ******************** *****@posting.google.co m：
typedef是否类似
typedef sig_atomic_t atomic_int;
会产生原子写/可读类型吗？从我在
标准中读到的内容我猜是的，因为sig_atomic_t本身是由
typedef生成的，而typedef并没有真正引入新类型。但是，对于另一个问题，如何定义无符号原子类型？如果签名sig_atomic_t，甚至没有查看signal.h并使用构造sig_atomic_t的无符号类型，我无法在标准中找到任何可以证明其合理性的内容，因为它可能具有不同的宽度/对象表示。
Mark
sig_atomic_t的SIG_ATOMIC_MIN范围为SIG_ATOMIC_MAX和SIG_ATOMIC_MAX可能是
签名或未签名。签名，最小范围是-127到127.
无符号，最小范围是0到255.或者换句话说......你知道
定义那个sig_atomic_t可以保存0到127之间的值，无论是签名还是未签名的
。 （全部来自C99）。无论哪种方式，我都看不到任何方式
制作一个签名的或未签名或sig_atomic_t的版本。
sig_atomic_t最好将IMO视为所有
其他整数类型的完全独立类型，而不是将其视为typedef。来自其他类型的一些
。编译器必须对它进行操作的事实原子
意味着某个级别的编译器必须知道这不仅仅是一个简单的
旧整数类型。
伊恩伍兹
-
我是一个偏执型精神分裂症的悲伤 - 受虐狂。 />
我的另一半是为了得到我而且我等不及了。
Richard Heathfield
在< Xn ***************************** @ 217.32.252.50> Ian Woods< ne ****** @ wuggyNOCAPS.org>写道：
sig_atomic_t最好将IMO视为来自所有其他整数类型的完全独立的类型，而不是将其视为typedef来自某些
其他类型。编译器必须对其进行原子操作的事实
意味着某个级别的编译器必须知道这不仅仅是一个简单的旧整数类型。
如果编译器*自然地*原子地处理整数类型T，那么
它不关心对象是否被定义为具有类型
T直接或通过sig_atomic_t。
这将需要一个小于8位的处理器，以便原子上不能处理整数
类型，需要额外的信息
你在谈论。但我还没有听说过这类处理器的标准C
实现...
我同意最大可移植代码只能依赖于0 .. 127范围
sig_atomic_t，但这个范围对于大多数
应用来说应该足够了。请记住，只有*访问sig_atomic_t *才能保证以原子方式执行
，因此这种类型的唯一有意义的操作
分配值并读取当前值。
Dan
-
Dan Pop
DESY Zeuthen，RZ group
电子邮件： Da*****@ifh.de
2004年4月22日16:28:18 GMT， Da*****@cern.ch （ Dan Pop）写道：请记住，只有*访问* sig_atomic_t才能保证以原子方式执行，所以这种类型的唯一有意义的操作是分配一个值$读取当前值。
这是否意味着不支持原子读 - 修改 - 写？如果没有，
sig_atomic_t的用途是什么？
-
#include< standard.disclaimer>
_
Kevin D Quitt USA 91387-4454所有统计数据的96.37％组成
根据FCA，此地址可能不会添加到任何商业邮件列表中/>
Does a typedef like
typedef sig_atomic_t atomic_int;
produce an atomically write/readable type? From what I read in the
standard I would guess yes, as sig_atomic_t itself is produced by a
typedef and typedefs don''t really introduce new types. For another
question though, how to define an unsigned atomic type? I can''t find
anything in the standard that would justify it, if sig_atomic_t is
signed, not even looking into signal.h and using the unsigned type
from which sig_atomic_t is constructed, as it could well have a
different width/object representation.
Mark
so************@yahoo.com (Mark Piffer) wrote in
news:cc*************************@posting.google.co m:
Does a typedef like
typedef sig_atomic_t atomic_int;
produce an atomically write/readable type? From what I read in the
standard I would guess yes, as sig_atomic_t itself is produced by a
typedef and typedefs don''t really introduce new types. For another
question though, how to define an unsigned atomic type? I can''t find
anything in the standard that would justify it, if sig_atomic_t is
signed, not even looking into signal.h and using the unsigned type
from which sig_atomic_t is constructed, as it could well have a
different width/object representation.
Mark
sig_atomic_t has a range of SIG_ATOMIC_MIN to SIG_ATOMIC_MAX and may be
either signed or unsigned. Signed, the minimum range is -127 to 127.
Unsigned, the minimum range is 0 to 255. Or, in other words... you know for
definate that sig_atomic_t can hold values from 0 to 127 whether it''s
signed or unsigned. (All from C99). Either way, I can''t see any way of
making a "signed" or "unsigned" version of sig_atomic_t.
sig_atomic_t is best treated IMO as a completely seperate type from all the
other integer types rather than thinking of it as "typedef"ed from some
other type. The fact that the compiler has to make operations on it atomic
means that the compiler at some level has to know that isn''t just a plain
old integer type.
Ian Woods
--
"I''m a paranoid schizophrenic sado-masochist.
My other half''s out to get me and I can''t wait."
Richard Heathfield
In <Xn*****************************@217.32.252.50> Ian Woods <ne******@wuggyNOCAPS.org> writes:
sig_atomic_t is best treated IMO as a completely seperate type from all the
other integer types rather than thinking of it as "typedef"ed from some
other type. The fact that the compiler has to make operations on it atomic
means that the compiler at some level has to know that isn''t just a plain
old integer type.
If the compiler *naturally* handles integer type T atomically, then
it couldn''t care less whether the object was defined as having type
T directly or via sig_atomic_t.
It would take a less than 8-bit processor so that none of the integer
types can be handled atomically, requiring the additional information
you''re talking about. But I have yet to hear about standard C
implementations for such processors...
I agree that maximally portable code can only rely on the 0..127 range
for sig_atomic_t, but this range should be more than enough for most
applications. Keep in mind that only *accesses* to sig_atomic_t are
guaranteed to be performed atomically, so the only meaningful operations
on this type are assigning a value and reading the current value.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
On 22 Apr 2004 16:28:18 GMT, Da*****@cern.ch (Dan Pop) wrote:Keep in mind that only *accesses* to sig_atomic_t are
guaranteed to be performed atomically, so the only meaningful operations
on this type are assigning a value and reading the current value.
Does this mean that atomic read-modify-write is not supported? If not, of
what use is sig_atomic_t?
--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list
这篇关于来自sig_atomic_t的typdef'ing有效吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
