On Tue, 5 May 2009 14:03:46 +0300, "Jukka Ruohonen"
said:
> On 05.05.2009, Simon Dick wrote:
> > with them at my last job, I don't remember hearing about anyone who'd
> > managed to get anything except linux working on it though (though I'm
> > sure someone must have!)
>
> Perhaps somewhat off-to
On Wed, May 06, 2009 at 02:28:51PM +0400, Alexander Churanov wrote:
> 1) Why discuss UCS-4 at all? UTF-32 is alreay in place. SImple,
> standardized, fixed-width and stateless.
Which part of "combining characters" is stateless? Sure, you can ignore
that in some/many applications, but it still exis
On 2009-05-06 10:57:25, Daniel Eischen wrote:
>
> Back in the day when I did it, it was with gcc-2.7.x or
> gcc-2.8.x I believe. The cross build process with gnat
> was a little different. I couldn't do a normal gnat build,
> which did a bootstrap and then rebuilt the compiler again
> using the b
2009/5/6 Erik Trulsson :
> The C standard has very few requirements on wchar_t. It is up to each
> implementation to decide how wchar_t is defined.
> There is nothing which prevents the FreeBSD project from deciding
> that on FreeBSD wchar_t is always 32 bits wide, which can then be relied
> upon
On Wed, May 06, 2009 at 02:28:51PM +0400, Alexander Churanov wrote:
> Gabor, Joerg,
>
> I am currently working on UTF-8 support in syscons and highly
> interested in making FreeBSD using UTF-8 out of box.
>
> There is my $0.02:
>
> 1) Why discuss UCS-4 at all? UTF-32 is alreay in place. SImple,
Gabor, Joerg,
I am currently working on UTF-8 support in syscons and highly
interested in making FreeBSD using UTF-8 out of box.
There is my $0.02:
1) Why discuss UCS-4 at all? UTF-32 is alreay in place. SImple,
standardized, fixed-width and stateless.
2) I'm against using wchar_t internally, be
6 matches
Mail list logo
