[CELT-dev] CELT grabbing 100KB of memory right off the top
jmvalin at jmvalin.ca
Mon Apr 18 20:44:33 PDT 2011
So right now, compiling with C89 compilers requires you to put
in your config.h. What you're proposing is to instead have
Aside from having to type 5 more characters, I'm not sure what you're
On 11-04-18 11:20 PM, Brett Paterson wrote:
> "Lots of people build CELT fine on non-C99 compilers."
> not without a lot of manual patching each time a new celt is released. I
> think i've mentioned several of these issues on IRC, restrict and inline
> being the worst offenders.
> CELT_RESTRICT and CELT_INLINE would be most appreciated. I have to patch
> this in each time and it's not trivial.
> Brett Paterson | CEO
> FMOD by Firelight Technologies Pty Ltd
> Interactive Audio Middleware | www.fmod.org
> PH: +61 3 96635947 Fax: +61 3 96635951
> -----Original Message-----
> From: celt-dev-bounces at xiph.org [mailto:celt-dev-bounces at xiph.org] On Behalf
> Of Jean-Marc Valin
> Sent: Tuesday, 19 April 2011 12:44 PM
> To: Ross Bencina
> Cc: celt-dev at xiph.org
> Subject: Re: [CELT-dev] CELT grabbing 100KB of memory right off the top
> These sorts of features are meant to be handled by the config.h file.
> Same for inline, fixed-point, stack allocation and others. Lots of
> people build CELT fine on non-C99 compilers.
> On 11-04-18 10:09 PM, Ross Bencina wrote:
>> Timothy B. Terriberry:
>>> What's wrong with passing -Drestrict ? Anything can be a macro in C.
>> What's wrong with writing portable code that can compile out of the box
>> compilers other than gcc?
>> imho if code is intended to be portable, C99 features should be used as an
>> optional enhancement, not a baseline requirement. Code can (and should) be
>> written accordingly. For example, detect if restrict is available rather
>> than assuming it is.
>> I have experienced the same hurdles trying to get CELT to compile under
>> non-gcc compilers and I too find it surprising that a baseline
>> implementation like this would assume C99 as a requirement.
>> (a CELT user who uses multiple compiler toolchains on a daily basis)
>> celt-dev mailing list
>> celt-dev at xiph.org
> celt-dev mailing list
> celt-dev at xiph.org
More information about the celt-dev