«

"Martin Marcher" <> wrote in message
news...
> Hi,
>
> I've read several questions and often the answer was
>
> 'C knows nothing about [lots of different stuff here].'
>
> So if C knows that little as some people say, what are the benefits, I
> mean do other languages know more or is it a benefit that C knows nearly
> nothing (what I can think about is that C is the largest common divisor
> defined on most available platforms)?

The command set for C is small and elegant. In the "bad old days" there were
languages that were so complex that one couldn't keep the entire language in
one's mind. Ada comes to mind as an example. It was impossible to become a
true expert. By keeping the command set to a consistant, small size allows
one to truly master the language.

As to how it can do so much with so little, well C can be expanded with
external libraries. These can be written in Assembler, C, or another
language. So, even though C has no built-in input/output functions, the
standard library STDIO.H declares several functions, like fread() and
printf(), which allow programs to do input and output. The particular
version of these routines (the implementation)will have to be non-portable,
Operating System (OS) based code. So, Microsoft writes a printf() that works
on DOS machines, and I link it into my program, and I can output "Hello,
world!" to my computer screen. When I move the program to a Linux box, I
recompile with gcc and it will build my executable with a Linux-based
printf() that still outputs "Hello, world!" to my computer screen. Same
source code, two differnt executables that can only run on their own OS.

Unfortunately, with C++, we've taken a step back into the "bigger = better"
style of language creation. However, as PDA's and phones begin to need
programming, you can bet that C will be there first. There will be a big
need to avoid platform specific programming, as new device come out
constantly and your code will have to work right, right now.

On 12 Aug 2003 18:05:33 -0600, Chris Torek <>
wrote in comp.lang.c:

[big snip]

> (Not that this stopped the X3J11 folks in all cases. For instance,
> they stole "const" from C++, and broke it. They also picked

I strongly disagree with your first statement above. They stole
"const" from C++ and FIXED it. They also didn't break "volatile", as
C++ has quite badly, albeit inadvertently. A very large percentage of
production C programming today is in the realm of embedded systems,
and the C semantics of const are ideal for read-only objects in
ROM/EPROM/Flash etc.

> the wrong rules for dealing with narrow unsigned arithmetic, where
> the Unix compilers got it right but one particular PC compiler used
> the silly "value-preserving" rules. They even tried to add an

On the other hand, your second gripe is right on. "Value preserving"
is at the top of my list of things that went wrong in 1989.

> 11th-hour unworkable version of C99's "restrict", called "noalias".
> But for whatever reason, they did not invent directory operations.)

You forgot to mention that enums are so crippled as to be almost
useless in both C and C++, and bit-fields likewise, and...

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

In article <>
Jack Klein <> writes:
>I strongly disagree with your first statement above. They stole
>"const" from C++ and FIXED it. ...
>the C semantics of const are ideal for read-only objects in
>ROM/EPROM/Flash etc.

If we want const to mean "read-only object as stored in ROM or
equivalent", const should be a storage-class, not a type-qualifier.

The part of C that is particularly broken with respect to "const"
has to do with pointers that point to "const char *", when using
const as a type-qualifier. For instance, suppose you have a
function f() that takes a pointer to "const char *" and applies
strlen to the various p[i] values:

void f(const char **p) {
... strlen(p[i]) ...
}

but never modifies p, p[i], or p[i][j].

Now we have a function much like main(), in which we have a
"char **argv", reasonably suited to pass to f():

f(argv);

but C's type rules prohibit this. (C++'s type rules allow it
if we change f() to take "const char *const *", but even then,
C's type rules prohibit it.)

If "const" were a storage-class specifier, the call would be OK
(and any "const" keywords in f()'s parameter would effectively be
a no-op, or prohibited entirely).
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

On Tue, 12 Aug 2003 19:18:56 +0200,
Martin Marcher <> wrote
in Msg. <>

>> Users are allowed to augment that functionality, but it won't be discussed
>> in this newsgroup.
>
> Problem 1: The only one that can forbid or allow me aksing questions is my
> mother

Uh-oh...

> Problem 2: If you would be so kind to point me to a group where I can ask
> that question (I didn't find a group called
> comp.lang.c.historical-background or similiar)

comp.lang.c is the perfectly correct place to ask the question why C has
or has not certain features.

> Problem 3: Please tell me the reason why asking this question is OT in
> this group,

Nobody accused you of off-topicality, because...

> If you would have had a look at the post I mention in my original post you
> would have seen that I didn't ask the question,

What several people pointed out to you is that this group isn't concerned
with platform-specific stuff, using reading information from a hard disk
as an example. Nobody accused you of barging in here asking
platform-specific stuff (as happens several times a day).

> so you don't need to tell
> me not to discuss platform specific code, I'm really new to C and did my
> best to stay standard conform, also if you search my previous posts I
> mentioned everytime I wasn't sure wether it was ANSI C or not, so people
> that strictly refer to ANSI C aren't forced to read further.

> A simple 'ask at this group' would be enough

Why do you fail to understand that YOU asked YOUR question at the CORRECT
newsgroup and NOBODY said otherwise?

> PS: in case you want to flame use my mail address because flames are
> off-topic and users are not allowed to do this in the newsgroup

And this comes from Mr "The only one that can forbid or allow me aksing
questions is my mother"?

For I minute I thought, wow, here comes a role-model thread: A newbie
comes in and asks a question, modestly and politely, and already a couple
of our highly regarded specialist regulars (to avoid the term "guru") give
him equally (and unusually) polite, verbous answers. Sadly, Mr. newbie
reads into those answers criticism, even flaming, snd heads off down the
well-trodden path into the killfiles by educating people about c.l.c
topicality.

--Daniel

--
"With me is nothing wrong! And with you?" (from r.a.m.p)

On Wed, 13 Aug 2003 11:06:32 +0000, Dan Pop wrote:

> In <> Scott McPhillips <>
> writes:
>
>>Martin Marcher wrote:
>>> especially since I never thought that access to directories could be
>>> outside of the standard, which makes the mentioned 'abstract machine'
>>> really minimal
>>
>>Then your awareness of the application domain is sharply limited.
>>Millions of machines that do not have disks or disk directories have
>>been programmed in C. For example: microwave ovens, hotel room locks,
>>cell phones, ...
>
> Bogus argument: we're not talking about freestanding implementations,
> which need not provide any of the standard library functions, anyway.
> Therefore, including directory support into the standard C library would
> not affect freestanding implementations in any way. Furthermore, it
> wouldn't affect hosted implementations with no directory support either:
> opendir (or whatever) could simply fail.

But for C to know about filesystems you would have to define functions to
access that filesystem. While this may seem a good idea now, future
advances in filesystems (or how OS'es deal with them) may make that
interface a bad choice. But if the filesystem interface is part of the
language making a change to it is hard, (as opposed to linking new
programs against the new library on old programs against the old one).

If C knows nothing about filesystems you are free to choose a library with
an interface that suits YOU and/or your selected plattform to access
filesystems. If on the other hand C pretended to know the ultimate
filesystem interface you would effectively have no choice, since alternate
ways would dwindle away into obscurity.


regards
NPV

Chris Torek <> wrote:
> In article <>
> Jack Klein <> writes:
>>I strongly disagree with your first statement above. They stole
>>"const" from C++ and FIXED it. ...
>>the C semantics of const are ideal for read-only objects in
>>ROM/EPROM/Flash etc.
>
> If we want const to mean "read-only object as stored in ROM or
> equivalent", const should be a storage-class, not a type-qualifier.
>
> The part of C that is particularly broken with respect to "const"
> has to do with pointers that point to "const char *", when using
> const as a type-qualifier. For instance, suppose you have a
> function f() that takes a pointer to "const char *" and applies
> strlen to the various p[i] values:
>
> void f(const char **p) {
> ... strlen(p[i]) ...
> }
>
> but never modifies p, p[i], or p[i][j].
>
> Now we have a function much like main(), in which we have a
> "char **argv", reasonably suited to pass to f():
>
> f(argv);
>
> but C's type rules prohibit this.

For good reason. If char ** were assignment-compatible with const char
**, then you could accidentally escape const:

const char c;
char *p;
const char **q = &p; /* This is what C doesn't allow */
*q = &c; /* this looks ok, both are const.. */
*p = '!'; /* ...oh no, we just broke const on ` c ' */

> (C++'s type rules allow it
> if we change f() to take "const char *const *", but even then,
> C's type rules prohibit it.)

I'm not sure how C++'s type rules work - does the destination have to be
const-qualified from the deepest indirection level of the type being
assigned, all the way up to the second last level?

> If "const" were a storage-class specifier, the call would be OK
> (and any "const" keywords in f()'s parameter would effectively be
> a no-op, or prohibited entirely).

That would have the very big problem of preventing the compiler from
diagnosing modifications to const objects made through pointers:

const int a;
int *p_a = &a;

a = 10; /* Diagnostic */
*p_a = 10; /* No diagnostic */

- Kevin.

In < > "Nils Petter Vaskinn" <> writes:

>On Wed, 13 Aug 2003 11:06:32 +0000, Dan Pop wrote:
>
>> In <> Scott McPhillips <>
>> writes:
>>
>>>Martin Marcher wrote:
>>>> especially since I never thought that access to directories could be
>>>> outside of the standard, which makes the mentioned 'abstract machine'
>>>> really minimal
>>>
>>>Then your awareness of the application domain is sharply limited.
>>>Millions of machines that do not have disks or disk directories have
>>>been programmed in C. For example: microwave ovens, hotel room locks,
>>>cell phones, ...
>>
>> Bogus argument: we're not talking about freestanding implementations,
>> which need not provide any of the standard library functions, anyway.
>> Therefore, including directory support into the standard C library would
>> not affect freestanding implementations in any way. Furthermore, it
>> wouldn't affect hosted implementations with no directory support either:
>> opendir (or whatever) could simply fail.
>
>But for C to know about filesystems you would have to define functions to
>access that filesystem. While this may seem a good idea now, future
>advances in filesystems (or how OS'es deal with them) may make that
>interface a bad choice.

If well designed and generic enough, this is not going to happen. See
below.

>But if the filesystem interface is part of the
>language making a change to it is hard, (as opposed to linking new
>programs against the new library on old programs against the old one).
>
>If C knows nothing about filesystems you are free to choose a library with
>an interface that suits YOU and/or your selected plattform to access
>filesystems. If on the other hand C pretended to know the ultimate
>filesystem interface you would effectively have no choice, since alternate
>ways would dwindle away into obscurity.

You're missing the point. C should provide a minimal interface to
accessing directories plus a minimal interface to the information
associated with each directory entry (a minimal <dirent.h> and a minimal
<stat.h>). Each implementation can either extend these minimal interfaces
or provide alternative solutions that provide as much information as
available on the underlying OS. The minimal and possibly suboptimal C
solution doesn't prevent better solutions that are platform specific.

E.g. the existence of <stdio.h> doesn't prevent any implementation from
providing alternate I/O interfaces, more flexible and more functional than
the standard C one.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email:

Dan Pop wrote:
>
> In < > "Nils Petter Vaskinn" <> writes:
>
> >But for C to know about filesystems you would have to define functions to
> >access that filesystem. While this may seem a good idea now, future
> >advances in filesystems (or how OS'es deal with them) may make that
> >interface a bad choice.
>
> If well designed and generic enough, this is not going to happen. [...]

The design is the hard part. The most ambitious attempt
at such an abstraction layer that I've come across is that of
Common LISP, and (personal opinion) it isn't all that useful.
Smarter people than I put some serious skull sweat into the
CL scheme and came up with something inadequate; that suggests
to me that the problem is considerably nastier than it might
appear on first examination.

> You're missing the point. C should provide a minimal interface to
> accessing directories plus a minimal interface to the information
> associated with each directory entry (a minimal <dirent.h> and a minimal
> <stat.h>). Each implementation can either extend these minimal interfaces
> or provide alternative solutions that provide as much information as
> available on the underlying OS. The minimal and possibly suboptimal C
> solution doesn't prevent better solutions that are platform specific.
>
> E.g. the existence of <stdio.h> doesn't prevent any implementation from
> providing alternate I/O interfaces, more flexible and more functional than
> the standard C one.

I'm not sure how this differs from the situation that prevails
today: C offers a "minimal" directory interface (to wit, a null
directory interface), and platforms extend it in various ways.
A less vacuous (is "less vacuous" a linguistic abomination?)
interface would presumably aspire to provide a portable means of
getting at some common subset of all the file-cataloging schemes,
but the big question would be whether that subset could be large
enough to be useful. The Common LISP experience suggests that a
portable interface might be close to impotent, and that a useful
interface might not be very portable.

--

On Tue, 12 Aug 2003 19:18:56 +0200, in comp.lang.c , Martin Marcher
<> wrote:

>On Tue, 12 Aug 2003 16:43:16 +0000, Thomas Matthews wrote:
>
>> The issue is that there is a finite set of functionality in the language.
>
>My question was more like, why it is that C knows so little (since you
>didn't answer me I allow myself to asume that C really knows very little).

ISO C is designed to be maximally portable to different hardware and
OSes. Therefore it is a subset of what any given platform can do.
Platform specific extensions are then developed to augment C's basic
functions. However they're not topical here.

>> Users are allowed to augment that functionality, but it won't be discussed
>> in this newsgroup.
>
>Problem 1: The only one that can forbid or allow me aksing questions is my
>mother

<pedantic>
Actually you can also be forbidden from asking questions by a wide
range of other people, from the police to a maniac with a pair of
pliers and a penchant for roast tongue.
</pedantic>

The point is, this group is for discussion of ISO C. If you ask
nontopical questions here, expect to get told to ask elsewhere, then
flamed, then insulted and finally plonked.

>Problem 2: If you would be so kind to point me to a group where I can ask
>that question (I didn't find a group called
>comp.lang.c.historical-background or similiar)

a group that specialises in the platform you want to use. Suchg
extensions are typically platform specific.

>Problem 3: Please tell me the reason why asking this question is OT in
>this group,

see above.


--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

On Wed, 13 Aug 2003 00:41:59 +0200, in comp.lang.c , Richard Delorme
<> wrote:

>Scott McPhillips a écrit :
>
>> Then your awareness of the application domain is sharply limited.
>> Millions of machines that do not have disks or disk directories have
>> been programmed in C. For example: microwave ovens, hotel room locks,
>> cell phones, ...
>>
>
>This is not a problem of having discs or not. C supports files through
>functions like rename(), remove(),... Then, why are directories, which are
>useful at keeping files well ordered, not part of the language?

C supplies functions to remove things called "files" but it has no
actual idea what these things are. They could include directories,
which are after all a feature from VMS, but not say PalmOS. C
therefore cleverly allows these things to exist, to allows each
platform to support them in its own way.

>Why that feature is in, and why this one is out?

Because a committee voted on whether they thought it was generically
useful or not.

>Why not adding another
>level, called "graphical environment", with graphical functions added into
>the standard libraries?

Because the vast majority of devices on which C programs might be used
do not have any "graphical device". Therefore its not generically
useful. You're thinking too narrow.

>I don't think there is any rationale here. It probably just depends on the
>people attending the commitee meetings and their particular needs.

Of course, thats called "democracy in action". If you think the
committe got it wrong, then you are as it happens completely at
liberty to join it for C200x.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---