|
Home > Archive > Unix Programming > September 2007 > SUSv3 error in fread() example
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
SUSv3 error in fread() example
|
|
| Frank Cusack 2007-09-17, 1:25 am |
| http://www.opengroup.org/onlinepubs...ions/fread.html
shows the example
bytes_read = fread(buf, sizeof(buf), 1, fp);
which is incorrect. fread() returns the number of items read, which
in this case is 1, so fread() in this case returns either 0 or 1.
The example should be
bytes_read = fread(buf, 1, sizeof(buf), fp);
-frank
| |
| Joachim Schmitz 2007-09-18, 7:30 am |
| "Frank Cusack" <fcusack@fcusack.com> schrieb im Newsbeitrag
news:m2ir6ars0a.fsf@sucksless.local...
> http://www.opengroup.org/onlinepubs...ions/fread.html
> shows the example
>
> bytes_read = fread(buf, sizeof(buf), 1, fp);
>
> which is incorrect. fread() returns the number of items read, which
> in this case is 1, so fread() in this case returns either 0 or 1.
> The example should be
>
> bytes_read = fread(buf, 1, sizeof(buf), fp);
nitpick: assuming bytes_read is actually meant to be what it implies to be
_and_ CHAR_BIT is 8
Bye, Jojo
| |
| Frank Cusack 2007-09-18, 1:27 pm |
| On Tue, 18 Sep 2007 10:56:33 +0200 "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> wrote:
> "Frank Cusack" <fcusack@fcusack.com> schrieb im Newsbeitrag
> news:m2ir6ars0a.fsf@sucksless.local...
> nitpick: assuming bytes_read is actually meant to be what it implies to be
If you looked at the referenced page you would see that it is.
> _and_ CHAR_BIT is 8
how would a different value of CHAR_BIT change anything?
-frank
| |
| Joachim Schmitz 2007-09-18, 1:27 pm |
|
"Frank Cusack" <fcusack@fcusack.com> schrieb im Newsbeitrag
news:m2tzprvrp3.fsf@sucksless.local...
> On Tue, 18 Sep 2007 10:56:33 +0200 "Joachim Schmitz"
> <nospam.jojo@schmitz-digital.de> wrote:
The variable name is just that: a name. That's what I refered to.
[vbcol=seagreen]
> If you looked at the referenced page you would see that it is.
>
>
> how would a different value of CHAR_BIT change anything?
a byte is 8 bit (general), a char (in C) may have more bits than that.
I'd change the example to
chars_read = fread(buf, 1, sizeof(buf), fp);
But as I also said: nitpick...
Bye, Jojo
| |
| Alan Curry 2007-09-18, 7:19 pm |
| In article <fcp164$c32$1@usenet01.boi.hp.com>,
Joachim Schmitz <schmitz@hp.com> wrote:
>
>I'd change the example to
>chars_read = fread(buf, 1, sizeof(buf), fp);
>
>But as I also said: nitpick...
A byte is a char, regardless of CHAR_BIT.
--
Alan Curry
pacman@world.std.com
| |
| Frank Cusack 2007-09-18, 7:19 pm |
| On Tue, 18 Sep 2007 19:14:31 +0200 "Joachim Schmitz" <nospam.schmitz@hp.com> wrote:
> "Frank Cusack" <fcusack@fcusack.com> schrieb im Newsbeitrag
> news:m2tzprvrp3.fsf@sucksless.local...
>
> The variable name is just that: a name. That's what I refered to.
ah, ok. i thought you might have been commenting on size_t.
> a byte is 8 bit (general), a char (in C) may have more bits than that.
>
> I'd change the example to
> chars_read = fread(buf, 1, sizeof(buf), fp);
oh, i thought a byte was the same as a char (by definition). ie, if
CHAR_BIT is 9, then a byte is 9 bits on that platform.
-frank
| |
| Frank Cusack 2007-09-18, 7:19 pm |
| On Tue, 18 Sep 2007 19:14:31 +0200 "Joachim Schmitz" <nospam.schmitz@hp.com> wrote:
> But as I also said: nitpick...
well, standards docs should be nitpicked.
| |
| Geoff Clare 2007-09-19, 1:27 pm |
| Frank Cusack wrote:
>
> oh, i thought a byte was the same as a char (by definition). ie, if
> CHAR_BIT is 9, then a byte is 9 bits on that platform.
It doesn't matter anyway, since SUSv3 requires that CHAR_BIT is 8.
--
Geoff Clare <netnews@gclare.org.uk>
| |
| Joachim Schmitz 2007-09-19, 1:27 pm |
| "Frank Cusack" <fcusack@fcusack.com> schrieb im Newsbeitrag
news:m2lkb3eq1u.fsf@sucksless.local...
> On Tue, 18 Sep 2007 19:14:31 +0200 "Joachim Schmitz"
> <nospam.schmitz@hp.com> wrote:
>
> well, standards docs should be nitpicked.
True. only that the example are (usually) non-normative, so they are alowed
to be wrong and/or missleading
Bye, Jojo
| |
| Joachim Schmitz 2007-09-19, 1:27 pm |
| "Geoff Clare" <geoff@clare.See-My-Signature.invalid> schrieb im Newsbeitrag
news:3fg7s4-f86.ln1@leafnode-msgid.gclare.org.uk...
> Frank Cusack wrote:
>
>
> It doesn't matter anyway, since SUSv3 requires that CHAR_BIT is 8.
Sure? Not >= 8 line in ANSI C?
Bye, Jojo
| |
| Joachim Schmitz 2007-09-19, 1:27 pm |
|
"Alan Curry" <pacman@TheWorld.com> schrieb im Newsbeitrag
news:fcp5j0$uaq$1@pcls4.std.com...
> In article <fcp164$c32$1@usenet01.boi.hp.com>,
> Joachim Schmitz <schmitz@hp.com> wrote:
>
> A byte is a char, regardless of CHAR_BIT.
a byte is nothing defined by the C-Language/Standard. A char is.
Bye, Jojo
| |
| Rainer Weikusat 2007-09-19, 1:27 pm |
| "Joachim Schmitz" <nospam.schmitz@hp.com> writes:
> "Alan Curry" <pacman@TheWorld.com> schrieb im Newsbeitrag
> news:fcp5j0$uaq$1@pcls4.std.com...
> a byte is nothing defined by the C-Language/Standard. A char is.
3.6
byte
addressable unit of data storage large enough to hold any member of
the basic character set of the execution environment
| |
| William Ahern 2007-09-19, 1:27 pm |
| Joachim Schmitz <nospam.schmitz@hp.com> wrote:
> "Geoff Clare" <geoff@clare.See-My-Signature.invalid> schrieb im Newsbeitrag
> news:3fg7s4-f86.ln1@leafnode-msgid.gclare.org.uk...
> Sure? Not >= 8 line in ANSI C?
SUSv3, Rationale A.3 Definitions, Byte
The restriction that a byte is now exactly eight bits was a conscious
decision by the standard developers. It came about due to a combination of
factors, primarily the use of the type int8_t within the networking
functions and the alignment with the ISO/IEC 9899:1999 standard, where the
intN_t types are now defined.
According to the ISO/IEC 9899:1999 standard:
* The [u]intN_t types must be two's complement with no padding bits and
no illegal values.
* All types (apart from bit fields, which are not relevant here) must
occupy an integral number of bytes.
* If a type with width W occupies B bytes with C bits per byte ( C is
the value of {CHAR_BIT}), then it has P padding bits where P+ W= B* C.
* Therefore, for int8_t P=0, W=8. Since B>=1, C>=8, the only solution is
B=1, C=8.
The standard developers also felt that this was not an undue restriction for
the current state-of-the-art for this version of IEEE Std 1003.1, but
recognize that if industry trends continue, a wider character type may be
required in the future.
| |
| Joachim Schmitz 2007-09-19, 1:27 pm |
|
"Rainer Weikusat" <rweikusat@mssgmbh.com> schrieb im Newsbeitrag
news:87tzpqrcaw.fsf@fever.mssgmbh.com...
> "Joachim Schmitz" <nospam.schmitz@hp.com> writes:
>
> 3.6
> byte
>
> addressable unit of data storage large enough to hold any member of
> the basic character set of the execution environment
OK, I rest my case...
|
|
|
|
|