[compatibility] heirloom tools

[compatibility] heirloom tools

[Valentin Ochs]

[-- Attachment #1: Type: multipart/signed, Size: 1022 bytes --]

Re: [compatibility] heirloom tools

[Rich Felker]

On Mon, Apr 11, 2011 at 10:27:13PM +0200, Valentin Ochs wrote:
> cpio:	needs <sys/mtio.h>
> dd:	needs <sys/mtio.h>

I can add this.. are people *really* still using tape devices? Seems
like 15¢ DVDs would be a lot more cost-effective and faster...

> priocntl:	undefined references to sched_* stuff. I guess that's not been
> 	implemented yet, even if it's in the headers?

For now, musl does not support the POSIX priority scheduling options.
Adding syscall wrappers would be easy, but in many ways would be worse
than the current situation -- if you have realtime/priority scheduling
but your synchronization primitives are not carefully audited to make
sure they give the correct semantics for which thread/process gets the
resource when there's contention, use of nondefault priorities will
result in deadlocks.

A quick fix might be to implement the functions but make them return
errors for all priorities except 0 (the default).

> shl:	needs wordexp() and wordfree()

Wow, something actually uses this function? I have an idea for
implementing it as a shell script passed on the command line to
/bin/sh via exec.

> test:	sed -i 's/S_IREAD/S_IRUSR/g;s/S_IWRITE/S_IWUSR/g;s/S_IEXEC/S_IXUSR/g;' test/test.c test/helper.c

These legacy aliases can be added under _GNU_SOURCE... done.

> 	defs.h needs to include <sys/types.h>
> users:	needs utmpxname()
> who:	needs ut_exit in const struct utmpx (there's a __ut_exit there)

utmpx.h was removed from POSIX 2008, and is now a "nonstandard
header", so I can happily add to it whatever is deemed useful. I'll
just rename __ut_exit to ut_exit.

Rich

Re: [compatibility] heirloom tools

[Christian Neukirchen]

Rich Felker <dalias@aerifal.cx> writes:

>> test:	sed -i 's/S_IREAD/S_IRUSR/g;s/S_IWRITE/S_IWUSR/g;s/S_IEXEC/S_IXUSR/g;' test/test.c test/helper.c
>
> These legacy aliases can be added under _GNU_SOURCE... done.

And _BSD_SOURCE, I guess.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: [compatibility] heirloom tools

[Rich Felker]

On Tue, Apr 12, 2011 at 06:35:51PM +0200, Christian Neukirchen wrote:
> Rich Felker <dalias@aerifal.cx> writes:
> 
> >> test:	sed -i 's/S_IREAD/S_IRUSR/g;s/S_IWRITE/S_IWUSR/g;s/S_IEXEC/S_IXUSR/g;' test/test.c test/helper.c
> >
> > These legacy aliases can be added under _GNU_SOURCE... done.
> 
> And _BSD_SOURCE, I guess.

I've been rather inconsistent in use of _BSD_SOURCE, and not sure I
want to support it at all. The idea was that I've included a few BSD
functions like lchmod and strlcpy which are NOT in glibc, so it didn't
make sense to put their prototypes under _GNU_SOURCE. But as it
stands, _BSD_SOURCE enables only these things, not all the other BSD
features that are under _GNU_SOURCE, which differs from every other
library's behavior and doesn't seem all that useful. And adding
"|| defined(_BSD_SOURCE)" all over the place in all the headers seems
like just more clutter... I may just move all the BSD extensions under
_GNU_SOURCE anyway, even if they're not in glibc, and be done with it
- that way, a single feature test macro can enable all the "legacy and
nonstandard extension" functions.

Thoughts on if this is a good idea?

Rich

Re: [compatibility] heirloom tools

[Rich Felker]

On Mon, Apr 11, 2011 at 10:27:13PM +0200, Valentin Ochs wrote:
> echo:	needs to include <sys/types.h>

Can you tell me what it needs from sys/types.h? It's possible I've
mistakenly omitted whatever it is from some other header that should
be providingit.

> nawk:	does some weird shit with PASTA definitions that I'm too lazy to
> 	debug

PASTA?

> test:	sed -i 's/S_IREAD/S_IRUSR/g;s/S_IWRITE/S_IWUSR/g;s/S_IEXEC/S_IXUSR/g;' test/test.c test/helper.c
> 	defs.h needs to include <sys/types.h>

And same here..

Rich

Re: [compatibility] heirloom tools

[Valentin Ochs]

[-- Attachment #1: Type: multipart/signed, Size: 1242 bytes --]