Am Montag, den 20.01.2014, 11:12 +0100 schrieb John Spencer:
> what rich had in mind was usage of _Generic in the x32 __scc 
> (syscall-cast) macro:
> 
> instead of
> 
> #define __scc(X) sizeof(1?(X):0ULL) < 8 ? (unsigned long) (X) : (long 
> long) (X)
> 
> something along the lines of
> _Generic((X), struct timespec*: &(struct timespec){.sec = (X).sec, .nsec 
> = (X).nsec}, default: sizeof(1?(X):0ULL) < 8 ? (unsigned long) (X) : 
> (long long) (X))

ah, I see how _Generic could pop in an make some wrappers for
architecture specific code nicer

In the concrete case I don't understand too well. The return type of
that generic expression would be of a fundamentally different type,
once a pointer to struct, otherwise an integer. Also the two struct
types should be different types, no? One the userland type and the
other the kernel type?

But then something like

&(struct kernel_timespec){.sec = (X)->sec, .nsec = (X)->nsec}

should suffice to capture the transition well.

This would certainly benefit of a wrapper function
kernel_timespec_copy, because it evaluates X twice :


kernel_timespec_copy(&(struct kernel_timespec){0}, (X))


If you want that for optimization reasons you could try to capture if
the two types agree and avoid the extra copy. Something along the
line of

_Generic((X),
        struct kernel_timespec*: (X),
         default: kernel_timespec_copy(&(struct kernel_timespec*){0}, (X))
        )

But I am not convinced that this can't be just achieved by doing some
#ifdef programming


> however the only available compiler implementing _Generic is Clang.
> not even GCC 4.8.2 supports it. however i've seen some pseudo _Generic 
> implementation on your blog [1], imo we could use the bits described 
> there, namely
> "
>      __typeof__(EXP) gives the type of the expression EXP
>      __builtin_types_compatible_p(T1, T2) is true if the two types are 
> compatible
>      __builtin_choose_expr(CNTRL, EXP1, EXP2) choose between the two 
> expressions at compile time.
> "
> 
> to implement the above macro, as x32 requires a very recent GCC (>= 4.7) 
> anyway, i see no big problem in using those gcc helpers in lieu of _Generic.

These features are supported since long in gcc and clang, I think, so
yes from that side there certainly would be not much of an obstacle.

But I wouldn't think that using such a feature just in such an
isolated spot (very restricted part of code and very specific
architecture) would be worth it.

Some cooked down version of _Generic could perhaps be beneficial for
the whole of musl, there are some places that implement type
genericity in some handcrafted way. But these things need macro magic
and should not be re-implemented at each point where they are
needed. So probably much too intrusive at this point in time.

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 ::