stream io in c

A question came up in a syntax which is a common C extension, and I wanted
to answer how to solve it in C, as I believe that the solution is less than
ten lines and one that I could step through with gdb, my untoward debugger.

%- Writing $00-$FF via Fortran
%-
%- I am in need for an important project to write out simple
%- unsigned-char values in the range $00 through $FF,
%- without any extraneous data being added:
%-
%- open: Open the file for "raw 8-bit binary output"
%- Sequential writes; nothing fancy.
%- write: Write out individual unsigned 8-bit values with no
%- extraneous data whatsoever being involved
%- (a single value results in a single value going to output
%- file)
%- close: Close the file with no extraneous data being appended.
%- Size: File size is only the number of actual values written!

I think the solution in c could be as easy as instantiating a loop from
zero to 255, putchar'ing in the body of the loop, then redirecting output
to a file. If the creation of the file comes from the source, I suspect it
would have to be in 'rb' mode.

But I don't know. I'm hoping to use 8-bit devices, so I better get a good
handle on it. Thanks and cheers,
--
Wealth - any income that is at least one hundred dollars more a year than
the income of one's wife's sister's husband. 6
H. L. Mencken

re: stream io in c

Ron Ford <ron@example.invalidwrites:
The output stream should be binary. On a system where there is no
distinction between text and binary streams you don't really need to
bother, but I would do a:

if (freopen(NULL, stdout, "wb") != NULL) {
/* OK, of we go... */
}

to be sure. Of course, if you are writing to a device/file, just open
with mode "wb".
Parse error. Can you re-phrase?

--
Ben.

re: stream io in c

On Tue, 29 Jul 2008 19:49:54 -0600, Ron Ford posted:
I've tried some variations with this.

int i;
for (i = 0; i <= UCHAR_MAX; i++) putchar (i);

When stdout is redirected to a file, I get a file of size 257 bytes. I
wanted to see if that would also be the case if I created the file from
source, but I've got type mismatches here:

#include <stdio.h>
int main(void)
{
FILE *fp;
char name[]="text58.txt";

fp=&name;
int c;

if ((fp = fopen(fp, "rb")) == NULL)
{
printf("can't open %s\n", fp);
return 1;
}
else
{
for (c = 0; c <= 255; c ++) {
putc(c, fp);
}
fclose(fp);
}
return 0;
}
// gcc -o chars mkchars1.c

This compiles but gcc warns of incompatible pointer types. As of now, it
tells me it can't open. I can't find an example in K&R where they hard-code
a filename like this, so I'm a little stuck.:-(

--
We are here and it is now. Further than that, all human knowledge is
moonshine. 3
H. L. Mencken

re: stream io in c

Ron Ford said:
Huh? fp has type FILE *, but &name has type char (*)[11]. How can it
possibly make sense to you to assign the one to the other? Serious
question. What on earth do you think this assignment means? Why did you
type it? (Answering that question might be the most important way you can
learn from this thread.)
fopen's first parameter is declared as being const char *, so why are you
passing it a FILE *?

Fixing that, we get:

if((fp = fopen(name, "rb")) != NULL) /* but see below */
Better: return EXIT_FAILURE; but you'll need <stdlib.hfor that.
Wait a minute. Didn't you just try to open that file for reading? So why
are you trying to write to it?
<coughYes, I know. But compilation does not indicate correctness. It
merely indicates that the compiler has managed, sometimes against heavy
odds, to produce an executable program. Unless the program is correct,
however, the program won't make a lot of sense.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

re: stream io in c

Ron Ford <ron@example.invalidwrites:
No need to set fp here. Just use name in the fopen call. This
assignment does no make sense anyway, since the types don't match.
Use fopen(name, "wb") here. You are opening for reading but plan to
write to this stream.
printf("can't open %s\n", name);
This is because you try to open it for reading and, presumably, the
file does not yet exist.
--
Ben.

re: stream io in c

Ron Ford <ron@example.invalidwrites:Please indent your code. Run it through "indent -kr" if necessary
(and if you have the "indent" program).
Ok, so far, so good.
What?

fp is a FILE*, something you use for things like fopen. You're
assigning the address of a character array to it. What exactly is
"fp=&name;" intended to accomplish?

Just delete that line.
And here you're trying to use fp both to hold the result of fopen and
to hold the name of the file.

A FILE* and the name of a file are two entirely different things. You
pass the name of a file to fopen, and it gives you a FILE*. (A FILE*
is a pointer to some blob of information; you don't need to know the
details, which will vary from system to system.)

You already have a variable that holds the name of the file. Use it.

... fp = fopen(name, "rb") ...
Mis-using fp again. You want name. And consider printing the error
message to stderr rather than stdout (that's not a high priority).
Add "#include <stdlib.hand change this to "return EXIT_FAILURE;".
The value 1 isn't necessarily meaningful.
You opened fp as an input file. Now you're trying to write to it.

If you wanted to write to the file, you should have used mode "wb"
rather than "rb".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: stream io in c

Ron Ford wrote:.... snip ...The system you are using affects this. Some will expand '\n' to cr
and lf, others just to lf, others to just cr, or even a line with a
length flag. Some will insist on adding an EOF marker, some wont.
If your system is ASCII you wrote a '\n' with the 11th character.
You wrote a '\0' with the first.

What you ARE guaranteed is that you get back what you wrote
(assuming proper file modes in the open argument).

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

re: stream io in c

CBFalconer <cbfalconer@yahoo.comwrites:I believe that's guaranteed only for binary file (except that they may
be padded at the end with an arbitrary number of zero bytes). There's
no such guarantee for text files.

For example, on a system that uses character 26 as an end-of-file
marker for text files, if you write character 26 in the middle of an
output file, you'll only see half the file when you try to read it.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: stream io in c

On Thu, 31 Jul 2008 01:26:25 +0000, Richard Heathfield posted:
It would seem that I was trying to shoe-horn a char* into a file*. I
believed that the & operator hands the LHS the address of the object, in
this case, the name of a file.

LHS is a pointer. Since I could not create a sensical thingamajig of type
FILE--everything I tried was a syntax error--I tried chars. There's no
guarantees on pointers like this; why would there be a prohibition?


--
We are here and it is now. Further than that, all human knowledge is
moonshine. 3
H. L. Mencken

re: stream io in c

Ron Ford wrote:[ ... ]
You mean a FILE*?

In any case the FILE type holds critical data that is needed to operate
on the associated stream, like address of buffers, status flags etc.
You simply cannot stuff a FILE* object with the address of any object
other than a FILE, and hope get anything right. This is in fact an
illustration of a general rule in C, viz., object pointers of type T*
can only hold NULL or addresses of objects of type T. An exception is
the void* which can hold NULL or values of any object pointer type.
The & operator indeed computes the address of it's operand, but in your
case the address generated is the address of the array name, not the
address of it's first element. The values would be identical, but the
type differs.
That's what the fopen function is for.
Because there are implementations were the sizes and representations of
various pointer types are different and a value of type A* need not
make any sense when interpreted as a value of type B*.

<snip>

re: stream io in c

On Wed, 30 Jul 2008 18:35:48 -0700, Keith Thompson posted:
Thanks, Keith, I seem to be doing much better:


#include <stdio.h>
int main(void)
{
FILE *fp;
char name[]="text58.txt";


int c;

if ((fp = fopen(name, "wb")) == NULL)
{
printf("can't open %s\n", fp);
return 1;
}
else
{
for (c = 0; c <= 255; c ++) {
putc(c, fp);
}
fclose(fp);
}
return 0;
}
// gcc -o chars mkchars2.c

It seems to compile and behave:

C:\MinGW\sourcegcc -o chars mkchars2.c

C:\MinGW\source>chars

C:\MinGW\source>dir
Volume in drive C has no label.
Volume Serial Number is 486B-CFF3

Directory of C:\MinGW\source

[...]
07/31/2008 02:58 AM 309 mkchars1.c
07/30/2008 06:31 PM 257 text55.txt
07/30/2008 06:56 PM 2,592 mkchars1.o
07/30/2008 06:56 PM 19,581 new.exe
07/31/2008 03:06 AM 312 mkchars2.c
07/31/2008 03:06 AM 256 text58.txt
07/31/2008 03:06 AM 17,203 chars.exe
27 File(s) 108,824 bytes
3 Dir(s) 492,433,408 bytes free

I think this shows a difference between a way to get a file with 257 bytes
(.txt) and one without an ultimate -1.

I'll tune up the minor points when I can follow through. Best regards,

--
We are here and it is now. Further than that, all human knowledge is
moonshine. 3
H. L. Mencken

re: stream io in c

Ron Ford <ron@example.invalidwrote:
That's a nice example of magical thinking. "This looks, in one trivial
detail, like that; therefore, this should work, in all essentials, like
that." No. A pointer to FILE and a pointer to array of char are quite
different, and what's much more important, a FILE and an array of char
are very different. If you want to be a programmer, you must learn to
make sure that you _know_, rather than guess.

Richard

re: stream io in c

Ron Ford wrote:

<snip>
If you are using tabs to indent your code, consider switching to spaces,
since tabs are often stripped out by Usenet software.
The 's' type specifier expects a char* argument that must point at a
string. You have supplied it a FILE* argument, a certain route to
undefined behaviour.
And one is not a portable return value. The portable values are 0,
EXIT_SUCCESS and EXIT_FAILURE.

Surely you must have noted these elementary things as they are often
mentioned in this group, besides being in it's FAQ.
Since you are writing raw byte values, you might consider changing the
misleading filename extension.

Also the maximum value of an unsigned byte in C is given by UCHAR_MAX.
It is not necessarily 256. And note that 'c' is declared as an int, not
unsigned char.
This command is not a conforming implementation of ISO C. For that you
need:

gcc -ansi -pedantic /* For conformance to C90 */
gcc -std=c99 -pedantic /* For incomplete but good conformance to C99
*/

Also add the -Wall and -W flags for extra diagnostics which are always a
help.

<snip>

re: stream io in c

On Thu, 31 Jul 2008 15:04:37 +0530, santosh posted:
//mkchars.c:



#include <stdio.h>
#include <stdlib.h>

int main(void)
{
FILE *fp;
char name[]="text62.txt";


int c;

if ((fp = fopen(name, "wb")) == NULL)
{
printf("can't open %s\n", fp);
return EXIT_FAILURE;
}
else
{
for (c = 0; c <= 255; c ++) {
putc(c, fp);
}
fclose(fp);
}
return 0;
}
// gcc -o chars -std=c99 -pedantic mkchars3.c

--
When a new source of taxation is found it never means, in practice, that
the old source is abandoned. It merely means that the politicians have two
ways of milking the taxpayer where they had one before. 8
H. L. Mencken

re: stream io in c

Ron Ford wrote:
Can you spot the mistake in this printf call?
If you had added the -Wall and -W flags to gcc, it would have warned you
of your botch-up with printf.

re: stream io in c

On 31 Jul, 02:10, Ron Ford <r...@example.invalidwrote:for (i = 0; i < UCHAR_MAX; i++) putchar (i);

<snip>

--
Nick Keighley

It's always September. But sometimes it is _more_ September.
Jim Cameron (clc)

re: stream io in c

Nick Keighley <nick_keighley_nospam@hotmail.comwrites:
I suspect a joke, but I'm not getting it. Can you labour the point
for the rest of us?

--
Ben.

re: stream io in c

Ben Bacarisse <ben.usenet@bsb.me.ukwrites:
I will hazard he meant:

,----
| for (int i = 0; i < UCHAR_MAX; i++) putchar (i);
`----

as in C99.

Although frankly I think it#s horrible layout. Hard to debug. Hard to
see the body.

,----
| for (int i = 0; i < UCHAR_MAX; i++)
| putchar (i);
`----

....

re: stream io in c

Richard<rgrdev@gmail.comwrites:
The bit I am not getting is changing test from the correct one to one
that does not do what the OP wants. If the intent was to change the
scope of i, why change the test as well?

--
Ben.

re: stream io in c

Nick Keighley wrote:.... snip ...No, the original is correct. He wants to write out the entire
range available to the char type.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

re: stream io in c

Ron Ford <ron@example.invalidwrites:Compared to the previous version you posted, you added
"#include <stdlib.h>", you changed the file name from "text58.txt" to
"text62.txt", and you changed "return 1;" to "return EXIT_FAILURE;".

Oh, and you didn't mention what changes you had made; I had to save
both versions and compare them myself.

You ignored the vast majority of santosh's excellent advice.
Specifically:

Your indentation is still non-existent.

You're still trying to print a FILE* value using "%s".

You're still using a misleading file name.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: stream io in c

On Thu, 31 Jul 2008 16:04:13 +0530, santosh posted:
I think I got it:

//mkchars.c:



#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

int main(void)
{
FILE *fp;
char name[]="chars.256";


unsigned char c;



if ((fp = fopen(name, "wb")) == NULL)
{
printf("can't open %s\n", name);
return EXIT_FAILURE;
}
else
{
for (c = 0; c <= UCHAR_MAX; c ++) {
putc(c, fp);
}
fclose(fp);
}
return 0;
}
// gcc -o chars -std=c99 -pedantic -Wall -W mkchars4.c

I created a problem for myself that I don't get. I checked that UCHAR_MAX
was indeed 255 on my machine, but the subtitution for 255 causes this
warning and the program to hang:


C:\MinGW\source>gcc -o chars -std=c99 -pedantic -Wall -W mkchars3.c
mkchars3.c: In function 'main':
mkchars3.c:26: warning: comparison is always true due to limited range of
data type

I think I get it. 255 ++ = 0 ?
--
We are here and it is now. Further than that, all human knowledge is
moonshine. 3
H. L. Mencken

re: stream io in c

On Thu, 31 Jul 2008 12:24:30 -0700, Keith Thompson posted:

I also changed the goocher line, which is the all-important commented-out
line that one pastes into the command line.I don't know that I ignored it so much as I hadn't gotten to it.
I think I got these.
The indent program is quite a package:
http://i37.tinypic.com/2wntwuw.jpg

Is anyone aware of a tutorial on how to build such things?

--
We must be willing to pay a price for freedom. 4
H. L. Mencken

re: stream io in c

Ron Ford <ron@example.invalidwrites:
Not quite...
You had an int here before and that was correct.
See below...
I'd put this in the else clause. It is a bug "waiting to happen".
Though correct at the moment (because you return when the open fails)
it will go wrong if you change that. It is safer to get into the
habit of only closing files you know you opened.
I get the same behaviour with both 255 and UCHAR_MAX. I can't see how
it could matter which you use. Did you change c's type at about that
time?

--
Ben.

re: stream io in c

On Thu, 31 Jul 2008 10:06:47 -0400, CBFalconer posted:
Nick might be sensing the rpoblem I ran into when I turned the looping
variable to type unsigned char. You want to have a data type that will
exceed that of the greatest char so as to break the loop. Before I changed
c back to an int, char.256 was 18 megs in size.

I think this version addresses all criticisms:

//mkchars.c:

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

int main(void)
{
FILE *fp;
char name[]="chars.256";
int c;

if ((fp = fopen(name, "wb")) == NULL)
{
printf("can't open %s\n", name);
return EXIT_FAILURE;
}
else
{
printf("creating %s\n", name);
for (c = 0; c <= UCHAR_MAX; c ++) {
putc(c, fp);
}
fclose(fp);
}
return 0;
}
// gcc -o chars -std=c99 -pedantic -Wall -W mkchars4.c

Thanks all for comments.
--
Unquestionably, there is progress. The average American now pays out twice
as much in taxes as he formerly got in wages. 1
H. L. Mencken

re: stream io in c

On Aug 1, 4:05 am, Ben Bacarisse <ben.use...@bsb.me.ukwrote:Not really. To really print every single unsigned char value, try
something like this:
unsigned char c = 0;
while(c++) putchar(c-1);

UCHAR_MAX might be the largest value in the implementation. <= is
meaningless...

re: stream io in c

vippstar@gmail.com writes:
Eh? That's a no-op.
I don't understand this point.

--
Ben.

re: stream io in c

On Aug 1, 4:38 am, Ben Bacarisse <ben.use...@bsb.me.ukwrote:Whoops :P.
Alright, fix:

unsigned char c = 0;
for(putchar(c++); c; putchar(c++));
You said unsigned int is fine. (or did you say int is fine? even
worse!)
Later in the code there is,
for (c = 0; c <= UCHAR_MAX; c ++) {
Whatever type 'c' is, this loop can run forever, and that was my
point.

re: stream io in c

vippstar@gmail.com writes:
<snip>I see what you mean, but that is not a practical concern in an output
loop. If UCHAR_MAX is as large the max. for any type one can give c
then the loop may as well run forever!

--
Ben.

re: stream io in c

On Thu, 31 Jul 2008 18:29:10 -0600, Ron Ford <ron@example.invalid>
wrote:
You did better when c was an int. As it stands now, this loop can
never terminate. When c is incremented to the value UCHAR_MAX, the
loop block will execute and c will be incremented again. At this
time, it will wrap to 0 and the loop will continue. Repeat ad
infinitum.
The warning should be the same whether you code the 255 or use the
macro. The value of an unsigned char can never exceed UCHAR_MAX.
Not quite. 255 will always have type int and incrementing it will
yield 256. (The macro UCHAR_MAX must also resolve to an int so it is
not the specific value but the type of the value.) However, when the
unsigned char c contains the value UCHAR_MAX, c++ will result in c
having the value 0.

--
Remove del for email

re: stream io in c

On 31 Jul, 15:06, CBFalconer <cbfalco...@yahoo.comwrote:yes. I was mistaken.

--
Nick Keighley

re: stream io in c

Ron Ford <ron@example.invalidwrites:Better.
I'd change this to:

fprintf(stderr, "can't open %s\n", name);
As others have pointed out, this loop never terminates. c is of type
unsigned char; it's *always" <= UCHAR_MAX, no matter what you do with
it.
Um, no. 255++ is an error (specifically a constraint violation).

Remember, the "++" operator (prefix or postfix) does two things: it
modifies its argument, and it yields a value (either the previous
value or the modified value depending on where you put the "++").
You can't modify 255, so 255++ doesn't make any sense.

New C programmers are often fascinated by C's ++ operator. It's such
a cool and terse way to specify that you want to increment something.
But "x++" doesn't mean "x+1"; it's more complex than that. If you
want the incremented value of x without modifying x as a side effect,
just write "x+1". (And if you replace x with a constant 255,
you *can't* modify it.)

So what you're really asking is whether 255 + 1 == 0.

As stated, no, but there's a true statement hiding in there.

*If* UCHAR_MAX is 255 (as it very commonly is), and if you have an
object of type unsigned char with the value 255, then incrementing
that object will cause it to have the value 0.

For all unsigned types, arithmetic is performed in a wraparound
manner. So UINT_MAX + 1U == 0U, and ULONG_MAX + 1UL == 0UL.
Conversely, 0U - 1U == UINT_MAX.

And in many cases you still have to worry about promoitions and other
implicit conversions. For example, consider this:

#include <stdio.h>
#include <limits.h>
int main(void)
{
unsigned char c = UCHAR_MAX;
unsigned char c1 = c + 1;
int i1 = c + 1;

printf("c1 = %d\n", (int)c1);
printf("i1 = %d\n", i1);
return 0;
}

c1 gets the value 0; i1 gets the value 256. That's because, in the
expression c + 1, the value of c is implicitly promoted to int; adding
1 to an int value of 255 doesn't overflow or wrap around, it just
yields 256.

And although the initialization of c1 to c + 1 *acts* like it's adding
1 to an unsigned char value of 255, wrapping around, and yielding 0,
what really happens is that the value of c is promoted to int, the
expression c + 1 yields the int value 256, and that value is then
*converted* to unsigned char, yielding 0. The final result is the
same, but we took a detour from unsigned char to int and back to
unsigned char.

For integers, these implicit promotions only occur (and only in some
circumstances) for types narrower than int and unsigned int.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: stream io in c

On Fri, 01 Aug 2008 10:17:36 -0700, Keith Thompson posted:
[snipped and re-ordered]
I'm gonna need a little time to go through this more carefully.
This change highlights the use of the second line of what I call the
goocher: the commented-out command lines. I would definitely expect
information like this to come from stderr.

//mkchars.c:

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

int main(void)
{
FILE *fp;
char name[]="chars.256";
int c;

if ((fp = fopen(name, "wb")) == NULL)
{
fprintf(stderr, "couldn't open %s\n", name);
return EXIT_FAILURE;
}
else
{
printf("creating %s\n", name);
for (c = 0; c <= UCHAR_MAX; c ++) {
putc(c, fp);
}
fprintf(stderr, "did open %s\n", name);
fclose(fp);
}
return 0;
}
// gcc -o chars -std=c99 -pedantic -Wall -W mkchars5.c
// chars >text55.txt 2>text56.txt

The first two commands were without the fprintf's:

C:\MinGW\sourcegcc -o chars -std=c99 -pedantic -Wall -W mkchars5.c

C:\MinGW\source>chars
creating chars.256

C:\MinGW\source>gcc -o chars -std=c99 -pedantic -Wall -W mkchars5.c

C:\MinGW\source>chars
creating chars.256
did open chars.256

C:\MinGW\source>chars >text55.txt 2>text56.txt

C:\MinGW\source>


So it is that text55 has the "creating" and text56 has the "did open" line.
I like the reassurance from stderr that there was no error.

--
Unquestionably, there is progress. The average American now pays out twice
as much in taxes as he formerly got in wages. 1
H. L. Mencken

re: stream io in c

Ron Ford wrote:

<snip>

[code indentation corrected]
Typically only error messages are sent to stderr. A normal program
message is usually sent to stdout.
BTW, I notice that you seem to have just as much problem with consistent
formatting of your code that Bill C has.

If you use an editor like Vim or Emacs it will automatically do most of
the indenting for you. Inconsistent indentation and formatting makes
your code difficult to read, when as it is, reading properly indented
code is difficult enough.

<snip>

re: stream io in c

santosh wrote:However here he is keeping track of file statuses on stderr, so I
think the file choice is quite reasonable. It doesn't disturb the
real action, and the actual output could be to stdout.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

re: stream io in c

Nick Keighley wrote:The original one is an endless loop,
the second one doesn't putchar(UCHAR_MAX).

unsigned i = 0;

do {
putchar (i);
} while (i++ != UCHAR_MAX);


--
pete

re: stream io in c

pete wrote:It isn't an endless loop.
I had read and recalled the original post
which had declared (i) as unsigned char,
and I made a mistake.

--
pete

re: stream io in c

pete wrote:
It isn't an endless loop, but it does potentially invoke undefined
behaviour if UCHAR_MAX INT_MAX.

<snip>

re: stream io in c

santosh wrote:I don't believe that is allowable. == yes.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

re: stream io in c

On Aug 4, 11:53 pm, CBFalconer <cbfalco...@yahoo.comwrote:It is. It's not allowable that UCHAR_MAX UINT_MAX.

re: stream io in c

CBFalconer <cbfalconer@yahoo.comwrites:I believe it is.

Consider CHAR_BIT==32, sizeof(int)==1, 2's-complement, no padding
bits. Then UCHAR_MAX==2**32-1, and INT_MAX==2**31-1.

It causes problems for stdio, but (a) it's not clear that's enough to
make the (hypothetical) implementation non-conforming, and (b) even if
it is, we can assume it's freestanding.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: stream io in c

Keith Thompson wrote, On 05/08/08 00:52:Note that there are a lot of *real* implementations where sizeof(int)==1
and CHAR_BIT is 16 or greater (including ones where it is 32).
All the implementations I know of are freestanding but I don't know all
implementations.
--
Flash Gordon