This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hello! On Wed, Dec 17, 2008 at 09:50:33AM -0800, Ulrich Drepper wrote: > Thomas Schwinge wrote: > > Why are these changes ``unnecessary and wrong''? > > They are obviously unnecessary since the existing code works fine. Apart from fixing breakage there is also this thing called improvement. And, taking an example from my patches, I was adding an improvement -- a preprocessor macro to be exact -- to the generic code that allows for using compile-time assertions inside glibc. It would be against all good and established traditions of software-writing craftsmen to put such a general definition into a system-specific file. I don't think I really have to explain that to you. Of course I totally understand that you can't let random junk go into glibc -- and I would do it just the same way than you're doing -- but there are people, including me, sending patches that aren't to be considered junk and nevertheless aren't put in, only because you don't see the direct need for it in the glibc Linux port. Taking the above example further, in the Linux code base you, exactly you, added exactly the same compile-time checks for these constants: commit e38b36f325153eaadd1c2a7abc5762079233e540 -- ``flag parameters: check magic constants''. Now it happens that for the Hurd implementing this part of socket functionality isn't done inside the kernel as it is for Linux, but it's implemented inside glibc. That's why these checks should be in glibc as well. And as they're not system-specific, they shouldn't be in a system-specific file. And I'm very sure that you know all this, so why do you reject this nevertheless? > And it's wrong since not all platforms fulfill the assumptions. Which assumptions did I break? I certainly took care to not break anything, so please tell me! > Stick with hurd, I don't care how much you screw that up. But don't > touch the rest unless there is a real problem. The Hurd is said to be an officially supported target for glibc, so you should as well care a little bit about it. And I don't even and never have ask you to do the leg work. Just, please, be a bit more cooperative! I mean, what's lost by keeping glibc more portable than having it target just the Linux kernel? Regards, Thomas
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |