Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 May 1999 16:49:04 -0500
From:      "G. Adam Stanislav" <adam@whizkidtech.net>
To:        Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: wc* routines
Message-ID:  <19990504164904.A217@whizkidtech.net>
In-Reply-To: <199905041711.VAA04689@tejblum.dnttm.rssi.ru>; from Dmitrij Tejblum on Tue, May 04, 1999 at 09:11:45PM %2B0400
References:  <199905041711.VAA04689@tejblum.dnttm.rssi.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 04, 1999 at 09:11:45PM +0400, Dmitrij Tejblum wrote:
> Well, just several comments (all IMO).

Actually, you made some very good suggestions. Spasibo! :-)

> Well, not bad. Still, your headers apparently have too much namespace 
> pollution. Your <wchar.h> include <machine/varargs.h>. Apparently, to 
> get definition of va_list. First, the modern definition of va_list is 
> in <stdarg.h> (symlink to <machine/stdarg.h>, conflict with <varargs.h>), 
> second, you should not include any of them, you should use _BSD_VA_LIST_, 
> just like <stdio.h>. Likewise, you should not include <stdio.h>. Try use some 
> similar trick. In general, everything more than <sys/cdefs.h> and 
> <machine/ansi.h> is too much.

Done. Changed all occurences of "va_list" to "_BSD_VA_LIST". Removed "#include
<machine/varargs.h>".

Replaced "#include <stdio.h>" with  "struct __sFILE;". Replaced all occurences
of "FILE *" with "struct __sFILE *".

This will have a side effect: If someone uses putwchar or getwchar without
including <stdio.h> explicitly, they will get an error (since stdin and
stdout will be undefined). But I suppose that should be an error anyway.
(Should it?)

> <machine/wcdef.h> should not exist. _BSD* macros missng from 
> <machine/ansi.h> should be added there.

Yes, that was the original idea. Then I decided to use <machine/wcdef.h>
for now since I want to have something that works but that I can change
as necessary before I request the formal change to <machine/ansi.h>. I did
not mention it on the web page because I wanted to hear what others think
about it. :-) But eventually, I would like to have moved.

> WCS* macros have unknown 
> purpose and pollute the namespace, therefore they should not exist. In 
> general, headers under machine/ should be machine-depended :-).

OK, they can be easily moved to <wctype.h> or even removed, renamed, whatever.
They are not part of the standard. I thought they might be useful for
internal use of the code (but then, I can move them to the appropriate C
file). The wctype(const char*) function is to convert a character string,
such as "upper" into a return value of type wctype_t which can then be used
as an argument to iswctype(). So, for example,

	iswctype(ch, wctype("upper"));

is functionally identical with

	(wint_t) iswupper(ch);

Similarly,

	towctrans(ch, wctrans("upper");

is the functional equivalent of

	towupper(ch);

> I don't like your idea that WEOF == INT_MIN. Apparently, everyone else 
> have WEOF == -1 (== EOF), and there is no reason why we should not too.
> I don't know about "debugging purposes". WEOF == EOF should allow more 
> code sharing with existing libc. Note that FreeBSD already have some 
> very sparse and nonstandard (but functional) wchar support.

OK, noted. I have not changed this one (not saying I won't). I would like
to hear others' opinions on this one. There is at least one function (I do
not recall straight from the head which one or which ones) that must return
WEOF if EOF is passed to it. Their purpose is similar but not absolutely
identical.

The standard says WEOF need not be -1, or for that matter a negative number.
Although I fail to see how it could be positive since any positive wint_t
can later become a valid ISO-10646 wide character, and we have no way of
knowing which codes will be added in the future.

> > I started with the headers because it does not seem to make much sense to me
> > to work on the code without good headers. 
> 
> Well, but implementation is also important ;-). Unimplemented headers are 
> somewhat confusing when committed into the tree - we already have examples...

It's the chicken and the egg dilemma. I wanted to create the headers first
because I am not the only one working on the code, and we all need to use the
same headers. Besides, I need to include them in my code anyway.

> Note that a major portion of <wctype.h> already almost implemented in FreeBSD: 
> plain ctype functions work with wide characters. So it should be fairly 
> easy to write an almost working <wctype.h>. (BTW, it is somewhere on my 
> ToDo list for quite some time, but now not that far from the top).

Thanks for the tip. I'll take a look at the code.

> Good luck.

Thanks,

Adam

P.S. I have uploaded the changes to the web page. Independent of this message,
I also added some more links to the page earlier today, including the link to
the web page which contains the formal request to add Klingon alphabet to
ISO 10646 (I just couldn't resist when I discovered it :).

I think ISO 10646 will grow so big, we will eventually need to create
dedicated font servers (hmmm... there's a tought...).


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990504164904.A217>