|
|
|
|
|
|
| Author |
Message |
neutron*star
*nix forums Guru
Joined: 21 Feb 2005
Posts: 2039
|
 Posted: Fri Jul 14, 2006 4:26 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
lovecreatesbeauty said:
| Quote: |
goose wrote:
E.g. on a DOS box using Turbo C, doing the following
unsigned char *mem_base = 0xb8000000L;
*mem_base = 'A';
What is the intention of this try? Demonstrates undifined behavior?
|
Yes, it demonstrates how undefined behaviour can be *useful*, if you know
what you're doing and are prepared to trade off portability for
functionality or performance.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously) |
|
| Back to top |
|
 |
Nelu
*nix forums beginner
Joined: 22 Jun 2006
Posts: 31
|
| Posted: Fri Jul 14, 2006 4:37 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
"lovecreatesbeauty" <lovecreatesbeauty@gmail.com> writes:
| Quote: | goose wrote:
E.g. on a DOS box using Turbo C, doing the following
unsigned char *mem_base = 0xb8000000L;
*mem_base = 'A';
What is the intention of this try? Demonstrates undifined behavior?
|
Not sure it's undefined-behavior. At least the first line of code is
implementation-defined (if it has the right cast). This is a good
example of how you can use C to work with the hardware when you know
what you are doing. It's not portable from hardware to hardware and OS
to OS but it works really well on Turbo C and DOS (I used that from
Pascal, actually, to save the display in text mode, and to use crt
windows without the crt unit Turbo Pascal offered).
--
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...) |
|
| Back to top |
|
|
Darren New
*nix forums beginner
Joined: 16 Jun 2006
Posts: 42
|
| Posted: Fri Jul 14, 2006 4:54 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
goose wrote:
| Quote: | AFAIK, its only a trap representation or incorrectly aligned
or not an entity of the referenced type *if* the implementation
does not define it.
|
Sure. So it's not "ANSI C" that lets you write the OS. It's that your
particular compiler has finished defining the undefined semantics that C
allows.
I could as easily write a LISP function that accepts a memory address
and a byte to store there, and say I've defined something that lets me
write kernels. Just because *your* CL doesn't define that doesn't mean
LISP isn't as good as C for that. I'm pretty sure a CL is allowed to
include libraries not defined by the standard. :-)
(And note that Ada is actually better than C for writing this stuff, as
you don't have to leave the language to deal with threads, interrupts,
or writing to memory addresses that actually need to be written
atomically and/or without being optimized away. I don't know why nobody
mentions Ada when discussing how great C is for this stuff. You really
can't write a kernel in C if your machine uses memory maps, I/O ports,
interrupts, etc.)
| Quote: | This is because under that implementation, the
result is well-defined.
|
No it's not. Turn up the optimization, and that entire statement could
disappear. (Yes, you can fix this, but that you didn't helps show my
point. :-)
(Sorry. This is just one of my pet peeves, along with the "my language
is as productive as yours because they're both Turing Complete.)
--
Darren New / San Diego, CA, USA (PST)
This octopus isn't tasty. Too many
tentacles, not enough chops. |
|
| Back to top |
|
|
goose
*nix forums addict
Joined: 05 Jun 2005
Posts: 54
|
| Posted: Fri Jul 14, 2006 6:24 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
Darren New wrote:
| Quote: | goose wrote:
AFAIK, its only a trap representation or incorrectly aligned
or not an entity of the referenced type *if* the implementation
does not define it.
Sure. So it's not "ANSI C" that lets you write the OS. It's that your
particular compiler has finished defining the undefined semantics that C
allows.
|
The C standard differentiates between "undefined" and "implementation
defined" whereas the Lisp standard doesn not. This makes the rest of
your
reasoning invalid :-)
<snipped>
goose,
No, I'm not playing that game, I know better than to think
that any one language is suitable for every task |
|
| Back to top |
|
|
goose
*nix forums addict
Joined: 05 Jun 2005
Posts: 54
|
| Posted: Fri Jul 14, 2006 6:49 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
Richard Heathfield wrote:
| Quote: | lovecreatesbeauty said:
goose wrote:
E.g. on a DOS box using Turbo C, doing the following
unsigned char *mem_base = 0xb8000000L;
*mem_base = 'A';
What is the intention of this try? Demonstrates undifined behavior?
Yes, it demonstrates how undefined behaviour can be *useful*, if you know
|
Er.
I was aiming for "implementation defined", but I'm open to being
convinced that it (with the correct cast that I was stupid enough
to forget!) is /undefined/ rather than /implementation defined/.
<snipped>
goose,
Once upon a time, I actually used that |
|
| Back to top |
|
|
Keith Thompson
*nix forums Guru
Joined: 28 Feb 2005
Posts: 5173
|
| Posted: Fri Jul 14, 2006 7:43 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
Darren New <dnew@san.rr.com> writes:
[...]
| Quote: | (And note that Ada is actually better than C for writing this stuff,
as you don't have to leave the language to deal with threads,
interrupts, or writing to memory addresses that actually need to be
written atomically and/or without being optimized away. I don't know
why nobody mentions Ada when discussing how great C is for this
stuff. You really can't write a kernel in C if your machine uses
memory maps, I/O ports, interrupts, etc.)
[...] |
Yes, you really can. You just can't write it in *portable* C. The C
standard specifically allows implementations to provide extensions (as
long as they don't change the behavior of any strictly conforming
program) and a program that uses those extensions can still be a
"conforming program" in the sense defined in the standard.
<OT>
Ada does provide some features that let you do certain low-level
things that aren't directly supported in unextended C, but any Ada
program that uses those features will still be non-portable. For
example, Ada defines a language-level mechanism for interrupt handers,
but the type Interrupt_ID is implementation-defined. This has some
advantages over C's approach of leaving the entire mechanism up to the
implementation, but it still doesn't let you write truly portable
interrupt-handling code.
</OT>
--
Keith Thompson (The_Other_Keith) kst-u@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. |
|
| Back to top |
|
|
neutron*star
*nix forums Guru
Joined: 21 Feb 2005
Posts: 2039
|
| Posted: Fri Jul 14, 2006 9:28 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
goose said:
| Quote: |
Richard Heathfield wrote:
lovecreatesbeauty said:
goose wrote:
E.g. on a DOS box using Turbo C, doing the following
unsigned char *mem_base = 0xb8000000L;
*mem_base = 'A';
What is the intention of this try? Demonstrates undifined behavior?
Yes, it demonstrates how undefined behaviour can be *useful*, if you know
Er.
I was aiming for "implementation defined", but I'm open to being
convinced that it (with the correct cast that I was stupid enough
to forget!) is /undefined/ rather than /implementation defined/.
|
[ I'll forgive your forgetting the cast, because the compiler should yell
anyway.  ]
If it's implementation-defined, the Standard will say so. If the Standard
says so, you'll be able to demonstrate this. :-)
| Quote: | goose,
Once upon a time, I actually used that
|
Er, yeah, me too...
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously) |
|
| Back to top |
|
|
Ian
*nix forums Guru
Joined: 16 Aug 2005
Posts: 1615
|
| Posted: Fri Jul 14, 2006 9:49 pm Post subject:
Re: About iServicePro
|
|
|
Al Balmer wrote:
| Quote: | On Fri, 14 Jul 2006 22:40:25 +1200, Ian Collins <ian-news@hotmail.com
wrote:
jjf@bcs.org.uk wrote:
Please do not spam somp.lang.c with unsolicited advertisements which
are entirely off-topic.
I've asked before and I'll ask again - please don't reply to spam that a
decent news server will filter out. If you must, for pity's sake don't
quote it!
Treat it like any other off topic posting - tell the poster not to do
it again, then tell him where to go.
Do you think spammers read the followups to their posting? Best let the |
machines take care of spam.
--
Ian Collins. |
|
| Back to top |
|
|
goose
*nix forums addict
Joined: 05 Jun 2005
Posts: 54
|
| Posted: Fri Jul 14, 2006 9:58 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
Richard Heathfield wrote:
| Quote: | goose said:
Richard Heathfield wrote:
lovecreatesbeauty said:
goose wrote:
E.g. on a DOS box using Turbo C, doing the following
unsigned char *mem_base = 0xb8000000L;
*mem_base = 'A';
What is the intention of this try? Demonstrates undifined behavior?
Yes, it demonstrates how undefined behaviour can be *useful*, if you know
Er.
I was aiming for "implementation defined", but I'm open to being
convinced that it (with the correct cast that I was stupid enough
to forget!) is /undefined/ rather than /implementation defined/.
[ I'll forgive your forgetting the cast, because the compiler should yell
anyway. ]
If it's implementation-defined, the Standard will say so. If the Standard
says so, you'll be able to demonstrate this. :-)
|
Sigh. Whatever happened to the practice of ruthlessly
correcting every misconception on clc? There was a
time one could look up facts merely by asserting the
fact on clc and hordes of people would rush to be the
first to correct him; now we have to look up our own
facts to support our case :-)
Anyway, C&V from my copy of n869, 6.3.2.3 (Pointers):
"[#5] An integer may be converted to any pointer type. |
Except as previously specified, the result is
implementation-defined, might not be properly aligned, and
might not point to an entity of the referenced type"
Now, that /may/ be a little ambiguous but I take the
meaning to be that it will be one of:
1. Implementation-defined.
OR
2. Might not be properly aligned.
Might not point to an entity of the referenced type.
The reason I read it that way is because the last two
options say "might" but the first one says "is", hence I regard
it to only be the last two options if the implementation
has not defined it. In the example I gave, the implementation
defines the conversion (graphics buffer, or suchlike).
Anyway, if I'm reading it wrong, someone *really* should
be correcting me (where's Mr Pop?).
goose,
ISTR something about a trap value, but n869 does not
have that. |
|
| Back to top |
|
|
neutron*star
*nix forums Guru
Joined: 21 Feb 2005
Posts: 2039
|
| Posted: Fri Jul 14, 2006 10:02 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
goose said:
<snip>
| Quote: |
Anyway, C&V from my copy of n869, 6.3.2.3 (Pointers):
"[#5] An integer may be converted to any pointer type. |
Except as previously specified, the result is
implementation-defined, might not be properly aligned, and
might not point to an entity of the referenced type"
|
Yes, the result of the conversion is implementation-defined. The result of
dereferencing the resulting pointer, however, is undefined. (But it can be
useful nevertheless, as hitherto acknowledged.)
<snip>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously) |
|
| Back to top |
|
|
goose
*nix forums addict
Joined: 05 Jun 2005
Posts: 54
|
| Posted: Fri Jul 14, 2006 10:16 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
Richard Heathfield wrote:
| Quote: | goose said:
snip
Anyway, C&V from my copy of n869, 6.3.2.3 (Pointers):
"[#5] An integer may be converted to any pointer type. |
Except as previously specified, the result is
implementation-defined, might not be properly aligned, and
might not point to an entity of the referenced type"
Yes, the result of the conversion is implementation-defined. The result of
dereferencing the resulting pointer, however, is undefined. (But it can be
useful nevertheless, as hitherto acknowledged.)
|
I hate to be bothersome, but I don't suppose you have
C&V for that?
goose,
thanks |
|
| Back to top |
|
|
neutron*star
*nix forums Guru
Joined: 21 Feb 2005
Posts: 2039
|
| Posted: Fri Jul 14, 2006 10:24 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
goose said:
| Quote: |
Richard Heathfield wrote:
goose said:
snip
Anyway, C&V from my copy of n869, 6.3.2.3 (Pointers):
"[#5] An integer may be converted to any pointer type. |
Except as previously specified, the result is
implementation-defined, might not be properly aligned, and
might not point to an entity of the referenced type"
Yes, the result of the conversion is implementation-defined. The result
of dereferencing the resulting pointer, however, is undefined. (But it
can be useful nevertheless, as hitherto acknowledged.)
I hate to be bothersome, but I don't suppose you have
C&V for that?
|
If a ``shall'' or ``shall not'' requirement that appears outside of
a constraint is violated, the behavior is undefined. Undefined
behavior is otherwise indicated in this Standard by the words
``undefined behavior'' or by the omission of any explicit definition
of behavior. There is no difference in emphasis among these three;
they all describe ``behavior that is undefined.''
I claim that the Standard omits any explicit definition of behaviour, and
therefore the behaviour is undefined. If you can show that I'm wrong, feel
free.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously) |
|
| Back to top |
|
|
Eric Sosman
*nix forums Guru
Joined: 21 Feb 2005
Posts: 1246
|
| Posted: Fri Jul 14, 2006 10:29 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
goose wrote On 07/14/06 17:58,:
| Quote: | [...]
Anyway, C&V from my copy of n869, 6.3.2.3 (Pointers):
"[#5] An integer may be converted to any pointer type. |
Except as previously specified, the result is
implementation-defined, might not be properly aligned, and
^^^ |
| Quote: | might not point to an entity of the referenced type"
Now, that /may/ be a little ambiguous but I take the
meaning to be that it will be one of:
1. Implementation-defined.
OR
^^ ? |
| Quote: | 2. Might not be properly aligned.
Might not point to an entity of the referenced type.
The reason I read it that way is because the last two
options say "might" but the first one says "is", hence I regard
it to only be the last two options if the implementation
has not defined it. [...]
|
You've mis-read the compound predicate. The sentence
contains three statements (here simplified by removal of the
limiting clause at the start):
The result is implementation-defined.
The result might not be properly aligned.
The result might not point to an entity of the
referenced type.
.... and asserts that all three ("and") of these are true.
The fact that two of the statements happen to have the same
verb is irrelevant.
--
Eric.Sosman@sun.com |
|
| Back to top |
|
|
Alan Balmer
*nix forums Guru
Joined: 22 Feb 2005
Posts: 490
|
| Posted: Fri Jul 14, 2006 10:34 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
On 14 Jul 2006 09:14:03 -0700, "lovecreatesbeauty"
<lovecreatesbeauty@gmail.com> wrote:
| Quote: |
goose wrote:
E.g. on a DOS box using Turbo C, doing the following
unsigned char *mem_base = 0xb8000000L;
*mem_base = 'A';
What is the intention of this try? Demonstrates undifined behavior?
G> You have to recognize the magic number. It's the address of (one |
kind of) video memory on a DOS system.
DOS programs that needed fast video poked values directly.
--
Al Balmer
Sun City, AZ |
|
| Back to top |
|
|
Keith Thompson
*nix forums Guru
Joined: 28 Feb 2005
Posts: 5173
|
| Posted: Fri Jul 14, 2006 11:24 pm Post subject:
Re: Amazon used lisp & C exclusively? (clc,cll)
|
|
|
Richard Heathfield <invalid@invalid.invalid> writes:
| Quote: | goose said:
Richard Heathfield wrote:
goose said:
snip
Anyway, C&V from my copy of n869, 6.3.2.3 (Pointers):
"[#5] An integer may be converted to any pointer type. |
Except as previously specified, the result is
implementation-defined, might not be properly aligned, and
might not point to an entity of the referenced type"
Yes, the result of the conversion is implementation-defined. The result
of dereferencing the resulting pointer, however, is undefined. (But it
can be useful nevertheless, as hitherto acknowledged.)
I hate to be bothersome, but I don't suppose you have
C&V for that?
If a ``shall'' or ``shall not'' requirement that appears outside of
a constraint is violated, the behavior is undefined. Undefined
behavior is otherwise indicated in this Standard by the words
``undefined behavior'' or by the omission of any explicit definition
of behavior. There is no difference in emphasis among these three;
they all describe ``behavior that is undefined.''
I claim that the Standard omits any explicit definition of behaviour, and
therefore the behaviour is undefined. If you can show that I'm wrong, feel
free.
|
C99 6.5.3.2p4, defining the semantics of the unary "*" operator, says:
The unary * operator denotes indirection. If the operand points to
a function, the result is a function designator; if it points to
an object, the result is an lvalue designating the object. If the
operand has type "pointer to type", the result has type "type". If
an invalid value has been assigned to the pointer, the behavior of
the unary * operator is undefined.
The code in question, as I recall, initialized a pointer with an
integer literal (assuming a cast that was missing in the original
code). If there happens to be an object at that address,
dereferencing the pointer is well defined and yields an lvalue
designating the object. If there is no such object, the behavior is
undefined. The standard says there may or may not be such an object,
so I'd say the behavior is conditionally undefined (and should be
treated as unconditionally undefined in anything pretending to be
portable code).
--
Keith Thompson (The_Other_Keith) kst-u@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. |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Fri Nov 21, 2008 3:09 am | All times are GMT
|
|
Auto Loans | Yu gi oh | Loan | Loans | Business Credit Cards
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
Programming
»
C
