[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Jan 2014 09:29:01 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Discussion of partly-invasive changes needed for x32 port
Hello,
Am Montag, den 20.01.2014, 18:57 -0500 schrieb Rich Felker:
> Where? In every file that passes timespecs to syscalls? The whole
> point is to follow my basic principle that workarounds for buggy
> platforms (which the kernel's x32 support is) belong in places where
> nobody has to see them unless they're working with the buggy platform
> in question. This is a principle I first proposed and promoted while
> working on MPlayer, and later applied as a critique of frameworks like
> NSPR, APR, etc. The classic example of this principle goes like this:
> For a cross-platform application or library, instead of having #ifdef
> WIN32 all over the place and windows-specific code interleaved all
> over the general, non-platform-specific code, one should provide
> replacement headers or library code that fix the behavior of the
> windows headers or runtime to conform to the standards they're
> ignoring, and then write the code shared between platforms to portable
> C/POSIX. BTW in some ways gnulib also follows this principle, except
> that it assumes by default the target system is broken and needs fixes
> which are inherently non-portabke. If you instead assume by default
> that the target is non-broken, and only apply fixes to a known finite
> set of broken platforms, you have much less chance of breaking things
> and also keep the ugly hacks out of the way of developers not
> specifically dealing with porting to the broken system(s).
>
> That's the motivation here.
sure, system dependent #ifdef are a plague, you are absolutely right
but feature dependent ones are not as bad, I think, there is a big
difference in maintainability between
#if WIN32 > 47
typedef unsigned long total_t;
#endif
and
#if ULONG_MAX == ULLONG_MAX
typedef unsigned long total_t;
#else
typedef unsigned long long total_t;
#endif
_Generic macros are not so much different from that. At the point of
declaration you'd have to understand and maintain the different
branches that such a macro could take. They have the advantage of
being type oriented, instead of being value oriented. But the
disadvantage of spreading the decisions to everywhere in the code,
potentially leading to longer compilation times. (Some of the macros I
have bring gcc to its knees :)
> Right now the only magic type-generic macros in musl are in tgmath.h
> and internal/syscall.h.
I would have thought that there already are more, but you certainly
know the code much better than I do.
> So I think we're okay without any more general
> _Generic framework for now.
Once you are starting to implement C11 library features, you are going
to need more, I think. Implementing C11 atomics without it would be a
real challenge.
Jens
--
:: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ ::
:: AlGorille ::::::::::::::: office Nancy : +33 383593090 ::
:: ICube :::::::::::::: office Strasbourg : +33 368854536 ::
:: ::::::::::::::::::::::::::: gsm France : +33 651400183 ::
:: :::::::::::::::::::: gsm international : +49 15737185122 ::
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.
