Re: cvs commit: src/sys/sys errno.h

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Sun, Jul 03, 2005 at 03:31:55PM +0100, Hiten Pandya wrote:
> 	Joerg, the problem originates in our codebase so it is not technically the
> responsibility
> 	of upstream code maintainer.  Above that our MAIN priority is to make sure
> that we don't
> 	break the hundreds of already-compiled applications.

Read the comments from both Jeroen and me. The behaviour of errno.h is
perfectly in the bounds of the standard. The use in the programs is not.
So yes, they are technically responsible. BTW, change your line wrapping
settings, it reads very annoying :)

> 	Unless the project wants to loose prospective users we shouldn't force the
> dogmatic
> 	attitude of "recompile it source because we have done it in a clean way,
> blah" etc.  Most
> 	of the users do not really care about the source code as much they care about
> their
> 	applications working in one piece.

This is not so much about recompilation, but about correctness of code. The problem
here is that staying compatible with the historic practise actually hinders future
development. There's still a lot of code out there which wants to define e.g. strcpy
manually. This means we can't change the definition to include e.g. restrict, without
breaking such code. What is better? Breaking code which lives in the K&R days or
following standards?

To summarize the situation: "extern int errno;" is INCORRECT. It is undefined behaviour
and unnecessary for any platform which has errno.h and ANSI C headers. If there are
still platforms out there, which have errno.h and don't define errno, all projects I've
seen which had explicit defines would break *anyway*, because they don't do it
consistently.

Joerg