[01:26:24] <convivial> Hello.
[01:26:26] <convivial> question.
[01:26:42] <convivial> & operator actually takes offset of variable and not true address
[01:27:22] <convivial> the reaason I think is because code can be relocated by OS there, if & took physical address at some point in program address would be invalid
[01:27:38] <convivial> thus,& is actually get memory offset of not address of
[01:28:47] <twkm> how the & prefix operator is implemented is, well, an implementation detail.
[01:28:58] <twkm> why do you care if it is the "true" address?
[01:29:55] <Oddity> Look-up "logical address". And I don't really see a question anywhere.
[01:30:05] <convivial> well, sometimes you want physical address rather than logical
[01:30:25] <convivial> question is, how does one get true physics address?
[01:30:31] <convivial> of like port?
[01:30:39] <spv> that's got nothing to do with C really, it's your implementation.
[01:30:40] <twkm> what if such things don't exist?
[01:31:10] <convivial> C has to provide a way to get physical addresses
[01:31:22] <Peaker> convivial: why?
[01:31:41] <convivial> how does one access ports then?
[01:32:08] <twkm> if such things exist, you using o/s specific facilities.
[01:32:14] <Peaker> convivial: with implementation-specific libraries provided by the platform/etc
[01:32:57] <Oddity> C doesn't provide you with many things.
[01:33:16] <convivial> ok.
[01:33:35] <tdmackey> yeah, it is something the operating system or hardware specific driver would provide c bindings for, but c by itself does not provide something
[01:33:36] <convivial> I guess the best way if to get access to Ring 0 of processor, (intel), and set data segment at 0.
[01:33:47] <twkm> sigh.
[01:35:24] <convivial> hmmm...
[01:35:46] <convivial> ok, then ... I just curious, it just popped into my head one night when i was thinking about pointers.
[01:35:55] <convivial> yeah, i guess the OS would provide that
[01:37:25] <convivial> but, i feel that offset is better term than address, because in todays world , you're dealling with multiprocess os's, even most embedded thus you'll never get a true address with '&' operator
[01:38:04] <convivial> only it's offset within the data segment, however that may be defined per CPU/OS
[01:38:46] <convivial> it may confuse students learning C and OS design at same time I bet.
[01:39:01] <melba> didn't confuse me
[01:39:02] <twkm> uh-huh.
[01:39:28] <convivial> me either but I can from world of 8bit asm, must students dont have that background
[01:39:48] <tdmackey> most students don't jump in from no knowledge to core OS design
[01:39:51] <spv> convivial: C doesn't define things such as data segments, so why would it even be relevant?
[01:40:12] <convivial> spv: that was not the mainpoint
[01:40:22] <convivial> spv: my point is that & is not returning addresses
[01:40:37] <spv> sure it is
[01:40:38] <Oddity> It returns the logical address of the variable.
[01:40:43] <tdmackey> and you aren't going to change a term that has been used in such a way since the early 70s
[01:40:56] <convivial> in fact, (*ptr)() and &a could have same value
[01:41:16] <Oddity> Maybe you should go back to studying.
[01:41:21] <Oddity> Study memory models or something.
[01:41:28] <spv> study the C standard
[01:41:35] <Oddity> that too
[01:41:53] <convivial> given, void (*ptr)() = printf; and int a;
[01:42:02] <Zhivago> convivial: You do not understand what address means, then.
[01:42:14] <Zhivago> convivial: Also, you might be confused about what 'offset' means.
[01:42:23] <Zhivago> convivial: int a; What is the 'offset' of a?
[01:42:23] <convivial> an address is location in memory
[01:42:39] <convivial> offset is displacement from base address
[01:42:43] <tdmackey> an absolute address uniquely identifies a location in memory, but a relative address does not
[01:42:44] <Zhivago> convivial: What base address?
[01:42:57] <convivial> base address is defined by OS
[01:43:03] <Zhivago> What base address i nC?
[01:43:04] <convivial> it is the address of code or data segemtns
[01:43:11] <Zhivago> What code or data segment in C?
[01:43:26] <convivial> come on now,
[01:43:36] <convivial> you know that eventually you get linked
[01:43:38] <Zhivago> Ah, you don't know ...
[01:43:44] <Zhivago> There are no base addresses in C.
[01:43:49] <Zhivago> There are no code or data segments in C.
[01:43:57] <Zhivago> And this is why you do not understand these terms properly.
[01:43:59] <convivial> Not in C per se, but the linked code it is.
[01:44:05] <Zhivago> An address is a means by which you can find an object.
[01:44:11] <Zhivago> This is precisely what &a gives you.
[01:44:17] <convivial> C does not have object's
[01:44:17] <Zhivago> *&a being the object a.
[01:44:27] <convivial> you're confused with java or c#
[01:44:30] <Zhivago> C has objects -- read the C specification.
[01:44:31] <spv> convivial: yes it does.
[01:44:36] <Oddity> HAHA\
[01:44:37] <convivial> C has data types
[01:44:37] <spv> convivial: int a; a is an object.
[01:44:59] <convivial> and aggregates
[01:45:01] <Zhivago> C has data types, which may be objects or values.
[01:45:34] <convivial> C has primitive types, aggregates
[01:45:41] <Zhivago> convivial: That is irrelevant.
[01:45:53] <convivial> aggregates include arrays, structs,
[01:45:59] <Zhivago> convivial: Again, irrelevant to objects.
[01:46:08] <convivial> primitives are integral types
[01:46:11] <Zhivago> convivial: int a; <- a is an object of type int.
[01:46:28] <Zhivago> convivial: a + 1 <- this is an expression producing a value of type int.
[01:46:29] <convivial> ok, call it object.
[01:46:38] <Zhivago> Yes, I will -- just like the C specification does.
[01:46:59] <convivial> I['m going to submit they change it
[01:47:00] <Peaker> Zhivago: that's often termed "lvalue" and "rvalue", no?
[01:47:05] <spv> convivial: want to know what the standard defines as an object? "region of data storage in the execution environment, the contents of which can represent values"
[01:47:17] <convivial> and gopiikng to submit they change address to offset
[01:47:36] <Zhivago> Peaker: As the C standard notes, those are better termed "object" and "value".
[01:47:55] <Zhivago> Peaker: Particularly since lvalue and rvalue are meaningless gibberish.
[01:48:19] <Zhivago> Also, it doesn't address the issue of what objects are -- an lvalue is how an object can be used.
[01:48:21] <tdmackey> convivial: learn the terms as they stand instead of fighting a community of programmers than has been using them since 1972
[01:48:24] <spv> I'm sure the C standards committee would love to hear your suggestion that they change the definition.
[01:49:12] <Oddity> must be a troll...
[01:49:21] <convivial> I'm just being architecturally correct
[01:49:24] <convivial> that's all.
[01:49:33] <Zhivago> convivial: No, you are being architecturally incorrect.
[01:49:34] <convivial> I know what we call them in asm
[01:49:41] <Zhivago> convivial: Asm isn't C.
[01:49:51] <tdmackey> convivial: you are being ignorant and interweaving hardware programming and C
[01:49:54] <Zhivago> convivial: The correct architecture for C is the C Abstract Machine.
[01:50:06] <convivial> ok.
[01:50:11] <Zhivago> convivial: Stop confusing asm with C and you'll start to understand C, which has a very different model.
[01:50:34] <convivial> I will stick to strict C99 terminology then...
[01:51:00] <Zhivago> int a; int b; What is &a - &b?
[01:51:18] <convivial> Zhivago: that is unknown
[01:51:35] <Zhivago> No, it's incorrect.
[01:51:47] <convivial> it will be the difference betwenen offsets
[01:51:48] <Zhivago> You may not subtract pointers that point into different vectors of objects.
[01:51:57] <Zhivago> No, you are wrong. There is no offsets here.
[01:52:01] <convivial> but the value i can't say
[01:52:07] <Zhivago> The objects a and b are not in the same memory space.