search for: int_fast32_t

...; is not required, but values in *tmp + * are changed in decoding process. + * + * RETURN VALUE + * if OK, a pointer to a decoded string malloc-ed + * else , NULL + * + * SEE ALSO RFC3397 + */ +static char *bootp_ext119_decode(const void *ext, int16_t ext_size, void *tmp) +{ + uint8_t *u8ext; + int_fast32_t i; + int_fast32_t decoded_size; + int_fast8_t currentdomain_is_singledot; + + /* only for validating *ext */ + uint8_t *is_pointee; + int_fast32_t is_pointee_size; + + /* only for structing a decoded string */ + char *decoded_str; + int_fast32_t dst_i; + + if (ext == NULL || ext_size <= 0 || tmp...

Please change all longs to int, and never use them in the future :) They arent needed as on most platforms they are the same size. (which is the assumption made in the ogg code anyway) The reason for this is i will have vorbis support on playstation 2, but long is 64 bits, and they are excruciatingly slow. cheers Brett Paterson --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg

...easons of memory usage and compatibility, "int" was fixed at 32 bits. This meant it was no longer the same size as a pointer, the size of an array index, or the widest native integer type. (Sequence of events simplified for brevity.) The C standard tries to help with a bunch of typedefs: int_fast32_t, int_least32_t, intptr_t, int32_t, size_t, ptrdiff_t, and more. With all these great typedefs, one could imagine that there's no reason anyone should ever use plain "int" ever again. Unfortunately, juggling all these typedefs can be impractical, for several reasons. C doesn't hav...

On Wed, Jul 1, 2015 at 12:22 PM, Russell Wallace <russell.wallace at gmail.com> wrote: > I am arguing in favor of a point, and I understand you disagree with it, > but I don't think I'm dismissing any use cases except a very small > performance increment. > I'm sure Google has numbers about how much electricity/server cost they save for X% performance improvement.