Re: Patches to improve Hurd parts: include/sys/socket.h

[Thomas Schwinge <tschwinge at gnu dot org>]

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