#define __MUSL__ in features.h

#define __MUSL__ in features.h

[Daniel Cegiełka]

[-- Attachment #1: Type: text/plain, Size: 139 bytes --]

Is it possible to add to the features.h __MUSL__ definition?

glibc can be identified by __GLIBC__, uclibc through __UCLIBC__ etc.

Daniel

[-- Attachment #2: Type: text/html, Size: 202 bytes --]

Re: #define __MUSL__ in features.h

[Rich Felker]

On Fri, Mar 29, 2013 at 09:44:05PM +0100, Daniel Cegiełka wrote:
> Is it possible to add to the features.h __MUSL__ definition?
> 
> glibc can be identified by __GLIBC__, uclibc through __UCLIBC__ etc.

Is this question in the FAQ yet? If not, it really should be. The
answer is no, it won't be added, because it's a bug to assume a
certain implementation has particular properties rather than testing.
So far, every time somebody's asked for this with a particular usage
case in mind, the usage case was badly wrong, and would have broken
support for the next release of musl...

Rich

Re: #define __MUSL__ in features.h

[Daniel Cegiełka]

[-- Attachment #1: Type: text/plain, Size: 53 bytes --]

I understand. Thank you for the explanation.

Daniel

[-- Attachment #2: Type: text/html, Size: 110 bytes --]

Re: #define __MUSL__ in features.h

[LM]

On 3/29/13, Rich Felker <dalias@aerifal.cx> wrote:
> On Fri, Mar 29, 2013 at 09:44:05PM +0100, Daniel Cegiełka wrote:
>> Is it possible to add to the features.h __MUSL__ definition?
>>
>> glibc can be identified by __GLIBC__, uclibc through __UCLIBC__ etc.
>
> Is this question in the FAQ yet? If not, it really should be. The
> answer is no, it won't be added, because it's a bug to assume a
> certain implementation has particular properties rather than testing.
> So far, every time somebody's asked for this with a particular usage
> case in mind, the usage case was badly wrong, and would have broken
> support for the next release of musl...

Was thinking an identifier like __MUSL__ would be useful as well.  So
what would be the best way to identify that this compiler is different
than the default system compiler for an example like openssl's
ui_openssl.c file?  The patch at
https://bitbucket.org/GregorR/musl-pkgsrc-patches/src/6becfeda746a4c456474f1aff0b21701b27e9d0d/security-openssl.diff?at=default
just uses sed to replace things.  I came up with something similar as
well when I was attempting to build openssl.  Needed to conditionally
define TERMIOS and undef TERMIO.  Would be nice if this could be done
in the code using ifdefs instead of with sed, so that the patch could
be sent back to the openssl developers.

Re: #define __MUSL__ in features.h

[Szabolcs Nagy]

* LM <lmemsm@gmail.com> [2013-03-30 11:39:27 -0400]:
> well when I was attempting to build openssl.  Needed to conditionally
> define TERMIOS and undef TERMIO.  Would be nice if this could be done
> in the code using ifdefs instead of with sed, so that the patch could
> be sent back to the openssl developers.

no, this should be fixed by openssl using
their huge configuration script correctly,
ie. detecting what is available instead of
using wrong ifdefs

their assumptions about termios is broken,
adding more ifdefs would just make it worse
(note that termios.h is specified by posix
so even if they want to use ifdefs, that
should be the fallback on a posix system)

Re: #define __MUSL__ in features.h

[Strake]

LM <lmemsm@gmail.com> wrote:
> Was thinking an identifier like __MUSL__ would be useful as well.  So
> what would be the best way to identify that this compiler is different
> than the default system compiler for an example like openssl's
> ui_openssl.c file?

Don't.

> The patch at
> https://bitbucket.org/GregorR/musl-pkgsrc-patches/src/6becfeda746a4c456474f1aff0b21701b27e9d0d/security-openssl.diff?at=default
> just uses sed to replace things.

I note the repeated "f x >x.mod; mv x.mod x" scheme. I wrote this to
do so, ∀ f: https://github.com/strake/situ
The code would thus be clearer.

> I came up with something similar as
> well when I was attempting to build openssl.  Needed to conditionally
> define TERMIOS and undef TERMIO.  Would be nice if this could be done
> in the code using ifdefs instead of with sed, so that the patch could
> be sent back to the openssl developers.

Szabolcs Nagy <nsz@port70.net> wrote:
> no, this should be fixed by openssl using
> their huge configuration script correctly,
> ie. detecting what is available instead of
> using wrong ifdefs
>
> their assumptions about termios is broken,
> adding more ifdefs would just make it worse
> (note that termios.h is specified by posix
> so even if they want to use ifdefs, that
> should be the fallback on a posix system)

Yes, in my experience, openssl is grievous to build, and I can't
remember all what perversions I wrought to do so, but both -DTERMIOS
and -DTERMIO are in Configure, so it may well be at fault.

Re: #define __MUSL__ in features.h

[Rich Felker]

On Sat, Mar 30, 2013 at 02:16:48PM -0500, Strake wrote:
> Szabolcs Nagy <nsz@port70.net> wrote:
> > no, this should be fixed by openssl using
> > their huge configuration script correctly,
> > ie. detecting what is available instead of
> > using wrong ifdefs
> >
> > their assumptions about termios is broken,
> > adding more ifdefs would just make it worse
> > (note that termios.h is specified by posix
> > so even if they want to use ifdefs, that
> > should be the fallback on a posix system)
> 
> Yes, in my experience, openssl is grievous to build, and I can't
> remember all what perversions I wrought to do so, but both -DTERMIOS
> and -DTERMIO are in Configure, so it may well be at fault.

Indeed, using termio (without the s) at all is _wrong_ unless you're
on a horribly outdated legacy system. The default should always be
termios and termio should only be used on systems that are detected or
known to be lacking termios.

Rich

Re: #define __MUSL__ in features.h

[dgutson .]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

> On Fri, Mar 29, 2013 at 09:44:05PM +0100, Daniel Cegiełka wrote:
> > Is it possible to add to the features.h __MUSL__ definition?
> >
> > glibc can be identified by __GLIBC__, uclibc through __UCLIBC__ etc.
>
> Is this question in the FAQ yet? If not, it really should be. The
> answer is no, it won't be added, because it's a bug to assume a
> certain implementation has particular properties rather than testing.

That is a beautiful theory in an ideal world, but in the real world,

implementations have bugs, and sometimes we need to workaround these bugs.

(e.g. the FD* issue reported by Martin Galvan).

So when writing code that should work with different implementations, these

macros are needed to apply workarounds for implementation-specific bugs.

That's why all the rest of the C lib implementations do provide an identifying

macro, something that I think musl should also do, IMVHO.


    Daniel.


> So far, every time somebody's asked for this with a particular usage
> case in mind, the usage case was badly wrong, and would have broken
> support for the next release of musl...

>

> Rich



-- 
Who’s got the sweetest disposition?
One guess, that’s who?
Who’d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

[-- Attachment #2: Type: text/html, Size: 5457 bytes --]