some basic question in C

hi  KDO

thanks for the explanation

i have some queries on your answer.

you started with the example   SmallValue = 130; ( 2byte in VC++)

when i am casting it into      unsigned int    the result should go to 4 byte( VC++) .

130 is positive....so  when i will caste it it will be a positive number.

so, if M.S.B  1 is -ve and 0 is positive then i should get  in the register like below

   0.....binary code of 130.(  total 32 bits)
M.S.B ... other bits  

why i would get  0xFFFFFF82 as a result?



i may be wrong ....can you tell whats wrong with this?

and about the second question
_________________________
as stefan73 told

* >> it skips or throws
 [\t] >> only tab(which contains 7 blank spaces)  are allowed.

 so  %*[ \t]  means it will skip 7 blank space while reading....is it correct?

what about  %8[^@]%*c  ? my probelm is how many percent sign i can give ?







 

hi , i have changed mine account  to  cofactor ..... i am getting mails irregularly  in my old account(sanko50).

do i need to close my old account(sanko50) ???
thanks

Hi cofactor,

You should close your old account.  Or contact a moderator and ask him to transfer your history and close it for you.  (I'll miss 'sank050'!)


Does VC++ use two bytes to store a character?  My example shows converting from a char to an int and was meant to convert from 1 byte to 4.  This is something I have to do from time to time and have been bit by the sign bit more times than I care to admit.  It goes back to the old big-endian vs. little-endian argument.

Often time you'll get data from a source that might behave differently than the system under which you're currently running.  To write code that always handles the data correctly you sometimes have to pack/unpack the data yourself.  When that happens you run the risk of the problem that I described.

Here's two common places for this:

TCP/IP.  The network header contains the IP address.  It is always 4 bytes, left to right.  1.2.3.4 is stored as 0x01020304.  Extract those four bytes as a 32-bit integer on a big-endian system and the integer will contain 0x01020304.  Do so on a little endian system and you'll get 0x04030201.  The way to ensure that the C program will always assemble the correct value is to have the program build the integer byte by byte.

Data Storage.  The same principal applies here.  There are quite a few record formats where the record length is noted by a leading integer field.  The only way to ensure that your program will read the record correctly is to make sure that you interpret the integer correctly and that usually means assembling it yourself.


Good Luck,
Kent

sanko50/cofactor,

kdo has effectively covered signed/unsigned for you.

In VC++ 'char' is indeed a 16bit value and therefore does not have the same effect that kdo was describing. Using signed/unsigned is a good way of getting the compiler to find your errors for you. Using unsigned for a loop counter, for example will often highlight potential problems with array accessing for example. Code like:

extern char buffer[];
extern int x;

for ( int i = 0; i < 100; i++ )
{
   buffer[x-i] = ' '; // Oops! I meant to use 'x+i'
}

would probably not signal errors but

for ( unsigned int i = 0; i < 100; i++ )
{
   buffer[x-i] = ' '; // Oops! I meant to use 'x+i'
}

would probably generate a warning because you are mixing signed and unsigned values in the calculation.

Generally, if the data is unsigned, say so. If you are working with binary data, use unsigned; if you are working with decimal values, use signed. Even if your compiler does not help finding problems, at least your intent was clear for others to see when they read your code.

>> in the format specifier of scanf()  what does percent(%) means??

The '%' is a trigger for scanf to begin scanning for a description of the format to use for the following characters in the format string.

>> is it necessary that there should be as many percent(%) that many data type character???

No, as you have correctly shown in one of your examples below. Using a '*' in the format allows you to skip parts of the input data without storing anything.

>> otherwise how this format works...
>> sscanf(" \t test", "%*[ \t]%s", a)
>> what does this format do?? notice here there is two percent(%) but only one data type character(i.e  's')....it is peculiar to me.

The '%*[ \t]' says 'take as many spaces or tab characters ([ \t]) from the input string and throw them away (*).
The '%s' says take the next string (terminated by a space or end of string incidentally) and put it into the next parameter ('a' in this case so I hope its a pointer to a string).

>> or  syntax  "%8[^@]%*c" also works in the scanf()

This will read up to eight characters, stopping at the end of the string or the first '@' character and store them in the first parameter, then take the next character (the '@') and throw it away (*).

>> ....it seems that there is no  relation with percent(%) and data type character. is it true?????

The number of parameters should be the same as the number of '%'s in the format that are not followed by '*' or another '%'.

E.G. "%%%*d%d" only needs one prarmeter (for the final %d). The '%%' will expect a '%' character in the input string, the %*d will read and throw away a decimal number, the %d will read and store a decimal number.

>> * >> it skips or throws
>> [\t] >> only tab(which contains 7 blank spaces)  are allowed.
>> so  %*[ \t]  means it will skip 7 blank space while reading....is it correct?

The '\t' is not expanded into 7 spaces, it stays as a 'tab' character (0x09) and therefore skips tabs.


Paul

i don't understand why would one need a signed char anyways. just to force the first bit to 0?

I agree, signed char's are an anachronism. They arise from the vagueness of the original definition of a char in C.

'int' came first when computers were expected to be used for primarily mathematical processes and calculations. When text processing became popular, the int was used as a character number from a list of possibles.

Then the dullards stepped in and tried to standardise these lists. There was 6bit TTS used on paper tapes, 7bit ASCII or 7bit EBCDIC used on punched cards etc etc. At a time when memory was expensive eight bits seemed a convenient packet to store all of these in.

With 6 or 7 bits there was no problem with the sign bit. Then extended ASCII - 8 bits - came along, opening up a can of worms. All sorts of problems arose that are still here today. I understand one moon-bound rocket exploded due to just such a problem. The retrofitted solution was to invent the concept of 'unsigned'. The problem was that the numerical distance between 'A' and 'Z' was, correctly, 26 but the distance between 'A' and the '<<' (spanish open quotes) is NEGATIVE.

And we still suffer from the two gremlins of 'unsigned' and 'Extended ASCII' to this day. Thank goodness ISO are finally baring their teeth at IBM et al and ignoring their demands to add more and more code pages. We are getting there. I look forward to the death of 'unsigned char'. Java has taken a significant step towards finally killing off this horrible accident waiting to happen but I dont feel it has solved the problem yet. Who knows what lies in the future.

Yes, signs on a chars are definitely not necessary anymore, and the use of a "signed 8-bit integer" is probably limited to such esoteric things as 8-bit-relative assembly jumps. Unicode is definitely the future.

Speaking of java, the forced signedness of ints + longs there can be a pain when you want to use the '%' operator to transform an int to a limited number range without regard to the sign.

yeah and java doesn't have bitwise access to ignore unimportant bits.
well we can't do anything abt it unless we r employed by IBM or Sun or Intel or ...

Yes we can!

We can create carefully crafted arguments for or against the issues we see in the tools that are provided for us. We can then present these arguments in a forum such as this where others can provide their input in the form of constructive criticism, as I am doing now for you. Ultimately, hopefully, someone will read our discourse and discuss it with someone who CAN change things.

In this way only will we progress. Defeatism will be defeated.