This topic has been archived. It cannot be replied.
-
工作学习 / IT技术讨论 / show u another dark spot of cvoid main()
{
char c=0;
signed char sc=0;
sc=c; //works
int i=0;
signed int si=0;
si=i; //works
char* pc=0;
signed char* spc=0;
spc=pc; //not works
int* pi=0;
signed int* spi=0;
spi=pi; //works
}
I can't see any reasonable logic here
-blaise(blaise);
2001-6-21
{375}
(#108408@0)
-
The compiler is just doing what the ANSI C standard has defined.All data types (mostly for integral types, becaue float and double are always signed) default to "signed" except for char. So , in the compiler's point of view, "int" equals to "signed int", while "char" and "signed char" are two different types
-numnum(numnum);
2001-6-21
{256}
(#108438@0)
-
could you tell why the specification decided that :it's ok for short/int/long but not char?and why assigned value from char to signed char is ok but assign point is wrong?
-blaise(blaise);
2001-6-21
(#108473@0)
-
This is usually taught in the first lecture for an introductory C or C++ course.You are right in that most people tend to overlook this small perk. Frankly speaking, I can tell this right on top of my head because I used to teach CS 111(introduction to C++ programming) course for the first two quaters in the graduate school. You know, you've gotta pay attention to details if you are a TA. The reason why you can assign char value to signed char variable is that the compiler does implicit conversions between all built-in types.
-numnum(numnum);
2001-6-21
{455}
(#108502@0)
-
what i asked for is why specification didn't tell compiler to do the implicit convertion for the pointer.
-blaise(blaise);
2001-6-21
(#108515@0)
-
Memory aligment. It's safe to do the implicit conversion for values, because you only make a memory copy. Imagine you explicitly cast a
char* into int*, what will happen? You will end up with a bus error on
Unix, although you are fine on PC because PC's are running little endian
chips. int data access requires an alignment of 4 on UNIX but your char* pointer might very likely be pointing to some odd numbered memory address.
-numnum(numnum);
2001-6-21
{420}
(#108519@0)
-
good answer!
-blaise(blaise);
2001-6-21
(#108521@0)
-
请教，endian是什么意思？
-pazu(InTheSky);
2001-6-21
(#108530@0)
-
Big endian refers to the chipset that addresses an integer by its most significant byte, while a small endian machine addresses the integer by the least significant byte.For an integer 234F, in a big endian machine, the representation would be 234F, while in a little endian machine, it would be represented as F432. One advantage for little endian machine is that the cpu deoesn't require the memory to be aligned for data access .
-numnum(numnum);
2001-6-21
{266}
(#108714@0)
-
It is so good that you mentioned endian, let me ask a little more...
-birdincage(birdincage);
2001-6-22
{753}
(#108848@0)
-
1) a very good question, 00101011 is the big endian,(sorry for using
English here, it comes more natural for me to discuss technical
questions in English due to the terminologies and jargons)
-numnum(numnum);
2001-6-22
{1211}
(#108866@0)
-
Why do you say sorry? :-) I am here to learn both techniques and English. If you answered my questions in Chinese, I would probably beg you to re-write it in English :-):-) :-) Thank you very much, now I get a rather clear picture:-)
-birdincage(birdincage);
2001-6-22
(#109096@0)
-
Big Endian and Little Endian.
-netwind(网风);
2001-6-22
{1452}
(#108880@0)
-
Woow, the 'history' of Big and Little Endian, and where they are now, woooow, :-) Thank you so much:-)
-birdincage(birdincage);
2001-6-22
(#109098@0)
-
Thx...netwind. According to numnum's words, I went through the /usr/include/arpa/names.h and found there is another ednian -- PDP Endian. Is there any other story about it? hoho...thx...and thank numnum...
-pazu(InTheSky);
2001-6-22
{1357}
(#109252@0)
-
PDP endian stems from the legacy pre-UNIX system PDP11, PDP11 was the ancestor of all modern UNIX systems.Its byte order is a weird mix of big endian and little endian, it has little enidan short integers(word) and big endian long integers. BTW, you should read the /usr/include/arpa/nameser_compat.h instead, because in your system, nameser.h is only a wrapper for nameser_compat.h, where the real DNS headers are defined, pay attention to the HEADER structure
-numnum(numnum);
2001-6-22
{357}
(#109274@0)
-
Help! numnum, I still don't understand why it will be ok on little endian chips.
-pazu(InTheSky);
2001-6-22
(#109279@0)
-
because HIWORD is not garbage in this case. numnum, am i right?
-mrviceroy(杀人者Daniel是也);
2001-6-22
(#109424@0)
-
I cannot see why it has anything to do with Big or Little Endian either. If number of bytes of two types are different, the order of byte or bit matters less.I don't know what does "work" mean in your program. Is it that "not work" is a complier error? It shouldn't be. All your assignments can pass, some of them may have compiler warnings. But assignments to pointers may cause unpredict errors, because the length of the data your pointer points is different. It is the same as you do convention between different types.
-birdincage(birdincage);
2001-6-23
{373}
(#110143@0)
-
i bet most of the people don't know the char is special without meet the compile error then look into the doc,at least for me
-blaise(blaise);
2001-6-21
(#108470@0)
-
It looks strange that you try to assign a fix value to a pointer....
-birdincage(birdincage);
2001-6-21
{703}
(#108580@0)
-
Sorry, I made a mistake. It is important to initialize a pointer to be 0.
-birdincage(birdincage);
2001-6-23
(#110415@0)