Cleaning up X server warnings • Hacker News Board

Re: Cleaning up X server warnings

#31

Post by mikeash » Sun, Dec 15, 2013, 9:46 PM UTC

raverbashing wrote: post #30

mikeash wrote: post #26

Earlier quoted context omitted.

This is not necessarily true. Lots of systems support running 32-bit and 64-bit binaries simultaneously, and structs won't necessarily be portable between the two. Some versions of Mac OS X even supported running 32-bit PowerPC binaries (in an emulator, but supported directly by the OS) next to both 32-bit and 64-bit x86 binaries, so you could not only get size mismatches, but also endian mismatches. This does not ap…

On the same machine, it's going to be rare But the most common occurrence of this I can think are online games.

Depends on what system and context you're talking about. I'd assume it's rare on Linux where most things are built from source, but it's pretty common on e.g. Apple platforms where binary compatibility means 32-bit processes keep being supported for years, and they still need to IPC to various system services. I've seen one highly amusing bug in Apple's iOS frameworks where they didn't quite handle the 32->64 IPC case properly because of an implicit assumption that data types remained identical.

Re: Cleaning up X server warnings

#32

Post by mikeash » Sun, Dec 15, 2013, 9:48 PM UTC

asveikau wrote: post #29

mikeash wrote: post #28

Earlier quoted context omitted.

That's a good point, and he's largely right. On the other hand, I've been burned before (Macs were always going to be 68k until they went PPC, they were always going to be PPC until they went Intel, they were always going to be Intel until Apple made these tiny mini-Macs that were ARM) and I'm wary of making assumptions anymore.

This is usually my kind of instinct too, which is why I was attributing the other viewpoint to someone else. But it was interesting to understand where someone like that is coming from. You can spend a lot of time adding the right swaps etc. but in the end if you don't own hardware that works that way, aren't testing it regularly, from a certain perspective you may be wasting your time. OTOH I recall that insightful…

For what it's worth, I completely agree with Pike there. It makes a lot more sense to me, and refrains from completely falling afoul of the C standard.

Re: Cleaning up X server warnings

#33

Post by joosters » Sun, Dec 15, 2013, 11:24 PM UTC

mikeash wrote: post #26

joosters wrote: post #13

Earlier quoted context omitted.

Also, if you're passing data between two processes (e.g. your code fork()d a child), you can be sure that the data format is going to match, no packing required. (still need to ensure alignment in memory though)

This is not necessarily true. Lots of systems support running 32-bit and 64-bit binaries simultaneously, and structs won't necessarily be portable between the two. Some versions of Mac OS X even supported running 32-bit PowerPC binaries (in an emulator, but supported directly by the OS) next to both 32-bit and 64-bit x86 binaries, so you could not only get size mismatches, but also endian mismatches. This does not ap…

Oh yes, I was a bit unclear but I meant two processes (from the same binary) communicating.

Without that condition, you've got all the original problems, as listed. You can also have incompatibilities between compilers, or even compiler versions - e.g. gcc has ABI changes between some versions.

Re: Cleaning up X server warnings

#34

Post by joosters » Sun, Dec 15, 2013, 11:28 PM UTC

mtklein wrote: post #19

joosters wrote: post #6

Earlier quoted context omitted.

I thought that the issue is the const-ness of the variables, and nothing to do with casting void* ->sometype* Essentially, they are making use of const pointers to ensure that the code doesn't change the data. (gcc would throw a warning if you did). BUT: the problem comes when you want to free() the data. A strict interpretation of C would be that you can't free() something that's const, because it clearly is alterin…

On a related note, if you're using new and delete you can simply delete a pointer-to-const without jumping through any const_cast hoops, though I often wish I had a way of blocking that for APIs where the callee doesn't take ownership of a const Foo*.

Is that actually a standard though? ISTR some compilers complaining if you use delete with a const pointer (sorry, this is from ages ago, I cannot recall which compiler...)

You can make a fair argument that using delete with a const pointer is a type error, after all the data can hardly be considered const if it has just been eradicated...