2016-04-02 16:59 GMT+03:00 Bram Moolenaar <[email protected]>: > > Ken Takata wrote: > >> Normally, char_u should be used for characters encoded in 'enc', and char >> should be used for characters encoded in the current code page. >> I found that some part of the code uses char_u and char wrongly. >> Attached patch fixes this. > > Hmm, that's not really the rule. The problem with "char" is that when > getting one character out of a string it may become negative. What the > encoding is doesn't really matter. To avoid that Vim mostly uses char_u > for text. But all the C library functions work with "char", thus we end > up type casting here and there. > > So, the rule is that we mostly use "char_u" to avoid the negative > character problem, and use "char" where needed, and then (more or less) > minimize the number of type casts.
Given how often you really need to compare characters above 127 or use them as an index (i.e. how often character needs to have specific sign) compared to how often library functions and, especially, string literals that have char* type are used to reduce number of type casts the Neovim approach is really better: 1. Use char always. 2. When needed cast to uint8_t (library type is preferred over char_u). Currently Vim has lots and lots of casts hidden by macros like STRLEN which really looks ugly and also allows bugs like passing buf_T* (i.e. non-string pointer) or integers be unnoticed by compiler because compiler sees explicit cast (while it is really implicit, done by a macros). In addition to this if string literal happens to be an argument to anything which is not a macros function with embedded casts you need a cast in your code. String literal in `return` statement? Also cast. Preferring char_u over char cannot possibly be justified by “minimizing the number of type casts”. > > > -- > What is the difference between a professional and an amateur? > The ark was built by an amateur; professionals gave us the Titanic. > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ > \\\ an exciting new programming language -- http://www.Zimbu.org /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
