Hi Paul! > Le 6 oct. 2019 à 03:58, Paul Eggert <egg...@cs.ucla.edu> a écrit : > > On 10/5/19 7:41 AM, Akim Demaille wrote: > >> Maybe you want to extend the notes you added to NEWS. Including >> the bits about limits.h and stdint.h. Maybe that should also make >> its way into the doc, yet I wouldn't know where to write that. > > OK, I did that in the revised patch (first attachment).
Great, thanks! >>> +typedef int yytype_uint8; >>> #endif >> Wow! Why do we fallback to int? Is this part where unsigned int == unsigned >> short == unsigned char on a little number of architecture? > > Yes, it's for those odd platforms. Though I now see that the above was too > extreme: it should have been 'short', not 'int'. Fixed in the first attached > patch. >> The medicine seems worse than the disease to me. > > Well, let's use stronger medicine then :-). I did it in a different way in > the first attached patch, so that yytype_uint8 should be 'unsigned char' > except for the odd but valid platforms where unsigned char and/or unsigned > short do not promote to int. Ok. I'm only worried that this might happen a little too often with some compilers that we don't have on our radar. > On compilers not compatible with GCC, the revised patch includes <limits.h> > and (if available) <stdint.h> which infringes on the user namespace, but > yacc.c already infringes elsewhere for other reasons so that should be OK. I would think so too. >> Eventually, all this should move up into c.m4, and be applied to >> glr.c too. > > Done in the second attached patch. (I haven't installed either patch yet.) Great! Feel free to install this. >> And see what to do about C++ parsers. > > I was hoping our C++ expert could look into that.... :) :) :) Actually, "Eventually, all this should move up..." really did not mean "Paul, please do...", but a note for the future, and I do plan to propagate what we did to C++ once the dust has settled down. It requires some expertise to M-w, C-x b lalr1.cc <RET>, C-y :)