Conversation

Notices

1. Embed this notice
   John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:02:59 JST John Regehr

   • Rich Felker
   • Patrick Lam :tinoflag:
   • David Andersen
   • Sobex
   • Chip Christian

   @Sobex @dave_andersen @va2lam @zwol @chipchristian hey @dalias -- I just took a super quick look at MUSL's mallocng and it seems to be dereferencing typecast pointers in ways that might violate strict aliasing. do you mind telling us why this isn't a problem? maybe you insist that this is compiled with strict aliasing disabled?

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:02:59 JST Rich Felker

     in reply to

     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @regehr @Sobex @dave_andersen @va2lam @zwol @chipchristian I don't think so. All of the accesses are to objects with no declared type and the type used in the access should match the most recent stored type or else be a char type.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:11:05 JST Rich Felker

     in reply to

     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @regehr @Sobex @dave_andersen @va2lam @zwol @chipchristian No, again, the effective type rules of C handle all this. The memory has no declared type so the only potential effective type UB is when an application accesses uninitialized memory from malloc that may still have the old effective type, without having stored something to it first.

   • Embed this notice
     John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:11:06 JST John Regehr

     in reply to

     • Rich Felker
     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @dalias @Sobex @dave_andersen @va2lam @zwol @chipchristian ah, super cool. not something I can verify with quick inspection :).

     but then eventually, memory is going to be repurposed, for example when you split a block that has already been used by the client. in that case we're just relying on separate compilation, I suppose?

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:19:11 JST Rich Felker

     in reply to

     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @regehr @Sobex @dave_andersen @va2lam @zwol @chipchristian The only real flaw of the effective type rules is that they don't unambiguously define a single active effective type, rather a set of possible effective types, but don't acknowledge this.

   • Embed this notice
     John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:25:10 JST John Regehr

     in reply to

     • Rich Felker
     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @dalias @Sobex @dave_andersen @va2lam @zwol @chipchristian I thought effective type was conferred when you first store to the typeless memory, and remains the same after that

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:25:10 JST Rich Felker

     in reply to

     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @regehr @Sobex @dave_andersen @va2lam @zwol @chipchristian Nope, it's set by each store.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:27:08 JST Rich Felker

     in reply to

     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @regehr @Sobex @dave_andersen @va2lam @zwol @chipchristian Like much of C though, the wording is poor, you have to read in detail to get that point, and WG14 doesn't seem to think this is a problem...

   • Embed this notice
     John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:27:09 JST John Regehr

     in reply to

     • Rich Felker
     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @dalias @Sobex @dave_andersen @va2lam @zwol @chipchristian ah, no problem then!

   • Embed this notice
     John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:28:56 JST John Regehr

     in reply to

     • Rich Felker
     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @dalias @Sobex @dave_andersen @va2lam @zwol @chipchristian yeah I imagine that at present, a lot of code works only due to separate compilation

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:28:56 JST Rich Felker

     in reply to

     • Patrick Lam :tinoflag:
     • David Andersen
     • Sobex
     • Chip Christian

     @regehr @Sobex @dave_andersen @va2lam @zwol @chipchristian AKA TU boundary as compiler barrier.