- alignment and endian issues - 6 Updates
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 18 10:00PM +0100 On Wed, 18 Apr 2018 16:43:22 -0400 > examination of data as data. This clashes with the way C++ views > data through a protocol lens, and there lies the source of the dis- > crepancy. You are imagining things: there was no negative characterization in "unbaffle". Perhaps something got lost while crossing the Atlantic. My earlier characterization of your views on the adequacy of tests to deal with detecting whether undefined behaviour did what was wanted as "deranged" seems to me to be justified technically, and addressed to your views and not to you. I chose my words carefully and refrained from expressing a view on the latter, which I think is pretty kind given some of your other off-topic posts to this newsgroup. I described you as "clueless" in relation to what I took to be your intransigent assertions of the inefficiency of memcpy(), contrary to facts. Maybe it was unkind; but I think it was fair given that you never seem to change your views on anything and seem confident of the correctness of all your views and the incorrectness of everyone else's. > a source to destination of an 8-byte type is 8 bytes of data being > copied, yet a memcpy() (with a parameter no less) indicating 8 bytes > tells the compiler it is an acceptable form of data exchange. The difference is that the dynamic type of the return value of std::reinterpret_cast is the dynamic type of the input value. So the dereference on the assignment to 'd' gives rise to undefined behaviour. The dynamic type of the return value of std::memcpy is the dynamic type of the destination, so all is good. |
| David Brown <david.brown@hesbynett.no>: Apr 18 11:28PM +0200 On 18/04/18 22:02, Rick C. Hodgin wrote: > which does not correlate something like a cast pointer copying 8 > bytes, compared to a memcpy() which copies 8 bytes, is the insane > component of that discussion. That's your problem here - data is /not/ data in a typed language. Data is organised by types, which say how that data is interpreted and what you can do with it. It is basically meaningless in a typed language to try to interpret the data of one type as though it were a different type, just because it happens to take the same number of bytes in its representation. Very occasionally you want to go to a lower level with C or C++, and look at the underlying data - that's why the language gives you facilities like memcpy and type-punning unions. But these are for special circumstances. It's fine if you want to make your own language typeless or type-unsafe. But that is not how C or C++ work. |
| David Brown <david.brown@hesbynett.no>: Apr 18 11:44PM +0200 On 18/04/18 22:27, Rick C. Hodgin wrote: > how a compiler can look at a memcpy() of 8 bytes from the same source > as a cast pointer dereference copy of the same 8 bytes can be UB in > one case, and not UB in another. Okay, let's break that down into steps. First, do you understand how the compiler can take what is logically a call to a function called memcpy(), and (when appropriate) turn it into a single 64-bit load? In many cases, I have seen memcpy() removed altogether and data simply kept in registers. Secondly, do you understand that C and C++ do not allow you to access data of one type through a pointer to a different type, except in certain specific circumstances? (I am not asking if you think this is a good idea - merely if you understand the meaning of the text in the standards. For C, it is at 6.5p7.) And that a key case here is that you can access any data via a character type pointer. In that case, you should understand that you are not allowed to access the character data (from the const char* pointer) as a completely different type. But you /are/ allowed to access it via a char* pointer - and you are also allowed to access the uint64_t variable via a char* pointer. Therefore, the memcpy is allowed but accessing via the cast is not. > It shows how close behavior is to typing in C++. Typing is important in C, and critical in C++. > as indicated, it will compile and run as you expect it to. It's up > to you, the developer, to know of any special cases where the actual > underlying data may be invalid. C and C++ are designed to make it difficult to get your types wrong. It would arguably have been better if pointer casts like this were not allowed, leading to compile-time errors for this sort of thing. Unfortunately you simply have to know. |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 18 05:56PM -0400 On 4/18/2018 5:00 PM, Chris Vine wrote: > dereference on the assignment to 'd' gives rise to undefined > behaviour. The dynamic type of the return value of std::memcpy is the > dynamic type of the destination, so all is good. Yes. I still do not see it. It's all about constraints imposed upon otherwise legal and valid data movement by a typing system. CAlive removes that constraint and limitation completely. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 18 06:01PM -0400 On 4/18/2018 5:44 PM, David Brown wrote: > - and you are also allowed to access the uint64_t variable via a char* > pointer. Therefore, the memcpy is allowed but accessing via the cast is > not. I recognize it as a limitation to the C++ compiler. I do not recognize it as any kind of fundamental limitation. It is a limitation imposed upon otherwise valid data moves for the sake and limitations of the compiler. >> It shows how close behavior is to typing in C++. > Typing is important in C, and critical in C++. Typing is necessary in CAlive for data manipulation and use, but CAlive recognizes that the underlying data is data, and allows it to be accessed at all times as such. > would arguably have been better if pointer casts like this were not > allowed, leading to compile-time errors for this sort of thing. > Unfortunately you simply have to know. CAlive does not let you write code that violates types either. But it allows a re-cast of something to be known from that point forward to be a re-cast of that type, and then treats whatever is there at that memory location as such. I think type constraints of the forms seen in this thread are quite ludicrous. They belie the true nature of the data operation under the guise of following protocol. I think it's a weakness in the language, and one I am glad to leave behind. -- Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9 Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj ------------------------------------------------------------------------- Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA |
| David Brown <david.brown@hesbynett.no>: Apr 19 12:16AM +0200 On 19/04/18 00:01, Rick C. Hodgin wrote: >> a char* pointer. Therefore, the memcpy is allowed but accessing via >> the cast is not. > I recognize it as a limitation to the C++ compiler. You mean a limitation of the C++ (and C) language, not the compiler. > the guise of following protocol. > I think it's a weakness in the language, and one I am glad to leave > behind. I would say it is a strength in the language, not a weakness. (The weakness is not getting enough automated help in spotting aliasing errors - but you know you are doing something dodgy whenever you are casting pointers to something other than character pointers, so you know where to be careful.) C and C++ do let you access the underlying data, but discourage it - and the compiler can assume you are not breaking the rules. There is a place for languages with weak typing and a "data is data" attitude. Assembly is a fine example. I realise it is highly unlikely that I'd be able to persuade you that strong typing is a good idea and that limiting low-level manipulation and access of data outside the type system is important to keeping the types strong. It is good enough for now if you understand how C and C++ work here. What you choose for your own language is up to you. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment