[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140329171946.GV26358@brightrain.aerifal.cx>
Date: Sat, 29 Mar 2014 13:19:46 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: paths.h and similar constants, internal usage?
On Sat, Mar 29, 2014 at 08:38:57AM +0000, u-igbb@...ey.se wrote:
> Hello,
>
> I noticed that musl defines certain constants but does not use them
> even when it could. I find if better in the long run to have
> a single definition of a string instead of multiple ones, for
> various reasons.
>
> Would it be suitable for upstream to make use of the available symbolic
> constants in the following cases where explicit strings are being used
> instead:
paths.h is just there for making some bad legacy apps happy. It's not
a system we want to use.
As for changing these paths, it's of course something you can do by
changing the source and I can't keep you from doing it, but it's also
not something I have an interest in making easy/automated. For the
most part, changing them has no purpose except making it so your
static binaries don't work on normal systems. musl aims to make
minimal assumptions about pathnames, and those which it does assume
are either required by standards, de facto requirements for
compatibility with anything (e.g. the shell has to be at /bin/sh for
scripts to work anyway), or historically so universal that any system
can be expected to have them.
Anyway, if you have specific requirements you're trying to find a
solution to, please let us know what you're doing. For any request
like this, a strong motivation is needed.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
