Re: using "!!" in "c"


"Keith Thompson" <kst-u@xxxxxxx> wrote in message
news:ln3bjkkkzk.fsf@xxxxxxxxxxxxxxxxxx
> "pemo" <usenetmeister@xxxxxxxxx> writes:
>> <snip>
>>
>>>> So is (value, 0) (i.e., a comma operator). It turns a scalar value
>>>> into 1 or 0. It just happens to be 0.
>>>
>>> What's the point here?
>>
>>>I believe that Keith was just pointing out that your specification of
>> what !! does was incomplete. What he wrote met your specification but
>> would generally be pointless in real code (there are potentially some
>> exceptions) and does not do what !! does.
>>
>>
>> If that *IS* the case, it seems um, rather unnecessarily pedantic - I
>> believe that what I said was clear enough - and corrrect in as far as it
>> went: and I also didn't say it was the only way to do something .... so
>> why
>> point out alternatives? Maybe it's necessary to produce litanies
>> containing
>> alternative possibilities for each non-exhaustive statement ever made
>> here
>> sometimes?
>
> (A number of attributions were snipped. I wrote the text starting
> with "So is (value, 0)", pemo wrote the text starting with "What's the
> point here?", and Flash Gordon wrote the text starting with "I believe
> that Keith was". Please leave attributions in place. Thanks.)

After this reply, I'll try and remember to simply enter any further replies
I make to posts at the bottom of any existing text - and then let others
either ignore my posts, or else figure out to what it is I might be
referring - seems like I'll never get the hang of this process, and if I'm
black-flagged, knobbled, f**ked up the ass [or whatever the proper 'in the
know' usenet term is] by some for not posting correctly, at least I won't be
committing the ultimate sin: top posting.


> What you wrote was:
>
> !! is a good way of turning a scalar value into 1 or 0.
>
> That's not a useful specification unless you also specify *when*
> it yields 0 and when it yields 1. By itself, it doesn't provide any
> clue of why you'd want to turn a scalar value into 1 or 0. I was just
> emphasizing the fact that !! maps 0 to 0 and all non-zero mappings
> to 1. There are many many other possible mappings.


> By itself, it doesn't provide any clue of why you'd want to turn a scalar
> value into 1 or 0.

'By itself' - yes - which is why I then gave an example (malloc).



> Whether I was being overly pedantic is a matter of opinion, of course.
> I likely wouldn't have bothered mentioning it if I weren't commenting
> on other things in your article.
>
>>>>> printf("%p\n", (void *)"boo");
>>>>>
>>>>> will output some value that's not 0, and very unlikely to be 1, e.g.,
>>>>> 0040300
>>>
>>>> It will output some implementation-specific sequence of printing
>>>> characters. The sequence may or may not look like a number.
>>>
>>> Can you explain this comment too? Is it an allusion to some obscure
>>> minutiae in the std, like "In reality, an implementation is free to
>>> encode
>>> an address such that it is displayed in egyptian hieroglyphics"?
>>
>>>One very common format of output is something like "1234:5678", another
>> is something like "0x12345678". <snip>
>>
>> Ah, so it was as I expected - an allusion to some obscure minutiae [well,
>> it
>> is isn't it - letter-of-the-law-correct-or-not] that seems picky and
>> generally non-constructive. The two examples you gave look like numbers
>> to
>> me. And I would hazard a guess that most every compiler outputs
>> something
>> similar - even if it doesn't *have to*. So, saying that a compiler
>> *could*
>> output this in a braille encoding of the morse-code interpretation of
>> egyptian hieroglyphics is kinda like saying that there is a remote
>> possibility that you *could* pick up a book which is written in English -
>> but that you can't read - because the author decided to choose a remote
>> vocabulary and to 'encode' his/her prose in such an impenetrable way as
>> it
>> make it more or less impossible. Both situations *could* exist, but both
>> are, in reality, unlikely to - so what's the point in making a noise
>> about
>> it?
>
> No, this is not "some obscure minutiae", this is part of a basic
> understanding of the language.
>
> Here's what the standard says about the "%p" format for the *printf()
> functions:
>
> The argument shall be a pointer to void. The value of the pointer
> is converted to a sequence of printing characters, in an
> implementation-defined manner.
>
> There's also some wording for the *scanf() functions saying that it
> can read the same format produced by *printf().
>
> There is no implication that the output looks anything like a number,
> and portable code cannot depend on any particular output format.

Ok, so this is where the problem is - although the OP might not give a
flying f**k about it, as they also might possibly not give the same for
portability - you're saying that I should have added ...

"will output some value that's not 0, and very unlikely to be 1, e.g.,
0040300. But remember that nothing is said in the C stds about the actual
output here, so you might see output that's in a format that you might not
readily understand for example, some version of printf might output cockney
rhyming slang! - "two fat ladies, two rubber ducks, and a ton" (meaning
8822100 in base 10)"







.