By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,763 Members | 1,609 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,763 IT Pros & Developers. It's quick & easy.

Standard C library functions in freestanding systems

P: n/a
MThe library functions which are included to allow process
Mlaunch, forking, and termination, imply that it is both
Mpossible and desirable for a process to fork itself. This is
Ma fundamental part of the Unix thought process, but is
Mnot essential for a working OS.

There are no Standard C Library functions for process forking or
overlaying. The fork() and execve() functions are part of the C
language bindings to POSIX. They are not parts of the Standard C
Library.

MWhy should the user have access to memory mapping,
Mallocation and de-allocation routines? [...]

Similarly, mmap() is not a Standard C Library function.

MWhat I am trying to say is not that these things are right
Mor wrong, but that the implementation of the functions,
Mand thus the library, pre-supposes that the OS will work
Min the Unix manner.

The error that you are making in your argument is that it is entirely
circular. You are taking functions from the POSIX C language bindings
and arguing that they pre-suppose a Unix-like operating system. Of
course they do. POSIX is the _definition_ of a Unix-like operating
system. However, you cannot make such an argument based upon
functions from the _Standard C Library_. The Standard C Library does
not either pre-suppose or mandate a Unix-like operating system.
Indeed, freestanding implementations of the C or C++ languages do not
pre-suppose operating systems at all.

Mmy point is basically that the C library defines the API of the OS.
This
Mforces the OS to have that API, and this leaves very little leeway
for
Mthe OS designer to deviate from another UNIX clone.

That point is wrong, as explained above. The Hurd and Plan 9 are
existence proofs of its incorrectness, as are the many embedded
systems written in the C and C++ languages.

Sep 19 '07 #1
Share this Question
Share on Google+
20 Replies


P: n/a

"J de Boyne Pollard" <j.**************@tesco.netwrote in message
news:11**********************@o80g2000hse.googlegr oups.com...
The Standard C Library does
not either pre-suppose or mandate a Unix-like operating system.
Indeed, freestanding implementations of the C or C++ languages do not
pre-suppose operating systems at all.
That was exactly Matt's point, if you had been reading the rest of the
a.o.d. thread... Your response seems to be without regard to the context.

He replied to your post, correcting you, but dropped comp.lang.c and
comp.std.misc from the reply.

We were discussing the philosophical, practical issues, and limitations of
application programmers attempting to write applications for a complete
modern OS with C only versus C with the an OS specific library which might
include the standard C library, POSIX library, other OS functionality, or
functionality equivalent to those.
Rod Pemberton

Sep 19 '07 #2

P: n/a

"J de Boyne Pollard" <j.**************@tesco.netwrote in message
news:11**********************@o80g2000hse.googlegr oups.com...
MThe library functions which are included to allow process
Mlaunch, forking, and termination, imply that it is both
Mpossible and desirable for a process to fork itself. This is
Ma fundamental part of the Unix thought process, but is
Mnot essential for a working OS.

There are no Standard C Library functions for process forking or
overlaying. The fork() and execve() functions are part of the C
language bindings to POSIX. They are not parts of the Standard C
Library.
We were discussing the use of these in OS development. Nowhere did Matt say
they were part of the C library. In regards to the OP's original post,
these would be part of a OS specific library implemented as a DLL. That DLL
may include all of the standard C library, may include all of the POSIX
libraries, and may include various OS specific functionality, or it may not.
The boundaries and scope of what was or wasn't to be included in the
development of the OP's OS DLL wasn't mentioned. Those boundaries were
under discussion.
MWhy should the user have access to memory mapping,
Mallocation and de-allocation routines? [...]

Similarly, mmap() is not a Standard C Library function.
It's true that mmap isn't part of the C library, but what does your response
have to do with an OS controlling various forms of user memory access? OS
development context lost completely...
MWhat I am trying to say is not that these things are right
Mor wrong, but that the implementation of the functions,
Mand thus the library, pre-supposes that the OS will work
Min the Unix manner.

The error that you are making in your argument is that it is entirely
circular.
No, this has nothing to do with the conversation at hand. He was stating
that he didn't want POSIX or C libraries to influence the design of his OS.
He stated that using them in his OS would essentially force him to inherit
some of the concepts behind their design - most of which were due to UNIX,
such as a hierarchical filesystem and the functions or API used to access
the filesystem.
You are taking functions from the POSIX C language bindings
and arguing that they pre-suppose a Unix-like operating system. Of
course they do. POSIX is the _definition_ of a Unix-like operating
system.
No, UNIX is the _definition_ of a Unix-like operating system... POSIX is
the definition of a _portable_ Unix-like operating system.
However, you cannot make such an argument based upon
functions from the _Standard C Library_. The Standard C Library does
not either pre-suppose or mandate a Unix-like operating system.
Indeed, freestanding implementations of the C or C++ languages do not
pre-suppose operating systems at all.
He wasn't. You just restated his point from prior posts. But, he also
wants "advanced" features in his OS such as:
"file I/O, directory management, (non-automatic) memory management, system
clock, process execution, environment, and signals (C interrupts). This
functionality isn't part of the C language. It's part of the C library."
(quoting myself...)
Mmy point is basically that the C library defines the API of the OS.
This
Mforces the OS to have that API, and this leaves very little leeway
for
Mthe OS designer to deviate from another UNIX clone.

That point is wrong, as explained above. The Hurd and Plan 9 are
existence proofs of its incorrectness, as are the many embedded
systems written in the C and C++ languages.
First, I wasn't talking about embedded systems. I was talking about OSes
sufficiently advanced that applications can be written. "My assumption was
that if someone was writing an application for his OS, that his OS is
running on something powerful enough to have applications written for it,
say a PC or 1U router, and not on something far less powerful, say a Lego
Robot or a 1U digital effects processor. Anything less powerful than a PC
rarely runs more than a single master program." (quoting myself... Yes, I
know there are small devices which do. Please don't post examples.)

Second, I already brought up the issue of hiding the complexity of
implementing different OS concepts behind an existing API. "The question
is: 'Is the new paradigm sufficiently complex that it can't be easily hidden
behind the functions of the old paradigm?'" (quoting myself...) Matt has
yet to provide his thoughts here.
If you'd read the thread,...
Rod Pemberton

Sep 19 '07 #3

P: n/a
Rod Pemberton wrote:
We were discussing the philosophical,
practical issues, and limitations of
application programmers attempting to
write applications for a complete modern OS
with C only versus C with the an OS specific library
which might include the standard C library,
POSIX library, other OS functionality, or
functionality equivalent to those.
I wrote some math functions in portable freestanding C code.

http://www.mindspring.com/~pfilandr/C/fs_math/

--
pete
Sep 19 '07 #4

P: n/a
Rod Pemberton wrote:
"J de Boyne Pollard" <j.**************@tesco.netwrote in message
news:11**********************@o80g2000hse.googlegr oups.com...
>MThe library functions which are included to allow process
Mlaunch, forking, and termination, imply that it is both
Mpossible and desirable for a process to fork itself. This is
Ma fundamental part of the Unix thought process, but is
Mnot essential for a working OS.

There are no Standard C Library functions for process forking or
overlaying. The fork() and execve() functions are part of the C
language bindings to POSIX. They are not parts of the Standard C
Library.

We were discussing the use of these in OS development. Nowhere did Matt say
they were part of the C library. In regards to the OP's original post,
these would be part of a OS specific library implemented as a DLL. That DLL
may include all of the standard C library, may include all of the POSIX
libraries, and may include various OS specific functionality, or it may not.
The boundaries and scope of what was or wasn't to be included in the
development of the OP's OS DLL wasn't mentioned. Those boundaries were
under discussion.
>MWhy should the user have access to memory mapping,
Mallocation and de-allocation routines? [...]

Similarly, mmap() is not a Standard C Library function.

It's true that mmap isn't part of the C library, but what does your response
have to do with an OS controlling various forms of user memory access? OS
development context lost completely...
>MWhat I am trying to say is not that these things are right
Mor wrong, but that the implementation of the functions,
Mand thus the library, pre-supposes that the OS will work
Min the Unix manner.

The error that you are making in your argument is that it is entirely
circular.

No, this has nothing to do with the conversation at hand. He was stating
that he didn't want POSIX or C libraries to influence the design of his OS.
He stated that using them in his OS would essentially force him to inherit
some of the concepts behind their design - most of which were due to UNIX,
such as a hierarchical filesystem and the functions or API used to access
the filesystem.
>You are taking functions from the POSIX C language bindings
and arguing that they pre-suppose a Unix-like operating system. Of
course they do. POSIX is the _definition_ of a Unix-like operating
system.

No, UNIX is the _definition_ of a Unix-like operating system... POSIX is
the definition of a _portable_ Unix-like operating system.
> However, you cannot make such an argument based upon
functions from the _Standard C Library_. The Standard C Library does
not either pre-suppose or mandate a Unix-like operating system.
Indeed, freestanding implementations of the C or C++ languages do not
pre-suppose operating systems at all.

He wasn't. You just restated his point from prior posts. But, he also
wants "advanced" features in his OS such as:
"file I/O, directory management, (non-automatic) memory management, system
clock, process execution, environment, and signals (C interrupts). This
functionality isn't part of the C language. It's part of the C library."
(quoting myself...)
>Mmy point is basically that the C library defines the API of the OS.
This
Mforces the OS to have that API, and this leaves very little leeway
for
Mthe OS designer to deviate from another UNIX clone.

That point is wrong, as explained above. The Hurd and Plan 9 are
existence proofs of its incorrectness, as are the many embedded
systems written in the C and C++ languages.

First, I wasn't talking about embedded systems. I was talking about OSes
sufficiently advanced that applications can be written. "My assumption was
that if someone was writing an application for his OS, that his OS is
running on something powerful enough to have applications written for it,
say a PC or 1U router, and not on something far less powerful, say a Lego
Robot or a 1U digital effects processor. Anything less powerful than a PC
rarely runs more than a single master program." (quoting myself... Yes, I
know there are small devices which do. Please don't post examples.)

Second, I already brought up the issue of hiding the complexity of
implementing different OS concepts behind an existing API. "The question
is: 'Is the new paradigm sufficiently complex that it can't be easily hidden
behind the functions of the old paradigm?'" (quoting myself...) Matt has
yet to provide his thoughts here.
If you'd read the thread,...
Rod Pemberton
Rod,

Sorry for missing your question in your earlier post.

The idea of masking the new paradigm with an existing API works as long
as the two are functionally similar, but different in implementation.
This is similar to the object-oriented concept of keeping the class
definition the same but altering the implementation.

One place where the idea falls down is if the functionality is not to be
offered to the application programmer. For example, there is an OS in
development which has no file concept, from the application programmer's
point of view. - All data is treated as persistent, so you create an
object, and the OS does all the saving etc.

My argument for rethinking the old paradigm is that it dates from the
days of a single machine running a single program. Historically, this
lead to the idea of the BIOS functions, and then to the higher level
functions that form parts of the C library, the Unix library, et.al.
These came about to stop the application programmer having to know too
much about the hardware, and to re-invent the wheel for every
application. At this time there was no such thing as a virus, or the
internet, etc. By the time multi-tasking came along, these functions
were so ingrained into the concept of the API that a huge amount of work
was done to make the OS appear as though each application had sole use
of the machine. This was necessary so as not to break existing programs.
However, was this the right route?

Originally, there was the manager, ( the app) and the employee ( the
OS). This worked, but we now have one employee working for perhaps 50
managers. In a factory this would lead to huge inefficiencies, and such
is the case with an OS. On top of this, we now have to give the employee
the task of trying to work out which of the managers is allowed to ask
for what, and which are malicious. If we turn the paradigm on its head,
then it makes more sense. We should have one manager, and lots of
employees. This means that we have to put the kernel in control not just
of the hardware, but of the app. The app should carry out tasks on
behalf of the OS, not the other way around. This eliminates many of the
problems of resource conflicts, re-invention of the wheel, faulty code,
and viruses.

If the app is the emloyee, then they should never be allowed to tell the
manager to do something for them which affects the global system. Thus,
no library function should be provided which affects the global state of
the system. This includes file handling, device handling, or memory
handling.

Just my thoughts, for what they are worth.

Matt
Sep 20 '07 #5

P: n/a
Matt wrote:
Sorry, didn't mean to post to comp.lang.c or to comp.std.misc.

Matt
Sep 20 '07 #6

P: n/a
On Sep 20, 1:57 pm, Matt <travellingmatt2...@yahoo.co.ukwrote:
>
Just my thoughts, for what they are worth.

So, can DLL's (or even shared libraries) be tought of as important as
OOP?

Sep 20 '07 #7

P: n/a
JdeBPThe error that you are making in your argument is that it is
JdeBPentirely circular. You are taking functions from the POSIX
JdeBPC language bindings and arguing that they pre-suppose a
JdeBPUnix-like operating system. Of course they do. POSIX is
JdeBPthe _definition_ of a Unix-like operating system. However,
JdeBPyou cannot make such an argument based upon functions
JdeBPfrom the _Standard C Library_. The Standard C Library
JdeBPdoes not either pre-suppose or mandate a Unix-like
JdeBPoperating system. Indeed, freestanding implementations
JdeBPof the C or C++ languages do not pre-suppose operating
JdeBPsystems at all.

MIt was exactly my point that C, (the language, with no
Mextensions) is OS independent, whilst the C library, (or the
MPOSIX extensions, or any of the other libraries which are
Moften added to, supplied with, or confused with the actual
Mlanguage) presuppose an OS dependent interface.

And, as already explained once, that point is wrong. Once again: The
Standard C Library does not either pre-suppose or mandate a Unix-like
operating system. Freestanding implementations don't pre-suppose even
the existence of an operating system.

MHowever, my argument is that many of the basic C library
Mfunctions ALSO pre-suppose an underlying structure which
Mis structured on existing OSes, and thus tends to force the
Mnew OS writer to conform to the existing designs, rather
Mthan branching off to something totally new.

As already explained once, there are plenty of existence proofs of the
contrary.

MLooking through the C library, (not the POSIX one), and few
functions
Mspring to mind:

They shouldn't have. Taking just two of them: It's clearly false
that calloc() imposes anything at all related to the system API, let
alone impose a Unix-like operating system as you have been claiming.
And you need to read what the C Standard actually says about the
system() function. Here's a hint: It doesn't guarantee very much
functionality. It doesn't even guarantee the existence of a command
processor. The same error of thinking goes for signal(), raise(), and
most of the other functions that you listed. (Have a look at what the
C Standard actually guarantees about signals to programs. You can
start with paragraph 7.14.4.) I think that most of your error here is
based upon not knowing exactly what functionality of the Standard C
Library is actually specified in the first place by the C Standard,
what the constraints upon library implementors actually are. You
might _think_ that the system() function imposes the requirement that
a "/bin/sh" program exist capable of processing POSIX standard shell
commands. (After all, that's what the "man" page for that function
says. And it says that it "comforms to ANSI C".) But in actual fact,
the C Standard makes no such guarantee at all.

The people who worked on the C Standard expended a lot of effort to
ensure that Standard C was operating system agnostic. That the
Standard C Library can be and has been implemented on a wide range of
operating systems with widely varying paradigms, from AmigaDOS to Plan
9, as well as implemented for freestanding environments where there is
no operating system at all, is ample proof that your argument, that
the Standard C Library enforces a Unix-centric view (your own words),
is wrong.

Sep 21 '07 #8

P: n/a
JdeBPThe Standard C Library does not either pre-suppose
JdeBPor mandate a Unix-like operating system. Indeed,
JdeBPfreestanding implementations of the C or C++
JdeBPlanguages do not pre-suppose operating systems at all.

RPThat was exactly Matt's point, if you had been reading the rest of
the
RPa.o.d. thread... Your response seems to be without regard to the
context.

The irony here is that it is _you_ who has ignored the context.
Here's the context that you ignored: _Immediately below the text that
you have just quoted_ was Matt's actual point, in xyr very own words,
which is in contradiction to the above. Here it is for you again:

Mmy point is basically that the C library defines the API of the
MOS. This forces the OS to have that API, and this leaves
Mvery little leeway for the OS designer to deviate from
Manother UNIX clone.

RPHe replied to your post, correcting you, [...]

No. He replied repeating the _very same mistake_ of conflating the
Standard C Library with the C language bindings to the POSIX system
API that I had already pointed out as being the error that he was
making; and making the additional mistake of thinking that Standard C
functions such as system() impose Unix-specific paradigms, in stark
contrast to what the C Standard _actually says_ about that function.

Sep 21 '07 #9

P: n/a
J de Boyne Pollard wrote:
You
might _think_ that the system() function imposes the requirement that
a "/bin/sh" program exist capable of processing POSIX standard shell
commands. (After all, that's what the "man" page for that function
says. And it says that it "comforms to ANSI C".) But in actual fact,
the C Standard makes no such guarantee at all.
A conforming implementation of system() can be

int system(const char *p)
{
return 0;
}

Any usage of "system" provokes a warning:

"Warning: 'system' is NOT implemented\n"

The standard says about it:

If the argument is a null pointer, the system function returns nonzero
only if a command processor is available. If the argument is not a null
pointer, and the system function does return, it returns an
implementation-defined value.

The above implementation fulfills everything in the standard about
"system".

Sep 21 '07 #10

P: n/a
MThe library functions which are included to allow process
Mlaunch, forking, and termination, imply that it is both
Mpossible and desirable for a process to fork itself. This is
Ma fundamental part of the Unix thought process, but is
Mnot essential for a working OS.

JdeBPThere are no Standard C Library functions for
JdeBPprocess forking or overlaying. The fork() and execve()
JdeBPfunctions are part of the C language bindings to
JdeBPPOSIX. They are not parts of the Standard C Library.

RPWe were discussing the use of these in OS development.
RPNowhere did Matt say they were part of the C library.

Rubbish. Here are xyr very words again:

MWhat I am trying to say is not that these things are
Mright or wrong, but that the implementation of the
Mfunctions, and thus the library, pre-supposes that
Mthe OS will work in the Unix manner.
M[...]
Mmy point is basically that the C library defines the API
Mof the OS. This forces the OS to have that API, and
Mthis leaves very little leeway for the OS designer to
Mdeviate from another UNIX clone.

MWhy should the user have access to memory mapping,
Mallocation and de-allocation routines? [...]

JdeBPSimilarly, mmap() is not a Standard C Library function.

MIt's true that mmap isn't part of the C library, but what does
Myour response have to do with an OS controlling various
Mforms of user memory access? OS development context
Mlost completely...

Again, it is not I but you who is losing the context. Here's what xe
went on to say immediately after that question:

MWhat I am trying to say is not that these things are
Mright or wrong, but that the implementation of the
Mfunctions, and thus the library, pre-supposes that
Mthe OS will work in the Unix manner.

Read the question, and that paragraph, and you'll get the context that
you are losing.

RPHe stated that using them in his OS would essentially
RPforce him to inherit some of the concepts behind their
RPdesign - most of which were due to UNIX, such as a
RPhierarchical filesystem and the functions or API used
RPto access the filesystem.

And I've told you and xem three times now that that is wrong, not
least because the Standard C Library doesn't _have_ underlying
concepts such as the ones you mention.

JdeBPHowever, you cannot make such an argument based
JdeBPupon functions from the _Standard C Library_. The
JdeBPStandard C Library does not either pre-suppose or
JdeBPmandate a Unix-like operating system. Indeed, freestanding
JdeBPimplementations of the C or C++ languages do not
JdeBPpre-suppose operating systems at all.

RPHe wasn't. You just restated his point from prior posts.

You are very confused. Xe was, and I've just _refuted_ xyr point.
Here's xyr point in xyr very own words _yet again_:

Mmy point is basically that the C library defines the API
Mof the OS. This forces the OS to have that API, and
Mthis leaves very little leeway for the OS designer to
Mdeviate from another UNIX clone.

That point is wrong, as explained at length, and the aforementioned
refutes it.

Sep 21 '07 #11

P: n/a
jacob navia <ja***@jacob.remcomp.frwrites:
J de Boyne Pollard wrote:
>You
might _think_ that the system() function imposes the requirement that
a "/bin/sh" program exist capable of processing POSIX standard shell
commands. (After all, that's what the "man" page for that function
says. And it says that it "comforms to ANSI C".) But in actual fact,
the C Standard makes no such guarantee at all.

A conforming implementation of system() can be

int system(const char *p)
{
return 0;
}

Any usage of "system" provokes a warning:

"Warning: 'system' is NOT implemented\n"

The standard says about it:

If the argument is a null pointer, the system function returns nonzero
only if a command processor is available. If the argument is not a null
pointer, and the system function does return, it returns an
implementation-defined value.

The above implementation fulfills everything in the standard about
"system".
Agreed. But as far as conformance is concerned, the warning (I assume
you mean a compile-time warning) is irrelevant. An implementation can
warn about anything it likes (and if system() with a non-null argument
doesn't do anything useful, then a compile-time warning would be a
good idea) -- but no such warning is required.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 21 '07 #12

P: n/a

"J de Boyne Pollard" <j.**************@tesco.netwrote in message
news:11**********************@y42g2000hsy.googlegr oups.com...

I'm interested in discussion with Matt and a.o.d. about the OS issues, and
not in arguments with you about comprehension of or lack of context.

Also, something in your post seemed really odd to me. So, even you may find
it a bit rude, I'm going to ask anyway. What's with the "xe" for "he",
"xem" for "hem", "xyr" for "his"? You read or reread your posts prior to
reply, correct?
Here are xyr very words again:
Here's what xe
And I've told you and xem three times now
Xe was, and I've just _refuted_ xyr point.
Here's xyr point in xyr very own words _yet again_:
See, sometimes your using "xyr" for "him" and othertimes using "xyr" for
"your"... How am I supposed to determine that you've accurately ascribed my
text to me and not Matt's to me?

Just how did you manage type in "his" as "xyr"? That's really odd. Wrong
rows. Wrong fingers. Wrong sequence. It doesn't even seem to be Dvorak...

No, a custom keymap can't be it. Google has indexed a few posts like this
from you. Are you translating to French or Chinese and back again?

You seem to be using a custom newsreader which does non-standard indenting.
Has it become corrupted somehow?
Rod Pemberton

Sep 21 '07 #13

P: n/a

"J de Boyne Pollard" <j.**************@tesco.netwrote in message
news:11**********************@d55g2000hsg.googlegr oups.com...
JdeBPThe Standard C Library does not either pre-suppose
JdeBPor mandate a Unix-like operating system. Indeed,
JdeBPfreestanding implementations of the C or C++
JdeBPlanguages do not pre-suppose operating systems at all.

RPThat was exactly Matt's point, if you had been reading the rest of
the
RPa.o.d. thread... Your response seems to be without regard to the
context.

The irony here is that it is _you_ who has ignored the context.
Here's the context that you ignored: _Immediately below the text that
you have just quoted_ was Matt's actual point, in xyr very own words,
which is in contradiction to the above. Here it is for you again:

Mmy point is basically that the C library defines the API of the
MOS. This forces the OS to have that API, and this leaves
Mvery little leeway for the OS designer to deviate from
Manother UNIX clone.
It was prior context earlier in the thread. He understands that C doesn't
require the library. That's exactly how he wrote his OS. This is basic
UNIX history:

0) a PDP-7 assembler was written.
1) the UNIX kernel was written in assembly for PDP-7 prior to the B & C
language interpreters and/or compilers.
2) B, a typeless language was written in assembly as a threaded interpreter
operating on a stack machine...like FORTH.
3) B was later rewritten to emit assembly, i.e., a simple compiler.
4) the UNIX kernel was ported to PDP-11 assembly.
5) the C compiler was developed from the B compiler.
6) the UNIX kernel was ported to C from assembly on the PDP-11. A prior
effort to port the kernel to C on the PDP-11 stalled.
7) no C library had been written.
8) a few C file I/O functions were written: read, write, open, creat,
close, link.
9) the I/O functions are based upon the PDP-7 UNIX filesystem which
Ritchie,Thompson,and Canaday had developed.
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
http://cm.bell-labs.com/cm/cs/who/dmr/hist.html

Trying to avoid "inheriting" the flavor of the PDP-7 filesystem through
functions in stdio.h, and/or unistd.h and fcntl.h is what Matt wants. I
already mentioned that it's really an issue of complexity of implementing
alternate filesystem behind the old functions.

The first is a good read. You'll find gems like:

"The rule, which survives in today's C, is that values of array type are
converted, when they appear in expressions, into pointers to the first of
the objects making up the array."

It brings up the question of whether arrays are really a type since a type
needs both a declaration and a form of usage within the language. Of
course, the array lacks the later. Here Ritchie ponders the incompleteness
of arrays and lack of solutions to make arrays a complete type:

"More fundamentally, the definition of C so specifically describes the
semantics of arrays that changes or extensions treating arrays as more
primitive objects, and permitting operations on them as wholes, become hard
to fit into the existing language."
Rod Pemberton

Sep 21 '07 #14

P: n/a
It brings up the question of whether arrays are really a type since a type
needs both a declaration and a form of usage within the language.
In C, arrays are treated as pointers only in _value_ context.

For instance, arrays are completely prohibited in lvalue context and are NOT
treated as pointers in sizeof() and structure field context.

"int a[]" is only equal to "int* a" if "a" will be used in value contexts only,
like, say, function formal parameter.

In a structure, "int a[]" is _by far not the same_ as "int* a"

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma***@storagecraft.com
http://www.storagecraft.com

Sep 30 '07 #15

P: n/a
On Sep 30, 6:40 am, "Maxim S. Shatskih" <ma...@storagecraft.com>
wrote:
It brings up the question of whether arrays are really a type since a type
needs both a declaration and a form of usage within the language.

In C, arrays are treated as pointers only in _value_ context.

For instance, arrays are completely prohibited in lvalue context and are NOT
treated as pointers in sizeof() and structure field context.

"int a[]" is only equal to "int* a" if "a" will be used in value contexts only,
like, say, function formal parameter.

In a structure, "int a[]" is _by far not the same_ as "int* a"

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.comhttp://www.storagecraft.com
There's another detail. If a is an array, then &a has a different type
from &a[0] and a but the same value.

Alex

Sep 30 '07 #16

P: n/a
There's another detail. If a is an array, then &a has a different type
from &a[0] and a but the same value.
Exactly.

"&a" is not a value context for "a".

Also note - "a", "&a" and "&a[0]" will all be the same _if placed in the value
context_.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma***@storagecraft.com
http://www.storagecraft.com

Sep 30 '07 #17

P: n/a
"Maxim S. Shatskih" <ma***@storagecraft.comwrites:
>It brings up the question of whether arrays are really a type since a type
needs both a declaration and a form of usage within the language.

In C, arrays are treated as pointers only in _value_ context.
It's not entirely clear what "value context" means. The actual rules
are simple enough that it's better to describe them exactly rather
than (or in addition to) summarizing them.
For instance, arrays are completely prohibited in lvalue context and are NOT
treated as pointers in sizeof() and structure field context.

"int a[]" is only equal to "int* a" if "a" will be used in value
contexts only, like, say, function formal parameter.

In a structure, "int a[]" is _by far not the same_ as "int* a"
Not quite.

The unary "&" operator requires an lvalue as its operand, and it
can be applied to an array.

The difference between "int a[]" and 'int *a" has nothing to do with
structures; the same rules apply (mostly) to structure members as to
standalone object declarations. These two declarations:

The actual rule (C99 6.3.2.1p3) is:

Except when it is the operand of the sizeof operator or the unary
& operator, or is a string literal used to initialize an array, an
expression that has type "array of _type_" is converted to an
expression with type "pointer to _type_" that points to the
initial element of the array object and is not an lvalue. If the
array object has register storage class, the behavior is
undefined.

See also section 6 of the comp.lang.c FAQ, <http://www.c-faq.com/>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Sep 30 '07 #18

P: n/a
Maxim S. Shatskih wrote, On 30/09/07 19:35:
>There's another detail. If a is an array, then &a has a different type
from &a[0] and a but the same value.

Exactly.

"&a" is not a value context for "a".
Since & is an operator it looks like a value context for a to me.
Also note - "a", "&a" and "&a[0]" will all be the same _if placed in the value
context_.
No.

int a[10];
int *b = a; /* valid */
int *c = &a; /* contraint violation requiring a diagnostic */
int *d = &a[0]; /* valid */
--
Flash Gordon
Sep 30 '07 #19

P: n/a
>Maxim S. Shatskih wrote, On 30/09/07 19:35:
>>There's another detail. If a is an array, then &a has a different type
from &a[0] and a but the same value.

Exactly.

"&a" is not a value context for "a".
(Elsethread, some point out that the C Standard does not use the
term "value context". I do use it myself, and may even be the
source of this particular meaning of it -- I contrast "value context"
with "object context" for various operators in C. There is one
even more special case which one might call "sizeof context",
but we can ignore that for now.)

In article <mj************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:
>Since & is an operator it looks like a value context for a to me.
It is not. Similarly, in:

x = y;

we name two variables and have one operator ("=", the ordinary
assignment operator) but we have two "contexts": x is in "object
context", because -- in this case -- we want to *change* its value,
and y is in "value context", because we want to find its value.

In this view (which is compatible with Standard C, but not actually
encoded in Standard C), array objects placed in "object context"
remain array objects, while array objects placed in "value context"
become pointers to the first element of the array.

One subtle point here is that this provides a specific model for
eventual extensions (in future version of C) that set entire array
objects. For instance:

int arr[10];
arr = expr;

is currently an error, but could become an assignment that sets
all ten elements of "arr". The value of the assignment would (in
my opinion anyway) be an "array rvalue" (a la func().arraymember
where func() returns a structure that contains a member of array
type), which is the one thing that this model does not address in
the first place. :-)
>>Also note - "a", "&a" and "&a[0]" will all be the same _if placed
in the value context_.
>No.

int a[10];
int *b = a; /* valid */
int *c = &a; /* contraint violation requiring a diagnostic */
int *d = &a[0]; /* valid */
Right. I think Maxim S. Shatskih meant "(with these things being
on the RHS of an assignment statement for instance) the values are
the same provided we disregard the types", but this is a bit like
saying that a person is a building, provided we disregard the
arrangements of the atoms in the molecules involved. If you take
away the type, you must -- at least in C -- also take away the
value. Values in C depend not only on the set of ones and zeros
in them, but also on the precise *interpretation* of those ones
and zeros. The interpretation is determined by type: take away
type and you have no idea whether the 32 bits sequence (0x40, 0x70,
0, 0) "means" 1081081856, 3.75, or something else entirely.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Oct 1 '07 #20

P: n/a
On Sep 30, 1:35 pm, "Maxim S. Shatskih" <ma...@storagecraft.com>
wrote:

snip
Also note - "a", "&a" and "&a[0]" will all be the same _if placed in the value
context_.
Only for a limited meaning of same. Under the conditions in which an
expression of array type is converted to a pointer (what you choose to
call value context), it is true that all three will point to the same
byte in memory. However, the expressions a and &a[0] will be
converted to pointer to T (where T is the type of elemet in a) while
&a will be converted to pointer to array of N T (where N is the number
of elements in the array). These two pointer types are significantly
different and there is no implicit conversion between them.

Oct 3 '07 #21

This discussion thread is closed

Replies have been disabled for this discussion.