There might not BE a definition of getc since it returns
an int and the default is to return an int. I searched
in /usr/include and /usr/include/sys on one of my Unix
machines and it was not explicitly defined...
What exactly is the problem you are running into with
doing IO on 128-255 characters?
WRITING
Writing shouldn't care: the bits just go out,
except that routines that take "strings" as output
(such as printf) may chop off everything after a zero
byte. Use fwrite instead.
READING
Reading shouldn't care either, except that you need
to be careful about telling the -1 from EOF apart from
the -1 that you get when you accidently (and erroniously)
sign-extend 128-255.
If you do this:
char foo = getc(stream);
you cannot tell an EOF from char 255 since both leave
the bit pattern FF in foo. If instead you do this:
int foo = getc(stream);
Then foo is an entire integer. Say it's 16 bits.
Then the 255 char will leave the bit pattern 00FF
in foo and EOF will leave bit pattern FFFF so you
can tell them apart. If it's 32 bits the patterns
are 000000FF and FFFFFFFF etc.
SO, if you are putting the result of getc into a char,
then checking it for negative, on machines on which
a "char" is a "signed char", the 128-255 characters
will "look like" an EOF. With careful checking of
the actual bit pattern you can still tell the
differance, except for character 255 itself.
So just keep it in an int like Richard suggested.
Or, you could use fread(&mychar, 1, 1, stream)
Or, use an independant call to feof() to detect
end of file.
=====
General background:
There is a suite of subroutines defined for IO of ASCII
text characters, which run from 1 to 127 (and which
sometimes use -1 for an EOF flag) and there is a completely
different suite of subroutines that is used for BINARY data,
in which a byte can take any of the 256 possible values.
Usually the problem is either null (zero) which is used as
an end-of-string by some subroutines, or the above-127
characters you are trying to use.
Now, a data item in a computer can be treated as either
SIGNED or UNSIGNED. A SIGNED byte runs from -127 to 127
(NO! STOP! NO 1's complement vs 2's complement stuff AIEEE!)
while an UNSIGNED byte runs from 0 to 255.
Whether a "char" on your computer is SIGNED or UNSIGNED
depends on the C compiler, which basically wants to generate
the most efficient code, and the fact that your particular
machine hardware architecture may make it easier to do signed
operations or easier to do unsigned operations, so unless you
specifically say, it can choose either, which is a source of
incompatability in porting programs from one computer
architecture to another.
For ASCII which runs from 1 to 127 IT DOESN'T MATTER! whether
the data is signed or unsigned, since the "sign bit" will
never be set.
SO. You want to use the characters over 127. You should know
that there may be standardization problems, that these codes
differ between Macintoshes and Suns and Windows. The major
email programs deal with this by putting in a header that
says
Content-Type: text/plain; charset="iso-8859-1"
(I copied this from the header of your email message!)
So this specifies the 128-255 characters as the ISO
Standard 8859-1 mapping.
You could declare every byte as UNSIGNED CHAR. You could keep
your bytes in INT instead of CHAR. Instead of using the
getc suite you could use fread and fwrite.
If "bar" turns out to be SIGNED CHAR on your machine and
you cannot control this, you might have to use code like:
foo = 0xFF & bar;
which removes the sign-extend which happens if "foo" is
a data type longer than "bar".
[EMAIL PROTECTED] wrote:
Good mornig,
the problem is that i'm dealing with the extended ASCII code, 8 bits, 'cause
I need characters as à è ò ù and so on. Do you know if there is a function I
can use for I\O of which I can handle this situation? I can't find the
definition of getc, I've checked STDIO.H.
I use char c=getc(file)
Could you give me some suggestions?Obviously I can't add a massive overhead
to the message.To solve this problem I could use 7 bits Ascii but I must use
the accented chars.Maybe I could print the char to the file as int but it
would do a big overhead!!!
Thanks for your time ,best regards!
----- Original Message -----
From: "Richard Levitte - VMS Whacker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, June 28, 2004 6:00 PM
Subject: Re: OT: problems with crypto and ASCII
In message <[EMAIL PROTECTED]> on Mon, 28 Jun 2004
17:45:23 +0200, <[EMAIL PROTECTED]> said:
deck80> Hi everybody...sorry if it's not a question strictly involving
deck80> openssl but I hope someone can help me.
deck80> I'm writing a simple program that encode a file with a LFSR
deck80> and a clock controlled shift register. Basically there is a
deck80> char m, I create a char of "worms" x and I make cipher c=m^x
deck80> in output. The problem is that the output can be every kind of
deck80> 256-ASCII code so also one of the first 31. So when it reads
deck80> the encoded file it reads also the special chars.It seems it
deck80> stops when it finds the char "
deck80> ÿ
deck80>
deck80> " which is probably the end of file. So the output is usually
deck80> a little part of the input. How can I do to solve this? I've
deck80> tried to read the file char by char and also without the
deck80> control if I'm reading an EOF
deck80> while(c=getchar(ifile)/*!=EOF*/)
deck80> {...
deck80> }
deck80> but it understands the file is finished this way either.
deck80> I've tried to append 10 EOF at the end, trying to recognize it
deck80> as a different EOF sequence but it doesn't work.
deck80> I could try to use a sequence of 10 zeros before the end but
deck80> it doesn't seem to be a smart solution(as the former with the
deck80> 10 EOF;))
What is the type of c? If it's a 'char', try changing it to 'int'.
This is really a C language question :-).
-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.
--
Richard Levitte \ Tunnlandsvägen 52 \ [EMAIL PROTECTED]
[EMAIL PROTECTED] \ S-168 36 BROMMA \ T: +46-708-26 53 44
\ SWEDEN \
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
--
Charles B (Ben) Cranston
mailto: [EMAIL PROTECTED]
http://www.wam.umd.edu/~zben
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
