Nikolay Pavlov wrote:

> > 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”.

In the early days of Vim there were many small bugs related to
forgetting to type cast a string to an unsigned type.  That's when I
decided to use "char_u" mostly.  And the number of mistakes did go down,
so it was a good choice.  After that most mistakes were with multi-byte
character strings.

I can't remember accidentally applying STRLEN() to something that isn't
a string.  

Anyway, I think it's a lot of work to change and there is no real
advantage.

-- 
hundred-and-one symptoms of being an internet addict:
194. Your business cards contain your e-mail and home page address.

 /// 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.

Raspunde prin e-mail lui