00:59 <aaabbb> oh great, it's +r now :(

00:59 <aaabbb> if i /part i won't be able to rejoin, has the spammer been taken care of by removing his hetzner account?

02:29 <BBB> aaabbb: we'll have to be like this for a few days, sorry about that

02:34 <aaabbb> ok, just a few days is fine. i was worried it would be the new normal

08:43 <elenril> why do people no register

08:57 <j-b> elenril: for the FBI not to track us

08:58 <elenril> you can create a pseudonymous email for such purpose

08:58 <elenril> everyone should have at least a few of these anyway

09:03 <j-b> elenril: you clearly underestimate the FBI

12:52 <BBB> aaabbb: it depends on how persistent the spammer is. if he goes away, we'll remove +r. if he returns, we have to re-assess

14:33 <courmisch> it's not spam. the motivation doesn't seem commercial

18:40 <Lynne> is it legal to cast a pointer to a union to a pointer of a struct type present in the union?

18:41 <jamrial> why would you have a pointer to a union instead of to one of the types inside it?

18:45 <Lynne> the caller calls a function with a union ptr as an arg, but doesn't know what struct type it's getting

18:46 <nevcairiel> if you have a pointer to the union itself, cant you just access the member in it you want and potentially make a pointer of it, not casting?

18:50 <Lynne> no, the callee passes different structs to different functions which all take a pointer to a regular struct

18:56 <Lynne> also, is it legal to have something like union { uint8_t cnt; struct_which_starts_with_uint8_t str; }, to modify str.cnt by writing to cnt?

19:19 <courmisch> Lynne: the cast itself is legal but that does not absolve aliasing violations whilst dereferencing the point later on

19:31 <Gramner> type punning using unions is valid. it doesn't even need to be the same type - "If the member used to read the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type"

20:42 <cosminaught> when I send patches to the mailing list with git send-email the from looks like “… via ffmpeg-devel” with the devel mailing list address instead of my email address. However patches I see from others on the list have their email address in the from. Am I configuring my git send-email incorrectly in some way for my address to get anonymized like this?

20:43 <cosminaught> Or is it something about my mailing list subscription settings?

20:44 <elenril> I think it's about your mail server config

20:48 <JEEB> I think the mailing list modifies the email's contents, so if your mail server has configured its security shenanigans well, the mailing list cannot send stuff in your name (email). which is why certain people's emails get modified to instead be something something via ffmpeg-devel

20:52 <cosminaught> ah makes sense

21:27 <wbs> if one could tell git-format-patch about this in advance, it could add a From: header to the body of the mail, like it does if git author!=<own identity>, and things would be fixed when the patch is applied

21:53 <cosminaught> I think I can make it do that by changing the from it uses to be different than the commit author, it only collapses the two when they are the same