[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.
[01:52:16] <Zhivago> C does not have a flat memory model.
[01:52:24] <convivial> they are local stack vars
[01:52:30] <Zhivago> There is no stack in C.
[01:53:05] <convivial> void FU(){int a; int b; } here a and b are not in same place?
[01:53:11] <Zhivago> No.
[01:53:19] <Zhivago> They are completely discrete allocations.
[01:53:35] <Zhivago> Which is why you cannot say &a - &b
[01:53:48] <convivial> how is that?
[01:53:56] <Zhivago> By definition.
[01:53:58] <convivial> push allocate off stack
[01:54:04] <Zhivago> There is no stack in C.
[01:54:13] <Zhivago> Pointers in C are not offsets from some base address.
[01:54:13] <tdmackey> you are confusing what the system does and what C is.
[01:54:21] <Zhivago> A pointer in C is an index into a vector of objects.
[01:54:30] <Zhivago> In this case you have two separate vectors of one int each.
[01:54:58] <Zhivago> The indexes between two different vectors of objects are obviously not comparable, so ...
[01:55:18] <convivial> well, that is kind of dumb but also you're question is convenient because &a - &b has no application in context you specified.
[01:55:27] <convivial> *your
[01:55:40] <Zhivago> It has no application anywhere.
[01:55:44] <Zhivago> This is because it is inapplicable.
[01:55:47] <convivial> I see no reason to do that in first place.
[01:56:13] <Zhivago> What it illustrates is that your notion of 'offsets' is completely wrong.
[01:56:16] <convivial> unless &st.a - &st.b, that makes sense]
[01:56:21] <tdmackey> he is trying to get the point across that C has nothing to do with the underlying system architecture
[01:56:47] <convivial> well, ok. ok.
[01:56:55] <tdmackey> and all you are recalling is your experience with asm
[01:56:58] <convivial> I accept that and move on.
[01:57:02] <trijezdci> it would be misleading to say "there is no stack in C", instead if would be preferable to convey the intended meaning by saying "there is no stack in C terminology"
[01:57:17] <Zhivago> tri: No, it is correct to say that there is no stack in C.
[01:57:17] <tdmackey> which is blurring your understanding of C
[01:57:34] <trijezdci> no, it refers to terminology
[01:57:35] <Zhivago> tri: A C implementation might use a stack to implement auto storage, or it might not.
[01:57:42] <Zhivago> tri: No, it refers to the specification of the language.
[01:57:56] <trijezdci> you are confused what a stack is though
[01:58:07] * DaZ_ is now known as DaZ
[01:58:07] <Zhivago> No, I am not.
[01:58:14] <trijezdci> any storage that satisfies lifo semantics can be referred to as a stack
[01:58:16] <convivial> i've been away from C for 6years
[01:58:16] * PureSine_ is now known as PureSine
[01:58:27] <convivial> guess I should reread C99 spec from page 1 to end
[01:58:28] <Zhivago> tri: And C has no such storage.
[01:58:48] <tdmackey> A stack is a datastructure that C can implement, or that is used by the underlying system as a means of storage but C itself does not provide it
[01:58:54] <convivial> ~C99
[01:59:00] <convivial> !C99
[01:59:01] * candide blinks.
[01:59:03] <trijezdci> you need lifo semantics
[01:59:06] <convivial> you guys dont have bots?
[01:59:07] <Zhivago> Which means that there is no stack in C.
[01:59:12] <spv> convivial: yes.
[01:59:12] <convivial> topci
[01:59:14] <Zhivago> No, C doesn't need lifo semantics.
[01:59:27] <convivial> got it in topic
[01:59:34] <convivial> well i'm off to read up
[01:59:35] <spv> !standard convivial
[01:59:36] <candide> convivial: C99 + TC1,2,3 working paper: http://open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf - Quick C library reference: http://www.acm.uiuc.edu/webmonkeys/book/c_guide/ - An explanation of all C standards: http://clc-wiki.net/wiki/The_C_Standard
[01:59:37] <convivial> thakks
[01:59:39] <trijezdci> you need lifo semantics when means you need a stack to *implement* it
[01:59:40] <Zhivago> C only needs to be able to manage the dynamic extent of auto storage objects within blocks.
[01:59:45] <trijezdci> which*
[01:59:51] <Zhivago> There is no part of C that requires lifo semantics.
[01:59:57] <tdmackey> why do I need lifo semantics?
[02:00:02] <trijezdci> you could use a heap to implement your lifo semantics
[02:00:09] <trijezdci> and that would then qualify as a stack
[02:00:17] <Zhivago> tri: There are no lifo semantics.
[02:00:20] <trijezdci> even though its not the machine stack most implementation do use
[02:00:35] <tdmackey> once again, C, the language, doesn't know or care
[02:00:46] <Zhivago> tri: Consider { int i; int j; ... } What order do i and j get deallocated in?
[02:00:48] <trijezdci> lifo => last in - first out
[02:00:55] <Zhivago> tri: Yes, so answer my question.
[02:01:16] <trijezdci> allocation matters not
[02:01:18] <trijezdci> access matters
[02:01:31] <Zhivago> tri: Uh, so what part of C do you think you're referring to here?
[02:01:55] <trijezdci> without lifo semantics in your storage implementation you cannot do recursion
[02:02:03] <trijezdci> C explicitly supports recursion
[02:02:13] <Zhivago> tri: What does recursion have to do with stacks?
[02:02:43] <trijezdci> stacks are the common term used for storage implementations that satisfy lifo
[02:02:56] <Zhivago> So what?
[02:03:07] <Zhivago> There is no implementation in C.
[02:03:11] <trijezdci> it encompasses a wider range that the machine stacks you have on most CPUs
[02:03:11] <tdmackey> C doesn't care about implementation