Date: Mon, 10 Jun 2002 05:01:52 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Bruce Evans <bde@zeta.org.au> Cc: audit@FreeBSD.ORG Subject: Re: Compiling bin/ed with WARNS=6 Message-ID: <20020610020152.GA9808@hades.hell.gr> In-Reply-To: <20020610112448.G1757-100000@gamplex.bde.org> References: <20020610004914.GA10811@hades.hell.gr> <20020610112448.G1757-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-06-10 11:34 +1000, Bruce Evans wrote: > On Mon, 10 Jun 2002, Giorgos Keramidas wrote: > > There are only two small changes that need to be done to ed(1) to make > > it compile cleanly with WARNS=6 in i386/CURRENT. I have tested the > > ... > > Declare an array of bytes as `char[]' and not `unsigned char[]'. > > Er, this seems to break at least get_des_char() if the buffer contains > negative chars. E.g., the signed char that has the value EOF (if any) > would be indistinguishable from EOF. Since ed can be used to edit 8-bit texts too, we should either use `char' everywhere, or `unsigned char'. We can't use both. I have verified that changing the type to `char' doesn't break editing of encrypted files. Using a program to generate input for ed, I inserted into an ed buffer all the characters from 128-255 (some codepages, like Greek that I'm customarily using use most of the 8-bit characters for their national part of the character-set). I am not sure if the resulting code of get_des_char() is broken. I saw the part of io.c that uses get_des_char(). It seems that this works because get_des_char() returns an int. So when get_des_char() returns EOF, it is different from ((char)-1). I might be wrong though. At least, it's nice to see that my worries and checks for 8-bit characters were steps in the right path :} - Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020610020152.GA9808>