Public
- Public
- Network
- Groups
- Featured
- Popular
- People

Conversation

Notices

Embed this notice
John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:02:59 JST John Regehr
@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?

In conversation about 4 months ago from mastodon.social permalink
- Embed this notice
  Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:02:59 JST Rich Felker
  in reply to
  @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.
  
  In conversation about 4 months ago permalink
- Embed this notice
  Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:11:05 JST Rich Felker
  in reply to
  @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.
  
  In conversation about 4 months ago permalink
- Embed this notice
  John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:11:06 JST John Regehr
  in reply to
  @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?
  
  In conversation about 4 months ago permalink
- Embed this notice
  Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:19:11 JST Rich Felker
  in reply to
  @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.
  
  In conversation about 4 months ago permalink
- Embed this notice
  John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:25:10 JST John Regehr
  in reply to
  @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
  
  In conversation about 4 months ago permalink
- Embed this notice
  Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:25:10 JST Rich Felker
  in reply to
  @regehr @Sobex @dave_andersen @va2lam @zwol @chipchristian Nope, it's set by each store.
  
  In conversation about 4 months ago permalink
- Embed this notice
  Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:27:08 JST Rich Felker
  in reply to
  @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...
  
  In conversation about 4 months ago permalink
- Embed this notice
  John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:27:09 JST John Regehr
  in reply to
  @dalias @Sobex @dave_andersen @va2lam @zwol @chipchristian ah, no problem then!
  
  In conversation about 4 months ago permalink
- Embed this notice
  John Regehr (regehr@mastodon.social)'s status on Thursday, 16-Jan-2025 03:28:56 JST John Regehr
  in reply to
  @dalias @Sobex @dave_andersen @va2lam @zwol @chipchristian yeah I imagine that at present, a lot of code works only due to separate compilation
  
  In conversation about 4 months ago permalink
- Embed this notice
  Rich Felker (dalias@hachyderm.io)'s status on Thursday, 16-Jan-2025 03:28:56 JST Rich Felker
  in reply to
  @regehr @Sobex @dave_andersen @va2lam @zwol @chipchristian AKA TU boundary as compiler barrier.
  
  In conversation about 4 months ago permalink

Public

Conversation

Notices

Feeds