[PD-dev] externals implementing PD_FLOAT_PRECISION can't be compiled against pure-data, libpd, pd-l2ork etc

Hans-Christoph Steiner hans at at.or.at
Sat Nov 12 16:43:23 CET 2011


That's a good idea for now for a workaround. 

In the case of type-punning, I think that code should be replaced with something that uses a different technique rather than making separate type punning for 32 and 64 bits.  I think unions can be used in many of those situations.  Type punning is very deprecated and not allowed in the C99 standard (which is 12 years old).

.hc

On Nov 12, 2011, at 9:56 AM, katja wrote:

> To answer my own mail, let's just do this whenever using PD_FLOAT_PRECISION:
> 
> #ifndef PD_FLOAT_PRECISION
> #define PD_FLOAT_PRECISION 32
> #endif
> 
> to make sure code remains compilable against all sorts of Pd. When
> PD_FLOAT_PRECISION is not defined, it is safe to assume t_float etc
> are float.
> 
> Katja
> 
> 
> 
> On Sat, Nov 12, 2011 at 3:30 PM, katja <katjavetter at gmail.com> wrote:
>> We now have PD_FLOAT_PRECISION in the Pd-extended API (even though
>> it's value is still fixed at 32) and in Pd-double. This macro is
>> sometimes needed for conditional compilation when making external libs
>> ready for double precision. For example, to call sf_read_float() or
>> sf_read_double() in libsndfile, or in case of a type punning trick
>> which must be defined according to data type.
>> 
>> Libs which use PD_FLOAT_PRECISION for such reason, are no longer
>> compilable against pure-data, libpd, pd-l2ork and other types of pd.
>> This is now the case for creb and smlib, for which I committed
>> double-ready changes this week.
>> 
>> Before I proceed committing to other libs, this issue should discussed
>> with authors and maintainers of pure-data, it's forks, and external
>> libraries. Historically, external libs have always been compilable
>> against Pd flavours other than Pd-extended, no? It would be an awkward
>> experience for anyone unsuspectingly copying a lib's latest revision
>> from pure-data.svn and find it's no longer compatible with Pd other
>> than Pd-extended and Pd-double! Technically, the solution is simple: a
>> line '#define PD_FLOAT_PRECISION 32' in the API's would restore
>> compatibility, when t_float etc. are still typedef'ed as float. It is
>> not so elegant we have to bother many people with our double precision
>> efforts, but it's impossible to develop this in isolation.
>> 
>> Katja
>> 
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev





----------------------------------------------------------------------------

"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman





More information about the Pd-dev mailing list