Live data from Hacker News

“C is how the computer works” is a dangerous mindset for C programmers

words.steveklabnik.com

311–320 of 387 posts

Re: “C is how the computer works” is a dangerous mindset for C programmers

#311
post #305

Earlier quoted context omitted.

Embedding Python 2 inside of Python 3 (or vice-versa) is not very hard to do on Linux. Simply `dlmopen` the .so in a new linker namespace and write a little bit of bridging code to interface the two object layouts. Python has a very rich runtime, so there are some tricky problems to solve if you want this to be perfect. e.g., circular references between the GCs. However, there are simplifying assumptions that can dra…

> Embedding Python 2 inside of Python 3 (or vice-versa) is not very hard to do on Linux. Simply `dlmopen` the .so in a new linker namespace and write a little bit of bridging code to interface the two object layouts. Where can I pip install this from? Or is there a reason that none of the huge numbers of python users delaying their transition as much as possible until all their libraries were updated built it?

> Where can I pip install this from?

A couple of signatures have changed, but the general approach looks like: https://gist.github.com/dutc/eba9b2f7980f400f6287 or https://gist.github.com/dutc/2866d969d5e9209d501a

The above will launch ("embed") a Python 2 or Python 1.5 interpreter from within a Python 3 interpreter. If you use `dlmopen` and `LM_ID_NEWLM`, the guest interpreter will have its own linker namespace. In other words, the guest interpreter (and any DSOs it opens) will be totally isolated from the host interpreter.

The above shows the use of `PyRun_SimpleString`. Since `PyRun_String` accepts a `PyObject* globals` and `PyObject* locals`, you could build a very basic bridge in I've given a many talks about this at various Python and PyData conferences. (I've mentioned it a number of times on HN, both in response to complaints about the Python 2→3 transition and in response to comments like yours suggesting this solution to that problem.)

Though presented as a joke, the approach could be made to work with some effort. I can't speculate on why no one has ever followed-up on it, and I can't speculate on why the Python 2→3 transition has been so difficult for some users. Perhaps in some places, financial or organisational arguments are more influential than technical arguments.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#312
post #262

Earlier quoted context omitted.

I'm just going to respond to the top part of your post, as it's at least somewhat relevant rather than being a disconnected rant about the kids censoring you. > I am just hooking linux kernel calls, I will never take JS for this. Pure C. Why not? Hooking native code in other languages is already fairly common: http://www.cycript.org > Valgrind? I have a header with #define MALLOC/FREE/REALLOC/... which returns larger…

It is easy for engineers, because engineers are trained to make things correctly even when that is inconvenient. Engineers make bridges that don't collapse (unless not maintained for decades) and planes that don't fall from the sky (unless overruled by management). By the evidence, it is not easy for people who just can't be bothered to take the time to make anything correctly. So, there are languages for engineers t…

> it is not easy for people who just can't be bothered to take the time to make anything correctly

Laziness may make the problem more likely, but even a disciplined team working on security-critical software can make mistakes[0].

[0] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0777

Re: “C is how the computer works” is a dangerous mindset for C programmers

#313

Earlier quoted context omitted.

Rust has both static (based on monomorphization, similar to a template instantiation in C++) and dynamic (based on vtables, similar to inheritance in C++) dispatch: https://doc.rust-lang.org/1.8.0/book/trait-objects.html . Both Rust and C++ are moving in the direction of encouraging static dispatch.

It may be similar, but it is implemented very differently, in exactly the "so can always work on unmodified structures" sense. Trait objects are a double pointer: one to the vtable, and one to the data. C++'s dynamic dispatch uses a single pointer to a structure that has the vtable and the data. The memory layouts are very different.

"The memory layouts are very different."

Clarification: the memory layouts between C++ dynamic dispatch and rust dynamic dispatch are very different.

Rust imposes no requirements on the structure layout, whereas C++ adds some magic data. The magic data means it's awkward to make C++ do dynamic dispatch on a C struct pointer; but rust can do dynamic dispatch on a C struct pointer with no problem.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#314
post #290

Should I learn Verilog to understand “how the computer works”?

In short, no. Verilog is very nearly a general purpose programming language, with some syntactic sugar for doing userspace/green/lightweight threads (that it confusingly calls processes). It is used to model digital hardware, but the language itself doesn't really give you any insight into how to construct those models. Creating the model is still up to you.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#315

Earlier quoted context omitted.

"There's no "bitcast" operator that changes the type of a value without affecting the value." Technically, you are supposed to use unions for that, though it's a pain. The PostgreSQL codebase is compile with -fno-strict-aliasing so that a simple cast will get the job done, but obviously that's technically out of spec.

Or better, memcpy.

Which in this case may or may not copy memory. You're only able to express changing the meaning of some specific bytes by moving them which is the contrary of what you meant. Sure you're not moving things because normally the compiler will (and does) optimize, but you must say that you need the bytes to be copied.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#316

Earlier quoted context omitted.

The "right tool for the job" is a myth (EDIT: exaggerating; clearly it applies in some cases). Languages don't work together very well, so you need huge, thick boundaries between them, such as serialization/deserialization. Data types don't match up, GCs require special data formats and don't line up with the GCs of other languages, other runtime weirdness, etc. At minimum, you need lots of copying/transformation of…

To be precise, C does not have a defined ABI (the spec goes out of its way to avoid this). Platforms (OS+Arch) define a C ABI for their own tools. Since this ABI is required to interop with the OS APIs, this will usually become the de-facto standard for the platform. This might seem like nitpicking but it's an important distinction because you can't assume that C data structures can be passed between different platfo…

What is the right way to say that without sounding too pedantic every time? "Most platforms define a stable C ABI"?

Re: “C is how the computer works” is a dangerous mindset for C programmers

#317

Earlier quoted context omitted.

But it shouldn't require a full compilation. The ultimate result, given the slow compile times of c++, is that you cannot know in your editor if your code is correct.

The IDEs I have used, or IDE-ified editors, run compilation ("indexing", or whatever) in the background to make this work.

Maybe you want to share which IDEs you've been using? It sounds like a wonder if there is one that can handle C++ in a way comparable to, say, IntelliJ for Java, or VSCode for TypeScript.

My experience is frankly more that the usual IDEs I know of can't even handle syntax coloring 100% correct when it comes to C++…

Re: “C is how the computer works” is a dangerous mindset for C programmers

#318

Earlier quoted context omitted.

C++ should only be used as a last resort. It's complex, development is slower, the tooling is poor, some universities have stopped teaching it. It's very hard to hire good C++ devs, and they are typically not cheap. I manage a c++ team btw. Our app has to be fast.

What are you comparing it to? I think C++ tooling is fairly decent. (By the way, what do you work on?)

I find modern c++ tooling to be great compared to even 10 years ago. I love the language. Between it and python I stay very busy with both.

Re: “C is how the computer works” is a dangerous mindset for C programmers

#319

Earlier quoted context omitted.

Actually, the guideline I've heard is that memcpy should be used, since memcpy has the magic property of copying the bytes without affecting the destination type. Unions are only legal in C99 and newer (although C99 erroneously includes this in its list of undefined behavior--this was fixed in C11); C89 and any version of C++ don't permit this behavior.

I keep hearing this rumor, but C99 did not erroneously include unions-as-type-punning in a list of undefined behavior. The normative language is unclear, but clarifications were added1][2]. 1: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_257.htm 2: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm

The parent comment seems to be saying that C99 does allow type punning with a union, with an explicit clarification as you say. In C89 it was ambiguous and in C++ it is explicitly disallowed (you are supposed to use memcpy).

Re: “C is how the computer works” is a dangerous mindset for C programmers

#320

Some time ago, I saw an article that described a very crazy hypothetical architecture that still fits the C standard and uses the undefined behaviors in various insane ways. It was named like "Computer platform from hell" or so. Unfortunately, I was not able to find it again. Does anyone know about something like that? I think that the hegemony of C for low-level programming is harming us significantly because it put…

The Death Station 9000, designed by the Top Men from highly rated government contractors, built to meet and exceed all mandated specification documents.

Undefined behavior or use of anything not strictly included in POSIX.1c may result in the launch of nuclear weapons.

Post reply on HN