Hi,
I've been facing the following interesting situation for years, but I only
took time to track it down now.
When building a glibc package for a distro, we perform the standard steps to
compile and install it including the locales, then do some random checks and
finally create a tar archive. So
On Tue, Jun 19, 2007 at 03:54:52PM +0200, Bodo Eggert wrote:
> Does the FLUSH DTRT by design, or does it just shrink and hide the original
> race?
I haven't deeply studied this aspect of the source, don't know what
_exactly_ this FLUSH does, but of course I have an inner feeling about this.
Kind
able
release that introduces my work, and the first two issues addressed now are
regressions since 2.6.21.
Thanks,
Signed-off-by: Egmont Koblinger <[EMAIL PROTECTED]>
diff -Naur linux-2.6.22-rc5.orig/drivers/char/vt.c
linux-2.6.22-rc5/drivers/char/vt.c
--- linux-2.6.22-rc5.orig/drivers/char/v
y to see that they are
tied together.)
4) There is a small built-in table of zero-width spaces that are not to be
printed but silently skipped. U+200A is included there, but it's not a
zero-width character, so I remove it from there.
The patch is exactly the same as I've sent to t
On Thu, Apr 12, 2007 at 10:35:24AM -0700, H. Peter Anvin wrote:
> Yes, I didn't realize at the time that that was dead code.
:-
Version 4 of the patch follows. Dead code omitted from version 3.
Signed-off-by: Egmont Koblinger <[EMAIL PROTECTED]>
diff -Naur linux-2.6.20.ori
On Thu, Apr 12, 2007 at 09:58:38AM -0700, H. Peter Anvin wrote:
> Not leaving dead code in the kernel is long-standing policy; it's
> nothing new. We constantly remove #if 0'd code that the authors have
> left in.
I see. However, you wrote it recently:
> Besides, would it not make more sense
On Thu, Apr 12, 2007 at 06:41:22PM +0200, Jan Engelhardt wrote:
> >> I've been thinking on it and I'm not sure which one the right way is. The
> >> reason for choosing this was probably that this way information that is
> >> not
> >> used by the code can be omitted by the compiler.
> >
> > Then le
On Thu, Apr 12, 2007 at 05:52:49PM +0200, Roman Zippel wrote:
> Well, it often doesn't end there, other users may report these as bugs and
> want to get them fixed, so we have to look ahead a little for possible
> problems.
They may even report that the current behavior of not knowing anything
On Thu, Apr 12, 2007 at 04:38:54PM +0200, Roman Zippel wrote:
> Considering this possible volatility I'm not certain we really need this
> in the kernel.
> The other point is that I have problems imagining, that this should be
> enough to edit random text files with a random editor without probl
On Thu, Apr 12, 2007 at 02:13:06PM +0100, Alan Cox wrote:
> You can pack them a little differently and they'll shrink a lot.
The smaller table would actually slightly grow instead of shrinking. In my
patch there are 11 intervals, each consume 2*4 bytes, that's 88 bytes. Your
variant would store e
now
I use uint8_t.
Pavel and Jan: rbtree is an excellent data structure if you have to modify
the contents run-time. Here we have a constant data structure, and static
initialization of an rbtree (with lots of pointers and other internal data)
seems to be (quite) impossible for me.
Signed-off-by
On Wed, Apr 11, 2007 at 09:00:49PM +0200, Jan Engelhardt wrote:
> >+struct interval {
> >+ int first;
> >+ int last;
> >+};
>
> CodingStyle? uint16_t instead of int?
> >+{ 0x1D173, 0x1D182 }, { 0x1D185, 0x1D18B }, { 0x1D1AA, 0x1D1AD },
> >+{ 0xE0001, 0xE0001 }, { 0xE0020, 0xE007F }, {
On Wed, Apr 11, 2007 at 11:36:40AM -0700, H. Peter Anvin wrote:
> Egmont Koblinger wrote:
> >+static int is_zero_width(long ucs)
> >+{
> >+ static const struct interval zero_width[] = {
> /* lots */
> >+ };
>
> I'm still unhappy about these large search
t the right place. Yet again the code is organized so that it is very
easy to change to jump only one character cell, should someone prefer
that behavior (which I still see no good reason to).
Signed-off-by: Egmont Koblinger <[EMAIL PROTECTED]>
diff -Naur linux-2.6.20.orig/driver
On Tue, Apr 10, 2007 at 10:30:07AM -0700, H. Peter Anvin wrote:
> Really? Why is CJK so much more fundamental than, say, Arabic?
Not more fundamental at all. It's just perhaps easier to "support" (I mean
keep track of the cursor, not to really support them of course).
I can't see any reason why
On Tue, Apr 10, 2007 at 08:43:14AM -0700, H. Peter Anvin wrote:
> I don't see the point in dealing with one particular corner case,
I wouldn't really call CJK a *corner* case, just think of how many people
use these writing systems.
Theoretically it's just one particular case, I agree. In practi
On Sat, Apr 07, 2007 at 10:59:19AM -0700, H. Peter Anvin wrote:
> As far as width handling -- in order to make all the text line up under
> all circumstances you need more than width handling. [...]
>
> is is ridiculous. It's much better to draw a line in the sand and say
> that this is beyon
On Sat, Apr 07, 2007 at 01:00:48PM +0200, Jan Engelhardt wrote:
Hi,
> Please, no dot, and no inverse color.
> Imagine someone had the following bitmap for :
No dot, I'm already convinced. To clarify the inverse thingy:
This is what the current kernel does:
1) tries to display the desired symb
On Fri, Apr 06, 2007 at 12:43:03PM -0700, H. Peter Anvin wrote:
Hi,
> I strongly disagree. First of all, you're changing the semantics of a
> 13-year-old API. The semantics of the Linux console is that by
> specifying U+FFFD SUBSTITUTION GLYPH in your unicode table, you have
> specified the
code code points.
+ * If U+FFFD is not available in the font, print an inverse question mark
instead.
+ * Display an inverted dot for valid characters that are not available in the
font.
+ * Do not print zero-width characters, pad double-width characters with an
extra
+ * space so that the cursor m
20 matches
Mail list logo
