Most of them were harmless: gcc not being smart enough to realize that
an uninitialized variable was never used if it wasn't initialized etc.
Some of them were name clashes ("crypt()" is a standard library
function, so rename it to "myencrypt()") etc.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Waste a few minutes occasionally on cleanup, and maybe we can make this
thing look ok in a decade or two..
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
NOTE! MicroEmacs is very much a byte-based editor, and the new utf-8
support is purely an issue of terminal input and output. The file
contents themselves are in the 8-bit space. In that space, Unicode is
the same as Latin1.
The new mode is called "utf-8", and is enabled automatically by the
new emacs.rc when $LANG contains the substring "UTF-8".
I'm sure people would like to some day also edit real UTF-8 contents,
rather than just edit old 8-bit Latin1 contents in a UTF-8 terminal.
However, that's an independent (and much bigger and thornier) issue.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
After your last round of changes it compiles without warnings here (Fedora
rawhide, gcc-4.0.2), but the link complains.
mktemp(3) isn't always secure, the problem is fixed in mkstemp(3)
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This code still assumes a latin1 kind of "one byte, one character" setup.
UTF-8 input/output (even if the data is encoded in latin-1) is a separate
issue.
make sure to include <errno.h>, and allow for the fact that newer
gcc's don't allow function declarations in function scope (don't
ask me why, but there you have it..)
This is a slightly updated version of uemacs-PK (PK is Pekka
Kutvonen) which was used at Helsinki University a long time
ago. My fingers cannot be retrained.
