IsUnsigned() function?

Jay A. Konigsberg jak at sactoh0.UUCP
Sun Jul 22 20:51:54 AEST 1990


In article <1990Jul20.144241.2560 at diku.dk> njk at diku.dk (Niels J|rgen Kruse) writes:
>karl at haddock.ima.isc.com (Karl Heuer) writes:
>>In article <3539 at sactoh0.UUCP> jak at sactoh0.UUCP (Jay A. Konigsberg) writes:
>>>I would bet that they had something like this in mind.
>>>      #define MASK 10000000
>>>      signed(number) long number; {
>>>          if(number & MASK) return(FALSE); else return(TRUE);
>>>      }
>>If that's what they had in mind, then `return (number >= 0)' is a trivial
>>solution-- which doesn't depend on the unspecified internal representation of
>
>Not to mension giving an integer argument to a function
>expecting long without prototype in scope and implementing the
>reverse operation of the one wanted (if it hadn't been for the
>missing 0x of course).
>
>Considering *********'s reputation for buggy code, they just
>_might_ have liked it.  :-) ;-)
>
>If squeezing codesize is the big issue, something like this
>might be better:
>
>IsUnsigned (int number) {
>  return ~(unsigned)number / ((unsigned)-1/2 + 1);
>}
>
Well, I'm not the original poster, but I am the one that posted the
solution that did the num & MASK solution. Since I've discussed this
topic with a local systems programmer/manager at a local company and
dicovered that the correct answer is the simple one. Namely:

if ( num < 0 ) return FALSE else return TRUE;

This is both simple and portable. Still I liked the solution of

(num & 1<< (sizeof(int)*8) )

even though it assumes that the sign is stored in the high order bit
(which to my surprise isn't always the case). It will always mask that
high order bit in a rather elegent fassion.

It seems that the original poster left off an important part to the
question. Why did you choose the algrothium you used? The question
is designed to find people who will make things overly complacted
or just don't know very much about how things work - thats where I
got traped. I passed by the simple solution because the question
seemed to imply that it wasn't the best. Oh well, thats why I read
this group.

In fact, the systems programmer liked the question so much, he said
he was going to include it in his interviews in the future.

Well, one good thing has come out of this anyway, I understand more
of how C handles the values it stores and how it relates to the under-
lying hardware. Gee, one down 9,999,999 to go :-)

-- 
-------------------------------------------------------------
Jay @ SAC-UNIX, Sacramento, Ca.   UUCP=...pacbell!sactoh0!jak
If something is worth doing, its worth doing correctly.



More information about the Comp.lang.c mailing list