Re: !!, what is it?

On Tue, 13 Sep 2005 09:12:42 +0200,
Michael Mair <Michael.Mair@xxxxxxxxxxxxxxx> wrote:
> Tim Woodall wrote:
>> On Mon, 12 Sep 2005 09:36:01 +0200,
>> Michael Mair <Michael.Mair@xxxxxxxxxxxxxxx> wrote:
>>
>>>As an aside:
>>>I recall seeing some platform specific headers which went for the
>>>all-bits-one representation of "true" -- but the C implementations
>>>gave 1 for !!TRUE as well...
>>
>> int is_it_seven(int x)
>> {
>> return x==7;
>> }
>>
>> if(is_it_seven(7) == TRUE)
>> printf("7 is seven\n");
>> else
>> printf("7 is not seven\n");
>>
>> While I would never write the explicit test for TRUE [1], I would be
>> horrified at any header that defined TRUE such that this code didn't
>> behave as expected.
>>
>> [1] Other peoples coding standards excepted.
>
> Sorry, without C99's _Bool and _True, this argument is bogus.
> Apart from the possible range of return values one could expect from
> is_it_seven() and the possible mismatch with, say isalnum() == TRUE
> or strcmp() != TRUE, there is no benefit in that.
I KNOW there is no benefit in that. Thats why I wrote
"While I would never write the explicit test for TRUE"

But I would not pass review any C source that defined FALSE as anything
other than 0 and TRUE as anything other than 1 (or some equivalent
expression)

Infact, assuming I spotted it, I wouldn't accept any code that had a
function commented /* returns TRUE or FALSE */ unless the function
returned only 1 or 0 regardless of whether the macros TRUE and FALSE
were actually defined




> IIRC, this "TRUE" was intended for bitwise operations and conveniently
> fulfilled !TRUE == FALSE. However, this would not have worked on a
> 1s complement platform.
I still wouldn't have accepted it. There will have been a better name
for the macro.


> Sorry, I probably did not phrase it carefully enough.
>
> This was not my question. I am well aware of s-m and 1s complement,
> my question more or less is whether it is possible that a signed
> int bitfield could be treated as if it was an unsigned int
> bitfield?
>
No. (IMO) 6.7.2.1

9 A bit-field is interpreted as a signed or unsigned integer type ...

and then footnote 104) paraphrased - if the type specifier is int it is
implementation defined whether the bitfield is signed or unsigned

Which implies to me that signed int -> signed, unsigned int -> unsigned
and int goes to one or the other.

Tim.


--
God said, "div D = rho, div B = 0, curl E = - @B/@t, curl H = J + @D/@t,"
and there was light.

http://tjw.hn.org/ http://www.locofungus.btinternet.co.uk/
.

Relevant Pages

  • Re: converting 1944 to 1,9,4,4
    ... >int main ... It was compiling for /me/ due to the headers included by ... tostring.h in the platform I happen to be using, ...
    (comp.lang.cpp)
  • Re: First C++ Project
    ... Neither of these two headers are part of standard C++. ... int main ... > draw line; ... it declares. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Moving from C++ to VC++
    ... If it is the longest integer. ... platform, I want the longest integer type ... Now /I/ would like to have 'int' being the ... Adhering to what computing standards' intention ...
    (microsoft.public.vc.language)
  • Re: Some Advice.
    ... int main{ ... you should use identifiers that are "self-documenting". ... you should provide inclusion guards for headers. ... function definitions into separate source files. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: I2C bus implementation (for MPC82xx)
    ... > PowerMac (see the patches that just went in rewriting the PowerMac i2c ... > smbus API, but then, do you really want to use an existing i2c driver? ... For the resources I have used platform definition. ... +static int ...
    (Linux-Kernel)