Re: ANNOUNCE: GNU Midnight Commander 4.5.55

[Pavel Roskin <proski gnu org>]

Hi, Martin!

> > - Experimental features (disabled by default).
> >         - Charset conversion support.
> >         - Large (64-bit) file support on 32-bit systems.
>
> I got a request for enabling the conversion support in the Debian
> package of mc.
>
> Do you say it is OK to enable this feature for distributions, or
> should I rather wait until it is declared stable?

I'll give you some facts that you should consider, but I'd rather leave
the decision up to you.

Charsest conversion support includes new dialogs and new strings.  I
believe that they are not translated to many languages.  For example,
"Input / display codepage:" is only translated to 15 languages of the 30
supported.

Charsest conversion support replaces the old "Display bits" stuff, that
allows you to limit the display to the ASCII characters (32-127) or to
ISO-8859-1 (32-127,160-255).  Now libc is responsible for the conversion.
I haven't tested whether it will reliably remove the "harmful" characters
from the output when the output codepage is set to ASCII or ISO-8859-1.

What is worse is that limiting the output range is bundled with output
conversion.  If I want to view files in koi8-r with occasional "noise"
(e.g. pseudographics) in the 128-159 area on a terminal that goes crazy
because of that "noise", I may be forced to used ISO-8859-1 for output and
thus have all cyrillic symbols converted to their latin couterparts.

This may be too confusing for some users even if the right solution can be
found.  Don't forget that even Debian GNU/Linux boxes can be accessed from
outside, so it's not a matter of capabilities of Debian's xterm.

All charsest conversion setting are common for all terminals.  This is
also wrong.  The old code (Display bits) has this problem too, but it may
be more visible if many users who didn't need display bits limitation
start using charset conversion.

In short - it's won't eat your data, it will be useful for many, but
expect more confused users and more bugreports.

> Same goes for the large file support. Could it do something nasty to
> the user's files if there is a bug?

Of course it can.  Big-endian machines (SPARC, PPC) are more in danger
because even small files (below 4G) will be affected.  But I don't expect
any bugs of this kind because there are no warnings from gcc.

The real reason why the large file support is disabled by default is
because some systems (Solaris) use preprocessor directives to implement
64-bit file access.  Somewhere in the headers they enable

#define stat stat64

and for this to work correctly, the identifier "stat" should not be used
to denote anything else but the "stat" structure as defined in libc.
This is not the case for MC, which uses "stat" in vfs.h as a member name
in "struct _vfs".  Needless to say that GNU libc does it better.

On the positive side, enabling the large file support works around another
bug in MC - files on which stat() files are not shown on panels.  It
happens with large files if the large file support is disabled.

In short, the large file support should be safe and useful if it compiles
without warnings.

-- 
Regards,
Pavel Roskin