Yeah, I think the complaint is mainly about possible loss of precision so (I may be wrong), the float to int cast might be fine.
> On Dec 2, 2017, at 11:57 PM, Miller Puckette <[email protected]> wrote: > > Or (aha) - I could make up new function names for the "int" versions and > change the pd sources to use them, and declare the existing ones obsolete...? > > In fact, is there any reason one can't just globally replace every call > to atom_getint and atom_getintarg with the atom_getfloat equivalent - let > externs blithely call atom_getint and get a t_int back all they want. > > That would touch a lot of files so if I do it perhaps I should make sure > to do all the PR-merging I possibly can beforehand. > > AND: there's no reason I can't assign a float to an int without a cast, is > there? As I understand it the only clang complaint is int-to-smaller-int > conversions. So int x = atom_getfloat(&atom) is still kosher, correct? > > thanks > Miller > On Sat, Dec 02, 2017 at 02:50:57PM -0800, Miller Puckette wrote: >> I think the use of "t_int" in m_pd.h is incorrect - it should have been >> int. But it's a mistake I think is now ironed in and we're stuck with it. >> >> >> M >> >> On Sat, Dec 02, 2017 at 10:25:07PM +0100, Dan Wilcox wrote: >>> I was following IOhannes' prompt about t_int: "rule of thumb: never use it >>> for anything but passing data to perform-routines." >>> >>>> On Dec 2, 2017, at 10:22 PM, Miller Puckette <[email protected]> wrote: >>>> >>>> I'm pretty confused about this. I believe it was "t_int" in 0.48-0, and >>>> I see that your PR changesit from "t_int" to "int" - and I believe >>>> it has to be "t_int" for back compatibility... >>>> >>>> cheers >>>> M >>>> >>>> On Sat, Dec 02, 2017 at 10:16:44PM +0100, Dan Wilcox wrote: >>>>> I think I had already fixed this: >>>>> https://github.com/pure-data/pure-data/pull/223 >>>>> <https://github.com/pure-data/pure-data/pull/223> (?) Or am I missing >>>>> something? >>>>> >>>>>> On Dec 2, 2017, at 8:40 PM, Miller Puckette <[email protected]> wrote: >>>>>> >>>>>> I had one small ouch: I don't think I can compatibly change t_int to int >>>>>> in m_pd.h (this is mentioned on another thread somewhere). I don't know >>>>>> how >>>>>> to make clang pipe down about this short of casting almost every call to >>>>>> atom_getint*() in the whole tree. Yuck... Maybe it's better just to >>>>>> tell >>>>>> clang to be more permissive (if that's possible)? >>>>> >>>>> -------- >>>>> Dan Wilcox >>>>> @danomatika <http://twitter.com/danomatika> >>>>> danomatika.com <http://danomatika.com/> >>>>> robotcowboy.com <http://robotcowboy.com/> >>>>> >>>>> >>>>> >>> >>> -------- >>> Dan Wilcox >>> @danomatika <http://twitter.com/danomatika> >>> danomatika.com <http://danomatika.com/> >>> robotcowboy.com <http://robotcowboy.com/> >>> >>> >>> >> >>> _______________________________________________ >>> Pd-dev mailing list >>> [email protected] >>> https://lists.puredata.info/listinfo/pd-dev >> >> >> _______________________________________________ >> Pd-dev mailing list >> [email protected] >> https://lists.puredata.info/listinfo/pd-dev -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
