Re: Prioritize Performance over Correctness

On 28/07/2026 8:02 PM, bart wrote:
> On 28/07/2026 12:21, Johann 'Myrkraverk' Oskarsson wrote:
>> On 28/07/2026 6:22 PM, Keith Thompson wrote:
>>> Johann 'Myrkraverk' Oskarsson <[email protected]> writes:
>>>> On 28/07/2026 8:59 AM, Keith Thompson wrote:
> 
>>>>> Your ASCII art has nothing to do with the current discussion (and
>>>>> didn't even display correctly due to line wrapping).  I've dropped
>>>>> the cross-post to alt.ascii-art.  Can you please try to focus?
>>>>
>>>> Nope.  You've absolutely demonstrated that you have no idea what
>>>> is involved in the internals of a C compiler.
> 
> You don't seem to have much idea either.
> 
> 
>>   What you're trying
>>>> to describe is just hogwash and balderdash when it comes to the
>>>> real world nitty gritty of implementing a compiler.
>>>>
>>>> Now stay out of my compiler discussion, you're not wanted here!
>>>
>>> Perhaps the rest of the group would be interested in knowing just
>>> what I got so badly wrong.
>>>
>>
>> I'll summarize it as: You think I care what the C standard documents
>> say.  I don't.
>>
>> I care how it's implemented.  You don't.
> 
> This is what you wrote:
> 
> "I think more of it like an arm-chair thought exercise.  The issue
> isn't the bit pattern at all, but how you're going to treat conversion
> to integers.  Especially in this context,
> 
>    if ( p ) { ... }
> 
> a 64bit p with the pattern 0x..00000000 isn't supposed to be false,
> when truncated to an integer...."
> 
> You don't say what type 'p' is, but I assume it is a pointer.
> 
> How a compiler implements this depends partly on what the language says, 
> for example:
> 
>    Scalar type  Value   True when
> 
>     integer      i      i != 0
>     float        x      x != 0.0     (-0.0 may need considering)
>     pointer      p      p != NULL
> 
> Whether NULL is all-bits-zero depends on the implementation, but I think 
> it it more platform-dependent rather than left to individual compilers.
> 
> Since in that case code from different compilers would be incompatible, 
> and calling into external libraries would be problematical.
> 
> In any case, there is no conversion to int involved; it is just has to 
> implement that comparison by whatever means works.
> 

Indeed, and if you read the snippet you so thoughtfully cut off, you'd
have realized that's exactly how I think about it, in terms of compiler
internals.  Now, of course, you being an expert in twisting other
people's expertise, you must be a journalist?  Do you perhaps write for
VICE?  I got my name into a VICE article once, for not being involved
at all.  That was comforting.  Now I feel like I'm just as important
as UBS.

On the other hand, to the programmer, especially those not who have not
and never will read the C language standard, it does look like the p
pointer is "truncated" to an integer valued 0 or 1, in boolean context.

And as I told Keith, I don't care how the language standard words
things.  I care how the compiler is implemented.

                                .________________________.
             ,-'""`-.          (                          )
            ;        :    o 0 ( I also added some more old )
           :          :        ( ASCII art, and re-added )
           : (_)  (_) ;       ( alt.ascii-art for cross )
            `   '`   '         ^^( posting purposes! )^^
             :`++++';             ^(._______________.)
              ``..''  /mv/



Happy writing articles for VICE!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com