Groups > comp.lang.c > #19848

Re: Generates integer literal of the largest value a variable can hold. Macro takes only variable-name.

From	James Kuyper <jameskuyper@verizon.net>
Newsgroups	comp.lang.c
Subject	Re: Generates integer literal of the largest value a variable can hold. Macro takes only variable-name.
Date	2012-04-23 16:45 -0400
Organization	A noiseless patient Spider
Message-ID	<4F95BF7F.10500@verizon.net> (permalink)
References	<3b194163-c8e2-4250-864a-d3f0a1324677@f5g2000vby.googlegroups.com> <jn4csb$2mn$1@news.belwue.de>

Show all headers | View raw

On 04/23/2012 04:08 PM, Thomas Richter wrote:
> On 23.04.2012 21:38, John Reye wrote:
>> Assume you have a variable called
>> var
>> of unknown type. (Or that the type can be changed).
>>
>> How can one construct a literal, to be the largest value that this
>> variable can hold, without information about the variables type?
> 
> Not in C in a completely portable way. If you are contained to standard 
> architectures with binary representation of data, you could check

The error density in the next sentence is truly amazing. Some people
consider sentences like this one to be the sign of a troll. I'll
withhold judgement for now on that issue.

> a) whether the 1/2 in this variable equals zero or not. ...

Setting any arithmetic type to 1/2 should produce a result of 0 for all
arithmetic types. I think you mean 0.5.

> ... If not, it not 
> an integer type, ...

This is both simpler and has better grammar: "if so, it is an integer
type". This would also fix the error in the rest of the sentence:

> ... otherwise, HUGE_VAL should be the largest possible value,

I think you got confused by having two many "not"s. As written, assuming
that you meant 0.5 rather than 1/2, and were thinking of 'double' as the
only floating point type, that's exactly backwards.

But that still doesn't work; HUGE_VAL is for doubles, HUGE_VALF and
HUGE_VALL are for float and long double, respectively. If you knew which
one of those three options was relevant, that would violate one of the
specified conditions: no information about the type.

The HUGE_VAL* macros are special positive values used by the standard
library for indicating error conditions; their values are otherwise not
constrained. It's entirely possible for HUGE_VAL to be 1 (though that
would be a very bad idea).

> b) if (-1) casted to the type is positive, it is unsigned, and the 
> result is the largest possible value,

Again, if he knew the type to cast it to, that would violate the
specified condition: "no information about the type".

> c) otherwise, on *many standard* systems, you may try to use 1 << 
> ((sizeof(type) << 3)-1) for signed types.

Why use "<<3" rather than "*CHAR_BIT"? It's not portable, but it's more
portable than "<<3".
You're missing the final -1 in your expression.

Thread

csiph-web