Re: Modules for iconv (Was: UTF-8 patterns in Lua 5.3)

[Sean Conner <sean@...>]

It was thus said that the Great Coroutines once stated:
> On Sat, Apr 19, 2014 at 1:38 PM, Sean Conner <sean@conman.org> wrote:
> 
> >   In general, I tend to use inline (imagine that!  the equivalent of
> > typesafe macros but portable!), restrict (still working out if that's a win
> > or not---at the very least it documents intent), and declaring local
> > variables in for loops, like:
> >
> >                 for (int i = 0 ; i < SOME_MAX; i++)
> >                 {
> >                         /* ... */
> >                 }
> 
> Hmm, I'd like to kindly point out that inline is a request and not a demand :>

  True.  Perhaps in time it'll be reguarded like the "register" keyword,
accepted, but totally ignored.  Besides, I declare inline functions as
"static inline ... " and make sure never to take their address.

> >         if (setsockopt(s,SOL_SOCKET,SO_REUSEADDR,&(int){1},sizeof(int)) < 0)
> >           error();
> 
> I think what you have there is a compound literal, bro: &(int){1}

  Ah, thanks.  I couldn't remember the name of the concept.

> >   I also love <stdint.h> and <stdbool.h>.  The former replaces a large block
> > of preprocessor code I used to use to get known sized integers, and the
> > later gives me booleans, true and false (okay, so booleans are a bit larger
> > than 1 bit, but hey, I can live with that).
> 
> I think we all wish booleans were 1-bit for memory concerns, but
> accessing word-sized primitives is much faster -- which is why it's
> traditionally defined as an int.

  GCC uses a byte to store a bool.  But if C had restricted taking the
address of a bool (which I doubt could be done in practice) then maybe it
could have gone with bit-packing bools.  

> I find myself doing this even if 'bool' does exist because I have to
> write code for both WIndows, sometimes Solaris, and the non-fucky
> platforms:
> 
> typedef int boolean;
> 
> #if true
> #elseif
> #    define true 1
> #endif
> 
> #if false
> #elseif
> #    define false 0
> #endif

  I tend to define those values as:

#ifndef FALSE
#  define FALSE 0
#endif

#ifndef TRUE
#  define TRUE !FALSE
#endif

  I felt it was a bit safer that way, because in C, true is anything other
than 0.

> I know it looks weird to not just use 'ifndef' but iirc on older
> compilers ifdef/ifndef aren't recognized -- maybe that's more paranoia
> on my end.

  Dude!  How old of a compiler do you use?  Even Small-C, in 1984 (that's 30
years ago now), for an 8080, *running on an 8080*, supports #ifdef and
#ifndef.  [1]

  I think that's beyond paranoia at this point.

> >   alloca() is not standard.  It's a compiler hack that is found on several
> > copilers (you can't write the function at all---it *has* to be a compiler
> > hack).
> 
> Pretty sure you can do it with assembly, but it of course wouldn't be
> portable... I don't have that code in front of me right now :(

  Hmm ... yes, I could see how it could be done in assembly.  Nasty hack
though.

> >> Going the route of luaL_Buffer would still
> >> allocate on the heap (internally using Lua's set allocator function --
> >> which looks like realloc).  I'm continually mad at Microsoft for not
> >> better supporting C99 but in the grand scheme of things I'd rather
> >> skip C99 entirely.  It doesn't add enough to be worth jumping ship.
> >
> >   Have you really looked at it?
> 
> Looks like heap allocation to me.... ?
> http://www.lua.org/source/5.2/lauxlib.c.html#luaL_prepbuffsize

  I actually meant C99, not luaL_Buffer.

  -spc

[1]	But does not seem to support "#if".  Talk about paranoia.