christos@ wrote: > Until that stops working, or being available. I think we should > let the majority decide what's appropriate.
One major problem of the NetBSD Project is that we don't have any well defined procedure to get majority. (we don't have enough activities or a person like Linus unfortunately) Persons who posted patches before commit were often blocked by bikeshed, and persons who committed changes without review (or even tests) always won by objecting (even just "I don't think so") all post claims. Only core might handle technical issue, but it looks core's decisions always ignore non-technical matters (resources, marketing, users etc). > | It's much worse to commit untested broken code. > > That was fixed and you tested it I presume. Unfortunately I didn't test your code at all because I objected it (the first rev was obviously broken anyway) and it was reverted per your approval: http://mail-index.netbsd.org/source-changes-d/2014/11/15/msg007338.html After you read other developer's post you started to claim to strictly follow -fstrict-aliasing and use memcpy() to achieve it but you always ignored my request (to use u_int16_t assignments consistently), so I still cannot see what is ok for you other than memcpy (or be16enc) since I'm not a good C programmer and it's unclear if you are ok to use pointer conversions via (void *). At first you answered it didn't work http://mail-index.netbsd.org/source-changes-d/2014/11/13/msg007326.html and in the next you said it was legal. http://mail-index.netbsd.org/source-changes-d/2014/11/16/msg007356.html Anyway, per your second mail it looks you are ok to pass a structure pointer to a function via (void *) arg so I'll add a new function to set u_int16_t cksum at proper offset in the boot sector using u_int16_t assignment as current abcksum() function does. If you still don't like it, please propose a patch which satisfies both requests as martin said, not repeating your "memcpy is ok and -fstrict-aliasing is more important" claim. --- Izumi Tsutsui
