Paul Edwards pisze:
Hi.you mean there is no such a compiler? rise a fund for some to
I have been after a public domain C compiler for decades.
None of them reach C90 compliance. SubC comes the
closest but was written without full use of C90, which
makes it difficult to read. I'm after C90 written in C90.
A number of people have tried, but they always seem
to fall short. One of those attempts is pdcc. The
preprocessor was done, but the attempt (by someone
else) to add C code generation was abandoned.
I decided to take a look at it, and it looks to me like
a significant amount of work has already been done.
Also, my scope is limited - I am only after enough
functionality to get my 80386 OS (PDOS) compiled,
and I don't mind short=int=long = 32 bits, I don't
mind not having float. I don't use bitfields.
Anyway, I have had some success in making enhancements
to it, and here is one:
https://sourceforge.net/p/pdos/gitcode/ci/3356e623785e2c2e16c28c5bf8737e72df >> d39e04/
But I don't really know what I'm doing (I do know some
of the theory - but this is a particular design).
E.g. now that I have managed to get a variable passed to
a function, I now want the address of that variable passed
to the function - ie I want to do &x instead of x - and I am
not sure whether to create a new ADDRESS type, or
whether it is part of VARREF or what - in the original
(incomplete) concept. Or CC_EXPR_AMPERSAND.
I am happy to do the actual coding work - I'm just looking
for some nudges in the right direction if anyone can assist.
Thanks. Paul.
write it and they will write it..and if few thousand of people
will give some money there it will be written
I have been after a public domain C compiler for decades.
[...] I'm after C90 written in C90.
"Janis Papanagnou" <janis_papanagnou+ng@hotmail.com> wrote in message news:vhvsm9$2bmq9$1@dont-email.me...
On 24.11.2024 15:00, Paul Edwards wrote:
I have been after a public domain C compiler for decades.
[...] I'm after C90 written in C90.
Why formulate the latter condition if you can bootstrap?
(Did you mean; written in a "C" not more recent than C90?)
Yes - written in C90 so that it can be maintained with
just knowledge of C90.
And also written in C90 so that it is written naturally
for a C90 programmer, not using a subset of C90
void fn(int a)
{
int x[3] = { foo(), bar(), a }; /* not in C90 */
On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku wrote:
void fn(int a)
{
int x[3] = { foo(), bar(), a }; /* not in C90 */
is in the above foo() called before bar()?
void fn(int a)
{
int x[3];
x[0]=foo(); x[1]=bar(); x[2]=a;
this would be ok with every C compiler
On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku wrote:
void fn(int a)
{
int x[3] = { foo(), bar(), a }; /* not in C90 */
is in the above foo() called before bar()?
No, you cannot rely on that. Maybe it's fixed in a more recent standard,
The specification has an inconsistency, because it gives the order
in which initializations occur, yet not the order of evaluation of
the expressions that produce their values.
On 26/11/2024 18:59, Kaz Kylheku wrote:
On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku wrote:
void fn(int a)
{
int x[3] = { foo(), bar(), a }; /* not in C90 */
is in the above foo() called before bar()?
No, you cannot rely on that. Maybe it's fixed in a more recent standard,
The implication of the word "fixed" is that you think the current
standards as somehow "broken" in this respect. Do you think that is the case?
On 11/27/24 14:42, Kaz Kylheku wrote:
...
The specification has an inconsistency, because it gives the order
in which initializations occur, yet not the order of evaluation of
the expressions that produce their values.
That's not an inconsistency, it's a deliberate choice to give
implementations freedom to use whichever order is most convenient.
On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 11/27/24 14:42, Kaz Kylheku wrote:
...
The specification has an inconsistency, because it gives the order
in which initializations occur, yet not the order of evaluation of
the expressions that produce their values.
That's not an inconsistency, it's a deliberate choice to give
implementations freedom to use whichever order is most convenient.
Implementations are not given freedom about initialization order;
in { A, B } the initialization implied by A happens before B.
Granting a freedom here while taking it away there is inconsistent.
Expression B may rely on the initialization A having completed, but
not on the effects of A having been settled.
Kaz Kylheku <643-408-1753@kylheku.com> writes:
On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku wrote:
void fn(int a)
{
int x[3] = { foo(), bar(), a }; /* not in C90 */
is in the above foo() called before bar()?
No, you cannot rely on that. Maybe it's fixed in a more recent standard,
but C99 (which I happen to have open in a PDF reader tab) stated that
"The order in which any side effects occur among the initialization list
expressions is unspecified.". This implies that there is no sequence
point between any two initializing expressions, which means we don't
know whose expression's function call takes place first.
N3096 (C23 draft) has :
"""
The evaluations of the initialization list expressions are
indeterminately sequenced with respect to one another and thus the order
in which any side effects occur is unspecified.
"""
C23 is more explicit (redundant?) than C99, which doesn't mention the
lack of a sequence point. (C11 dropped sequence points, replacing them
with "sequenced before", "sequenced after", and "unsequenced", basically
a new way of describing the same semantics.)
Given:
int n = 42;
int a[] = { n++, n++ };
C99 could imply that the value of a is merely unspecified, either {
42, 43 } or { 43, 42 }. Though it can almost certainly be inferred
from other parts of the C99 standard that there is no sequence
point between the two evaluations of n++ (I haven't taken the time
to check).
On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku wrote:
void fn(int a)
{
int x[3] = { foo(), bar(), a }; /* not in C90 */
is in the above foo() called before bar()?
No, you cannot rely on that. Maybe it's fixed in a more recent
standard, but C99 (which I happen to have open in a PDF reader
tab) stated that "The order in which any side effects occur among
the initialization list expressions is unspecified.". This
implies that there is no sequence point between any two
initializing expressions, which means we don't know whose
expression's function call takes place first.
On 2024-11-27, David Brown <david.brown@hesbynett.no> wrote:
On 26/11/2024 18:59, Kaz Kylheku wrote:
On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku wrote:
void fn(int a)
{
int x[3] = { foo(), bar(), a }; /* not in C90 */
is in the above foo() called before bar()?
No, you cannot rely on that. Maybe it's fixed in a more recent standard,
The implication of the word "fixed" is that you think the current
standards as somehow "broken" in this respect. Do you think that is the
case?
The specification has an inconsistency, because it gives the order
in which initializations occur, yet not the order of evaluation of
the expressions that produce their values.
Above we know that x[0] is initialized first before x[1].
That doesn't even matter unless initializations are being observed,
which they can be if there is self-reference going on, like:
int x[3] = { foo(), x[0] + bar(), x[0] + x[1] }
I'm assuming this sort of thing must to be the purpose for specifying
the order of initialization.
It looks inconsistent to me that the effects of the subobjects receiving their inital values are ordered, but all other effects are not.
On 11/27/24 16:52, Kaz Kylheku wrote:
On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
On 11/27/24 14:42, Kaz Kylheku wrote:
...
The specification has an inconsistency, because it gives the order
in which initializations occur, yet not the order of evaluation of
the expressions that produce their values.
That's not an inconsistency, it's a deliberate choice to give
implementations freedom to use whichever order is most convenient.
Implementations are not given freedom about initialization order;
in { A, B } the initialization implied by A happens before B.
Granting a freedom here while taking it away there is inconsistent.
Expression B may rely on the initialization A having completed, but
not on the effects of A having been settled.
I'm sorry - I thought you meant that they were logically inconsistent.
What you're actually saying is more like stylistically inconsistent.
In C90, the order in which the initializers were evaluated didn't
matter, because they were required to be static initializers. It was
only in C99 that they were allowed to be arbitrary expressions.
However, in the same version of the standard, designated initializers
were added. Designated initializers are allowed to update elements in a different order from their order in memory, and to initialize the same element multiple times, with only the final initialization actually occurring. This can be convenient for setting up a rule and then adding exceptions to that rule.
If there weren't a rule mandating the order in
which initializers were applied, when two or more initializers affect
the same object, it wouldn't be possible to be certain which one
overrode the others.
On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
If there weren't a rule mandating the order in which initializers
were applied, when two or more initializers affect the same
object, it wouldn't be possible to be certain which one overrode
the others.
It would make sense for that simply to be a constraint violation;
two initializations for the same object are being requested.
On 2024-11-27, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:...
In C90, the order in which the initializers were evaluated didn't
matter, because they were required to be static initializers. It was
only in C99 that they were allowed to be arbitrary expressions.
However, in the same version of the standard, designated initializers
were added. Designated initializers are allowed to update elements in a
different order from their order in memory, and to initialize the same
element multiple times, with only the final initialization actually
occurring. This can be convenient for setting up a rule and then adding
exceptions to that rule.
But it simply ends up being left to right.
Given { A, B, C }, the members are initialized in order of increasing
offset address, corresponding to left-to-right order in the syntax.
Given { [2] = A, [1] = B, [0] = C }, they are initialized in the left-to-right order in the syntax: [2] first, then [1] then [0].
So we have order. And yet we don't have order; the expressions are not actually sequenced.
If there weren't a rule mandating the order in
which initializers were applied, when two or more initializers affect
the same object, it wouldn't be possible to be certain which one
overrode the others.
It would make sense for that simply to be a constraint violation;
two initializations for the same object are being requested.
There is no sequencing in the initialization: { i++, i++ } would
be undefined behavior. Yet, you can request multiple initializations
of the same subobject and have it safely resolved to the rightmost?
On 2024-11-25, Rosario19 <Ros@invalid.invalid> wrote:
On Mon, 25 Nov 2024 18:23:58 -0000 (UTC), Kaz Kylheku wrote:
void fn(int a)
{
int x[3] = { foo(), bar(), a }; /* not in C90 */
is in the above foo() called before bar()?
No, you cannot rely on that. Maybe it's fixed in a more recent standard,
but C99 (which I happen to have open in a PDF reader tab) stated that
"The order in which any side effects occur among the initialization list >expressions is unspecified.". This implies that there is no sequence
point between any two initializing expressions, which means we don't
know whose expression's function call takes place first.
In any case, a C90 compiler with the above support as an extension to
C90 can specify rigid sequencing behavior.
void fn(int a)
{
int x[3];
x[0]=foo(); x[1]=bar(); x[2]=a;
this would be ok with every C compiler
One problem is, if you're doing this because your compiler is C90, you
also have to do something about all declarations which follow the int
x[3], since they cannot occur after a statement. You can add another
level of block nesting for them, or whatever.
Initialization is preferable to leaving an object uninitialized and >assigning. There is a scope where the name is visible, but the object
is not initialized, inviting code to be inserted there which tries
to use it.
If I needed foo to be called before bar, I would still rather do
the following than assignment:
int f = foo();
int b = bar();
int x[3] = { f, b, a };
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 151:50:10 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,815 |