Returning int pointer ?

[Ben Bacarisse]

Because no value can be a trap representation.

Ah yes. I don't know what I was thinking.

 

[CBFalconer]

CBFalconer said:

Because on a non-ASCII machine, it won't write ASCII. It will write
the native character set. For example, on a typical IBM mainframe
using EBCDIC, if you call it thusly:

Don't be a slave to the OPs misnaming of the routine. He wants to
write a string. The routine will write whatever characters have
been placed in the string, and the char format doesn't matter.
That is one more reason the C standard doesn't specify the char
coding.

He doesn't even need the "fputc(0, fp);" line.

 

[CBFalconer]

unsigned char is, signed char not.
However signed char is guaranteed 8 bits, so in fact it can hold
ASCII codes. Plain char must be an alias for either signed char
or unsigned char. So Keith Thompson actually squeaks through.

And the chars in the basic execution set must always be positive.
This forces EBCDIC based systems to used unsigned char as the type
for char. on byte machines.

 

[Keith Thompson]

And the chars in the basic execution set must always be positive.

Quibble: they must be non-negative. The null character is in the
basic execution character set.

This forces EBCDIC based systems to used unsigned char as the type
for char. on byte machines.

Another quibble: it forces EBCDIC based systems to make plain char an
unsigned type. char and unsigned char are still distinct types, even
if they have the same range and representation.

 

[Keith Thompson]

Don't be a slave to the OPs misnaming of the routine. He wants to
write a string. The routine will write whatever characters have
been placed in the string, and the char format doesn't matter.
That is one more reason the C standard doesn't specify the char
coding.

How do you know what the OP wants writeasciiz to do? (I think it was
Malcolm McLean who introduced the function.) For all we know, he
wants it to write ASCII characters even on an EBCDIC system, and the
implementation he's shown us is incomplete. If he wants to provide
some documentation, we can discuss it; until then, there's not much
point in guessing.

He doesn't even need the "fputc(0, fp);" line.

Why not? The intent appears to be to write the characters of the
string followed by a null character; that's presumably what the 'z' at
the end of the name means. (This makes sense only if fp was opened in
binary mode.)

 

[David Thompson]

...

Is that so?

I'm not seeing a distinction between unsigned char and signed char
when it comes to trap representations.

That's 1256, by the way - do you have another reference, or a
paragraph within 1256 which says something different?

6.2.6.2p1: "For unsigned integer types other than unsigned char, ...
padding bits [are allowed]" which allows trap reps; for uchar without
padding (or sign) only 'pure binary' value bits, there is no trap rep.

and p2: "For signed integer types ... padding bits [are allowed] ...
[and max-neg can be a trap representation]".

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Phil Carmody]

..

Is that so?

I'm not seeing a distinction between unsigned char and signed char
when it comes to trap representations.

That's 1256, by the way - do you have another reference, or a
paragraph within 1256 which says something different?

6.2.6.2p1: "For unsigned integer types other than unsigned char, ...
padding bits [are allowed]" which allows trap reps; for uchar without
padding (or sign) only 'pure binary' value bits, there is no trap rep.

and p2: "For signed integer types ... padding bits [are allowed] ...
[and max-neg can be a trap representation]".

Many thanks. If it's worth reading once, it's worth reading thrice.

Phil