 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> The real killer for such a system is the number of people who *do* assume
> 8-bit bytes. What happens when you have 10-bit characters and you call
> write(14, "Zoop", 4)
> and handle 14 is a TCP socket?
Hell breaks loose?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Darren New wrote:
>> The real killer for such a system is the number of people who *do* assume
>> 8-bit bytes. What happens when you have 10-bit characters and you call
>> write(14, "Zoop", 4)
>> and handle 14 is a TCP socket?
>
> Hell breaks loose?
I don't know. But that's the problem Ada solves by separating out "bytes of
memory" from "bytes of I/O". Of course, as Warp points out, for 99% of the
population not writing code for embedded processors in weapons systems,
those two types are always the same and it's annoying as hell to write any
I/O stuff in Ada. :-)
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] san rrcom> wrote:
>> Actually, thinking on this, it's obviously impossible to follow the
>> standards on any machine with virtual addressing, too.
>
> Why? I thought the whole idea of virtual addressing is that non-contiguous
> memory is made to *look* contiguous to a program, which is precisely what
> the C standard requires. So virtual addressing *fixes* the problem rather
> than *creating* it.
I was addressing the part of the original comments that said the same bit
can't be part of two different bytes.
In any case, if I have more RAM than address space (say, a 6G box running
under WindowsXP-32), I can address all of memory, just not with a char*. So
VM both lets me have one byte in two places and also lets me have bytes that
no pointer can point to.
That's why I'm curious about exactly how the standards body worded these
things, rather than the FAQ-writer's take on it. I'm sure the standards body
isn't still back in a Z-80 mindset.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Then how do you copy blocks of memory from one place to another with a
> function like memcpy()?
Why would memcpy be harder to implement than a while loop copying bytes?
My point is that if *no* program in that language can access those "hidden"
bits, how would your program know? Consider the bits hidden in (for example)
the processor registers. I worked on a mainframe where the registers were
mapped to addresses 0 thru 15. You could literally branch to instructions
stored in the registers. But you can't do that with AX/BX/SI/DI registers.
There's bits of "memory" that C can't address with a char*. Yet it isn't
problematic, because while memcpy() can't copy them, nothing else can see
that the copy can't copy them. I might have ECC bits or parity bits in my
memory, which C also can't address. It's not a problem for C.
Imagine if your C compiler was set up to only ever address even-numbered
bytes. Would you notice, other than running out of RAM twice as fast as you
thought you should? memcpy() would only copy even-numbered addresses, but
since nothing you do in the language would see odd-numbered addresses,
that's OK. (Until you share that memory with some other process via OS
primitives, but that isn't really relevant here.)
> If an architecture cannot support memcpy() then that would certainly
> break quite come C programs.
memcpy() doesn't need to copy all memory. It only needs to copy all
addressable memory.
--
Darren New, San Diego CA, USA (PST)
Insanity is a small city on the western
border of the State of Mind.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
