Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #103281 > unrolled thread

The C Library Reference Guide

Back to article view | Back to comp.lang.c

Contents

  The C Library Reference Guide MehdiAmini <atorrses@gmail.com> - 2017-02-06 13:35 +0330
    Re: The C Library Reference Guide Barry Schwarz <schwarzb@dqel.com> - 2017-02-06 03:42 -0800
    Re: The C Library Reference Guide raltbos@xs4all.nl (Richard Bos) - 2017-02-06 11:56 +0000
      Re: The C Library Reference Guide supercat@casperkitty.com - 2017-02-06 06:33 -0800
        Re: The C Library Reference Guide raltbos@xs4all.nl (Richard Bos) - 2017-02-06 15:17 +0000
        Re: The C Library Reference Guide Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-06 10:53 -0500
          Re: The C Library Reference Guide supercat@casperkitty.com - 2017-02-06 08:32 -0800
            Re: The C Library Reference Guide Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-06 11:47 -0500
            Re: The C Library Reference Guide Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-02-06 09:01 -0800
            Re: The C Library Reference Guide Barry Schwarz <schwarzb@dqel.com> - 2017-02-06 11:26 -0800
          Re: The C Library Reference Guide Robert Wessel <robertwessel2@yahoo.com> - 2017-02-06 16:26 -0600
        Re: The C Library Reference Guide Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-06 17:01 +0000
          Re: The C Library Reference Guide supercat@casperkitty.com - 2017-02-06 09:45 -0800
            Re: The C Library Reference Guide Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-06 18:03 +0000
              Re: The C Library Reference Guide supercat@casperkitty.com - 2017-02-06 10:45 -0800
              Re: The C Library Reference Guide Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 07:58 -0800
            Re: The C Library Reference Guide raltbos@xs4all.nl (Richard Bos) - 2017-02-06 20:43 +0000
              Re: The C Library Reference Guide supercat@casperkitty.com - 2017-02-06 13:22 -0800
                Re: The C Library Reference Guide raltbos@xs4all.nl (Richard Bos) - 2017-02-06 22:17 +0000
      Re: The C Library Reference Guide Noob <root@127.0.0.1> - 2017-02-06 16:15 +0100
      Re: The C Library Reference Guide luser droog <luser.droog@gmail.com> - 2017-02-06 10:34 -0800
      Re: The C Library Reference Guide Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-08 22:14 -0800
        Re: The C Library Reference Guide Keith Thompson <kst-u@mib.org> - 2017-02-09 09:32 -0800

Page 1 of 2  [1] 2  Next page →

#103281 — The C Library Reference Guide

Hi,

Is this ebook a reliable reference for C?

http://eecs.wsu.edu/~sshaikot/docs/Other/C%20Library%20Reference%20Guide.pdf

by Eric Huss

-- 
Farewell.

[toc] | [next] | [standalone]

#103289

On Mon, 6 Feb 2017 13:35:30 +0330, MehdiAmini <atorrses@gmail.com>
wrote:

>Hi,
>
>Is this ebook a reliable reference for C?
>
>http://eecs.wsu.edu/~sshaikot/docs/Other/C%20Library%20Reference%20Guide.pdf

Not really.  

1 - It is out of date and therefore says things about the language
that are no longer true, or omits things that are true,such as:
     // comments are not in the standard
     implied int is allowed
     long long is not mentioned

2 - It has numerous inaccuracies, such as:
     variable name cannot start with an underscore
     an int is 16 bits
     fewer initialization values leave some array elements
uninitialized
     using %d to print a size_t value

And that is just at the start of chapter 1.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#103290

MehdiAmini <atorrses@gmail.com> wrote:

> Is this ebook a reliable reference for C?
> 
> http://eecs.wsu.edu/~sshaikot/docs/Other/C%20Library%20Reference%20Guide.pdf

It was written in 1996, so no, it's not a reliable reference for C99 or
C11.

It's not quite reliable for C89, either:
- It assumes (1.2.7, appendix) the character set is ASCII, which is very
common but still not entirely universal, and in any case, not required
by the Standard.
- It does not (1.3.2) take freestanding implementations into account,
only hosted ones. 
- It refers (1.4.2) to typecasting. Typecasting is something that
happens to Hollywood actors. When it happens to C types, it's just
called casting. It also does not explain all the system-dependencies
that come with casting.
- It does not explain # and ## within macro definitions.

I haven't read through the explanations of the library functions, so
I'll leave it to someone else to critique those; the above should
suffice to show that no, it's not reliable.

Someone will now undoubtedly post a link to the actual Standard for you,
or even to the C89 Standard. I've forgotten where they live.

Richard

[toc] | [prev] | [next] | [standalone]

#103302

On Monday, February 6, 2017 at 5:56:37 AM UTC-6, Richard Bos wrote:
> It's not quite reliable for C89, either:
> - It assumes (1.2.7, appendix) the character set is ASCII, which is very
> common but still not entirely universal, and in any case, not required
> by the Standard.

How many C99 or C11 implementations are there in which character codes 0-127
represent anything other than ASCII?  I've used target systems which had
non-ASCII character sets, and it would be handy if there were a C syntax to
create string literals by feeding source text through a mapping table, but
I'd be genuinely surprised if there have been any full C99 or C11
implementations using EBCDIC or any other source character set.

> - It refers (1.4.2) to typecasting. Typecasting is something that
> happens to Hollywood actors. When it happens to C types, it's just
> called casting. It also does not explain all the system-dependencies
> that come with casting.

That seems overly pedantic.  Other languages may use the term "cast" for
other purposes, and using a lexicon which is "globally unique" among all
languages would seem advantageous even if, when discussing C, the shorter
term would work just as well.

It's also important to note that there are two schools of thought with
regard to casting and system-dependence:

1. The effects of casting should be determined by the target platform in
   cases where it would suggest a clear meaning.

2. The effects of casting should be reliant upon the compiler.

I tend to subscribe to the first school of thought, but some compiler
writers seem to differ.  It's important that anyone working with C
recognize the existence of both schools of thought.

[toc] | [prev] | [next] | [standalone]

#103312

supercat@casperkitty.com wrote:

> On Monday, February 6, 2017 at 5:56:37 AM UTC-6, Richard Bos wrote:
> > It's not quite reliable for C89, either:
> > - It assumes (1.2.7, appendix) the character set is ASCII, which is very
> > common but still not entirely universal, and in any case, not required
> > by the Standard.
> 
> How many C99 or C11 implementations are there in which character codes 0-127
> represent anything other than ASCII?

That is irrelevant. It's supposed to be a reference for C89, not an
introduction to C11.

> > - It refers (1.4.2) to typecasting. Typecasting is something that
> > happens to Hollywood actors. When it happens to C types, it's just
> > called casting. It also does not explain all the system-dependencies
> > that come with casting.
> 
> That seems overly pedantic.  Other languages may use the term "cast" for
> other purposes,

That is irrelevant. It's supposed to be a reference for C, not a
general discussion of programming languages.

> It's also important to note that there are two schools of thought with
> regard to casting and system-dependence:

That is irrelevant. It's supposed to be a reference for C89, not a
user's manual for a specific implementation.

> I tend to subscribe to the first school of thought, but some compiler
> writers seem to differ.  It's important that anyone working with C
> recognize the existence of both schools of thought.

And therefore, in a discussion of casting in a reference work, they
should have been at least mentioned. They were not.

It's not a reliable reference.

Richard

[toc] | [prev] | [next] | [standalone]

#103318

On 2/6/2017 9:33 AM, supercat@casperkitty.com wrote:
> On Monday, February 6, 2017 at 5:56:37 AM UTC-6, Richard Bos wrote:
>> It's not quite reliable for C89, either:
>> - It assumes (1.2.7, appendix) the character set is ASCII, which is very
>> common but still not entirely universal, and in any case, not required
>> by the Standard.
> 
> How many C99 or C11 implementations are there in which character codes 0-127
> represent anything other than ASCII?  I've used target systems which had
> non-ASCII character sets, and it would be handy if there were a C syntax to
> create string literals by feeding source text through a mapping table, but
> I'd be genuinely surprised if there have been any full C99 or C11
> implementations using EBCDIC or any other source character set.
>

Every one which runs on IBM-compatible mainframes uses EBCDIC.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#103327

On Monday, February 6, 2017 at 9:53:09 AM UTC-6, Jerry Stuckle wrote:
> > How many C99 or C11 implementations are there in which character codes 0-127
> > represent anything other than ASCII?  I've used target systems which had
> > non-ASCII character sets, and it would be handy if there were a C syntax to
> > create string literals by feeding source text through a mapping table, but
> > I'd be genuinely surprised if there have been any full C99 or C11
> > implementations using EBCDIC or any other source character set.
> >
> 
> Every one which runs on IBM-compatible mainframes uses EBCDIC.

Does IBM continue to treat EBCDIC as its preferred character set in new
designs?  When I did some programming on the RS/6000 in 1991, that was
ASCII, and I would think that any system that's going to be connected to
the Internet would benefit greatly from using ASCII as its primary
character set.

Further, it would seem that if the language is going to support character
sets other than ASCII,  the way to do that would be to have a syntax to
define character-translation tables for use with string literals and
designate which one should be used either with individual literals or as
a default.  That would make it possible to write code which expressed both
ASCII and EBCDIC literals in human-readable form [e.g. if no implementations
presently use \[ for anything:

    FILE *f1 = fopen("/dev/deviceThatUsesASCII", "wb");
    FILE *f2 = fopen("/dev/deviceThatUsesEBCDIC", "wb");
    fprintf(f1, "%s", "\[ASCII]Hello");  // Send 0x48 0x65 0x6C 0x6C 0x6F
    fprintf(f2, "%s", "\[EBCDIC]Hello"); // Send 0xC8 0x85 0x93 0x93 0x06

Something like printf would likely be a bother (any code which changed
the default character set would have to ensure a suitable printf function
was used) but there are some situations where a string literal should
represent a sequence of ASCII values *regardless of the source character
set*, some where it should represent the source character set, and probably
some where it should represent EBCDIC.

[toc] | [prev] | [next] | [standalone]

#103330

On 2/6/2017 11:32 AM, supercat@casperkitty.com wrote:
> On Monday, February 6, 2017 at 9:53:09 AM UTC-6, Jerry Stuckle wrote:
>>> How many C99 or C11 implementations are there in which character codes 0-127
>>> represent anything other than ASCII?  I've used target systems which had
>>> non-ASCII character sets, and it would be handy if there were a C syntax to
>>> create string literals by feeding source text through a mapping table, but
>>> I'd be genuinely surprised if there have been any full C99 or C11
>>> implementations using EBCDIC or any other source character set.
>>>
>>
>> Every one which runs on IBM-compatible mainframes uses EBCDIC.
> 
> Does IBM continue to treat EBCDIC as its preferred character set in new
> designs?  When I did some programming on the RS/6000 in 1991, that was
> ASCII, and I would think that any system that's going to be connected to
> the Internet would benefit greatly from using ASCII as its primary
> character set.
>

RS/6000 was not a mainframe.  It was a minicomputer.  And yes,
mainframes still use EBCDIC.

> Further, it would seem that if the language is going to support character
> sets other than ASCII,  the way to do that would be to have a syntax to
> define character-translation tables for use with string literals and
> designate which one should be used either with individual literals or as
> a default.  That would make it possible to write code which expressed both
> ASCII and EBCDIC literals in human-readable form [e.g. if no implementations
> presently use \[ for anything:
> 
>     FILE *f1 = fopen("/dev/deviceThatUsesASCII", "wb");
>     FILE *f2 = fopen("/dev/deviceThatUsesEBCDIC", "wb");
>     fprintf(f1, "%s", "\[ASCII]Hello");  // Send 0x48 0x65 0x6C 0x6C 0x6F
>     fprintf(f2, "%s", "\[EBCDIC]Hello"); // Send 0xC8 0x85 0x93 0x93 0x06
> 
> Something like printf would likely be a bother (any code which changed
> the default character set would have to ensure a suitable printf function
> was used) but there are some situations where a string literal should
> represent a sequence of ASCII values *regardless of the source character
> set*, some where it should represent the source character set, and probably
> some where it should represent EBCDIC.
> 

Whatever.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#103331

On Monday, February 6, 2017 at 4:32:53 PM UTC, supe...@casperkitty.com wrote:
> 
> Does IBM continue to treat EBCDIC as its preferred character set in new
> designs?  When I did some programming on the RS/6000 in 1991, that was
> ASCII, and I would think that any system that's going to be connected to
> the Internet would benefit greatly from using ASCII as its primary
> character set.
> 
In the olden days, you could talk about an "ASCII machine". The screen was character-
mapped and the Basic was hardwired into the ROM. So strings were clearly ASCII.

But nowadays we really need to talk about "ASCII string" or "ASCII files / filesystems".
it's not longer really a characteristic of the machine. If the mainframe is connected
to an EBCDIC terminal that occasionally accepts a few kilobytes of information, that 
doesn't make it an "EBCDIC machine". 

[toc] | [prev] | [next] | [standalone]

#103338

On Mon, 6 Feb 2017 08:32:45 -0800 (PST), supercat@casperkitty.com
wrote:

>Does IBM continue to treat EBCDIC as its preferred character set in new
>designs?  When I did some programming on the RS/6000 in 1991, that was
>ASCII, and I would think that any system that's going to be connected to
>the Internet would benefit greatly from using ASCII as its primary
>character set.

The RS/6000 was a Unix machine.  All the IBM systems that operate
under the MVS family of operating systems (OS/360, OS/370, OS/390,
z/OS, etc) use EBCDIC as their primary character set.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#103342

On Mon, 6 Feb 2017 10:53:03 -0500, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

>On 2/6/2017 9:33 AM, supercat@casperkitty.com wrote:
>> On Monday, February 6, 2017 at 5:56:37 AM UTC-6, Richard Bos wrote:
>>> It's not quite reliable for C89, either:
>>> - It assumes (1.2.7, appendix) the character set is ASCII, which is very
>>> common but still not entirely universal, and in any case, not required
>>> by the Standard.
>> 
>> How many C99 or C11 implementations are there in which character codes 0-127
>> represent anything other than ASCII?  I've used target systems which had
>> non-ASCII character sets, and it would be handy if there were a C syntax to
>> create string literals by feeding source text through a mapping table, but
>> I'd be genuinely surprised if there have been any full C99 or C11
>> implementations using EBCDIC or any other source character set.
>>
>
>Every one which runs on IBM-compatible mainframes uses EBCDIC.


Not the one that run on zLinux, which use ASCII.  Certainly the ones
intended to run under z/OS or z/VSE do use EBCDIC (baring the
existence of any cross compilers), but that's the OS, not the machine.

I'm pretty sure UTS and AIX for S/370 machines were ASCII, but I can't
swear to it. The short-lived OpenSolaris for Z was ASCII.

[toc] | [prev] | [next] | [standalone]

#103332

supercat@casperkitty.com writes:

> On Monday, February 6, 2017 at 5:56:37 AM UTC-6, Richard Bos wrote:
>> It's not quite reliable for C89, either:
>> - It assumes (1.2.7, appendix) the character set is ASCII, which is very
>> common but still not entirely universal, and in any case, not required
>> by the Standard.
>
> How many C99 or C11 implementations are there in which character codes 0-127
> represent anything other than ASCII?

They are rare but they exist (or maybe have existed).  See the Unisys C
implementations whose documentation has been linked to more than once.

More to the point, what is being gained by being overly specific?  In
another place is says that short may be the same size as int or or may
use half the bits.  You get a better understanding of the menagerie of
basic types in C is you learn the relationships between them rather than
the likely sizes.

<snip>
>> - It refers (1.4.2) to typecasting. Typecasting is something that
>> happens to Hollywood actors. When it happens to C types, it's just
>> called casting. It also does not explain all the system-dependencies
>> that come with casting.
>
> That seems overly pedantic.

Maybe.  There are some real confusions in the text so maybe this detail
is not a big deal, but it has always struck me as odd.  What is the
strange appeal of talking about typecasting rather than conversions
using a cast, or even just casting?  What makes it so odd is that when
someone is typecast they are given a role for which their appearance (or
some other attribute) suits them.  A typecast actor must do less
"conversion" than normal to fit the role.  A cast (when properly used)
often performs a conversion from a value that can't "naturally" play
that role.  It's the exact opposite of the the right term.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#103333

On Monday, February 6, 2017 at 11:01:48 AM UTC-6, Ben Bacarisse wrote:
> supercat writes:
> > How many C99 or C11 implementations are there in which character codes 0-127
> > represent anything other than ASCII?
> 
> They are rare but they exist (or maybe have existed).  See the Unisys C
> implementations whose documentation has been linked to more than once.

The Unisys implementation whose documentation you linked to supported a
signed long long, but did not support an unsigned long long.  While I would
think there would be value in recognizing a class of implementations whose
longest type is shorter than 64 bits, I don't think the C99 or C11 Standards
do so.  Consequently, an implementation which lacks an unsigned long long
type is neither C99 nor C11 compliant.

> More to the point, what is being gained by being overly specific?  In
> another place is says that short may be the same size as int or or may
> use half the bits.  You get a better understanding of the menagerie of
> basic types in C is you learn the relationships between them rather than
> the likely sizes.

The vast majority of programmers will never have any need to program on
a system in which char is not 8 bits, and which does not allow groups of
two or four bytes to be treated as longer values.  Some embedded compilers
only go up to 32-bit types (not sure about the popular Arduino) so a
significant number of programmers will have to deal with platforms which
lack 64-bit integers.

Someone who is trying to get maximal performance out of a small micro
will benefit from understanding that every implementation they are likely
to use will store 32-bit values one of two ways: as four bytes in LSB-first
order, or four bytes MSB-first order.  While it's true that the Standard
would allow a system where CHAR_BITS==8 to use roughly 2.63E35 other ways
of arranging the bits of a uint32_t, how many systems have done so within
the last 30 years?

Nowadays such a person would also need to be informed that exploiting the
ways in which values are stored may require using a "-fno-strict-aliasing"
flag with compilers that are "sophisticated" enough to recognize that
a function like:

    void set_lower_half_of_uint32(uint32_t *p, uint16_t value)
    {
      ((uint16_t*)p)[IS_BIG_ENDIAN] = 0;
    }

can't possibly affect a value of type uint32_t even though it accepts a
pointer of type uint32_t* and that memory addressed by that pointer is
quite conspicuously written.

> Maybe.  There are some real confusions in the text so maybe this detail
> is not a big deal, but it has always struck me as odd.  What is the
> strange appeal of talking about typecasting rather than conversions
> using a cast, or even just casting?  What makes it so odd is that when
> someone is typecast they are given a role for which their appearance (or
> some other attribute) suits them.  A typecast actor must do less
> "conversion" than normal to fit the role.  A cast (when properly used)
> often performs a conversion from a value that can't "naturally" play
> that role.  It's the exact opposite of the the right term.

In the vast majority of implementations, the only casts which change
representation are those involving floating-point types, or those which
convert integers to larger types; the latter will zero-pad if the source
was unsigned, or sign-extend if signed.

[toc] | [prev] | [next] | [standalone]

#103334

supercat@casperkitty.com writes:

> On Monday, February 6, 2017 at 11:01:48 AM UTC-6, Ben Bacarisse wrote:
>> supercat writes:
>> > How many C99 or C11 implementations are there in which character codes 0-127
>> > represent anything other than ASCII?
>> 
>> They are rare but they exist (or maybe have existed).  See the Unisys C
>> implementations whose documentation has been linked to more than once.
>
> The Unisys implementation whose documentation you linked to

I didn't link to one this time and I've linked to more than one in the past.

<snip> (But you cut the text this is reply to: "this" refers to "typecast")

>> Maybe.  There are some real confusions in the text so maybe this detail
>> is not a big deal, but it has always struck me as odd.  What is the
>> strange appeal of talking about typecasting rather than conversions
>> using a cast, or even just casting?  What makes it so odd is that when
>> someone is typecast they are given a role for which their appearance (or
>> some other attribute) suits them.  A typecast actor must do less
>> "conversion" than normal to fit the role.  A cast (when properly used)
>> often performs a conversion from a value that can't "naturally" play
>> that role.  It's the exact opposite of the the right term.
>
> In the vast majority of implementations, the only casts which change
> representation

That's an unhelpful use of words.  Casts convert values.

> are those involving floating-point types, or those which
> convert integers to larger types; the latter will zero-pad if the source
> was unsigned, or sign-extend if signed.

What is the representation of (_Bool)7?  How is it the same as the
representation of 7?  How does talking about representations do anything
by muddy the waters?

Finally, are you addressing the issue of using the word "typecast"?  I'm
rarely sure what your actual point it.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#103337

On Monday, February 6, 2017 at 12:03:43 PM UTC-6, Ben Bacarisse wrote:
> What is the representation of (_Bool)7?  How is it the same as the
> representation of 7?  How does talking about representations do anything
> by muddy the waters?

I'd forgotten about _Bool since I never use it.  So far as I can tell, it
is equivalent to an integer type which, as a bit of syntactic sugar, acts
as though a ! operator was applied twice to any value which is stored to it.

In a low-level language, it is useful for implementations to define the
effects of various operations in terms of the underlying machine.  While
implementations are not required to treat C as a low-level language, there
are some fields like embedded and systems programming where such treatment
is often useful and sometimes essential.  I don't doubt that there are
some programming fields which don't benefit from such treatment, though I
must confess some puzzlement as to why C would be better than FORTRAN
or some other modern language in fields that don't require bit-level
control.

Whether or not a machine-level understanding is helpful depends upon
whether one is using C because it's the closest thing available to a
vendor-independent assembly language, or whether one is planning to use
it in some field that would treat it as a higher-level language whose
syntax is suggestive of its low-level roots, but which no longer supports
many of the operations its syntax would imply.

[toc] | [prev] | [next] | [standalone]

#103524

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> supercat@casperkitty.com writes:
>
>> On Monday, February 6, 2017 at 11:01:48 AM UTC-6, Ben Bacarisse wrote:
>>> supercat writes:
[...]
>>> Maybe.  There are some real confusions in the text so maybe this detail
>>> is not a big deal, but it has always struck me as odd.  What is the
>>> strange appeal of talking about typecasting rather than conversions
>>> using a cast, or even just casting?  What makes it so odd is that when
>>> someone is typecast they are given a role for which their appearance (or
>>> some other attribute) suits them.  A typecast actor must do less
>>> "conversion" than normal to fit the role.  A cast (when properly used)
>>> often performs a conversion from a value that can't "naturally" play
>>> that role.  It's the exact opposite of the the right term.
>>
>> In the vast majority of implementations, the only casts which change
>> representation
>
> That's an unhelpful use of words.  Casts convert values.

Please excuse a quibble.  It's true that casts (and conversions)
convert values, but there is more involved.  The expressions '0'
and '(unsigned) 0' have the same value (and most likely the same
representation at the bit level), but they behave differently.

To be fair, I should add that you may have meant 'value' in the
sense of "value in a particular abstract value space", which is
pretty much the same as my comment above.

[toc] | [prev] | [next] | [standalone]

#103339

supercat@casperkitty.com wrote:

> The vast majority of programmers will never have any need

> In the vast majority of implementations,

If you want Java, you know where to find it.

The original question was about a reference for _C_, not for "the kind
of C which supercat commonly encounters, and believes is the only one
originally meant to exist by the Sacred Forefathers".

Richard

[toc] | [prev] | [next] | [standalone]

#103340

On Monday, February 6, 2017 at 2:43:10 PM UTC-6, Richard Bos wrote:
> If you want Java, you know where to find it.
> 
> The original question was about a reference for _C_, not for "the kind
> of C which supercat commonly encounters, and believes is the only one
> originally meant to exist by the Sacred Forefathers".

Someone who is writing code for a platform whose smallest addressable unit
of storage is larger than 8 bits should expect that either "char" will be
larger than 8 bits, a char* may be larger than an int*, or both.  Adding
extra complexity to a piece of code to accommodate such possibilities,
however, will be a waste of effort unless somebody ends up wanting to run
the code on such an unusual system.

I would suggest that C was best viewed as a mapping between hardware
platforms and languages.  Given a hardware reference manual for a processor,
one could pretty well guess how C compilers for that processor would handle
various constructs even in places where the Standard imposed no requirements.
The benefit of allowing for platforms where CHAR_BIT != 8, sizeof (char*) !=
sizeof (int*), etc. was that programmers wouldn't have to learn a whole new
language to use such platforms--they'd merely have to know the ways in which
the platform differed from more common ones and code around those.

I've seen no evidence that the authors of the Standard intended that
programmers should avoid using any features that might not be available on
obscure systems where the programs wouldn't be expected to run anyhow.  They
didn't want to brand unusual systems as obsolescent, but I don't think they
intended to suggest that any program that doesn't support every allowable
architectural quirk should be considered "non-portable" and nobody should
expect it to work on any platform other than the exact compiler version for
which it was targeted.

[toc] | [prev] | [next] | [standalone]

#103341

supercat@casperkitty.com wrote:

> On Monday, February 6, 2017 at 2:43:10 PM UTC-6, Richard Bos wrote:
> > If you want Java, you know where to find it.
> > 
> > The original question was about a reference for _C_, not for "the kind
> > of C which supercat commonly encounters, and believes is the only one
> > originally meant to exist by the Sacred Forefathers".
> 
> Someone who is writing code for a platform whose smallest addressable unit
> of storage is larger than 8 bits should expect that either "char" will be
> larger than 8 bits, a char* may be larger than an int*, or both. 

Again, _not relevant_ to the document in question.

It's not an exercise book. It's a _reference_. And it's an unreliable
one.

Richard

[toc] | [prev] | [next] | [standalone]

#103310

On 06/02/2017 12:56, Richard Bos wrote:

> Someone will now undoubtedly post a link to the actual Standard for you,
> or even to the C89 Standard. I've forgotten where they live.

Here are some nice HTML references for C11, C99, and C89:

http://port70.net/~nsz/c/c11/n1570.html
http://port70.net/~nsz/c/c99/n1256.html
http://port70.net/~nsz/c/c89/c89-draft.html

Regards.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web