Asooka
Joined 1,744 karma
- Back when strncpy was written there was no undefined behaviour (as the compiler interprets it today). The result would depend on the implementation and might differ between invocations, but it was never the "this will not happen" footgun of today. The modern interpretation of undefined behaviour in C is a big blemish on the otherwise excellent standards committee, committed (hah) in the name of extremely dubious performance claims. If "undefined" meaning "left to the implementation" was good enough when CPU frequency was measured in MHz and nobody had more than one, surely it is good enough today too.
Also I'm not sure what you mean with C successor languages not having undefined behaviour, as both Rust and Zig inherit it wholesale from LLVM. At least last I checked that was the case, correct me if I am wrong. Go, Java and C# all have sane behaviour, but those are much higher level.
- Similarly I wish open-source devs who wish to extend and improve existing tech take a page out of Microsoft and do their Embrace, Extend, Extinguish tactic. Like: "Here is my new D-Bus implementation, it has a couple of extra bells and whistles, which I need for my project, and is faster. Oh I have added more security, you don't have to use it right now, but some services will require it. ... Security is now mandatory. ... The protocol is now called Wire and if you need D-Bus, you can run this legacy translation layer. ... The legacy translation layer is no longer installed by default, but will be maintained for those who need it. ... It has been 30 years since anybody has needed D-Bus, we are no longer maintaining the translation layer."
Which is kind of what OP is doing, but less directly inflammatory. I wish him all the luck regardless.
- One more thing: D-Bus has the concept of generic services which can be automatically started, e.g. org.freedesktop.FileManager1. When you send a command to that service, the file manager will be started if it is not already running. However, there is no mechanism for the user to select which file manager to start, so if you happen to have both KDE and GNOME installed you have a 50:50 chance of launching dolphin or nautilus. See for example: https://unix.stackexchange.com/questions/778028/set-a-specif... . It truly boggles the mind.
- It does seem needlessly complex. I think a better idea is to just have a type that is a pair of pointer-sized words. That pattern crops up again and again - context pointer and function pointer, array and its size, memory allocation and effective size, etc. The problem with having both pieces in separate variables is that it is very easy to lose track of what is where. If you have it in a single bundle it is a lot simpler to use. The exact design needs a lot more consideration for sure, because I would like something simpler than writing anonymous structs everywhere (which I can already do), but at the same time flexible enough for most use cases.
- In that case you can use bit fields in a union:
Since both members of the union are effectively the exact same type, there is no issue. C99: "If the member used to access the contents of a union is not the same as the member last used to store a value, the object representation of the value that was stored is reinterpreted as an object representation of the new type". Meaning, you can initialise keyvalue and that will initialise both key and value, so writing "union slot s{0}" initialises everything to 0. One issue is that the exact layout for bit fields is implementation defined, so if you absolutely need to know where key and value are in memory, you will have to read GCC's manual (or just experiment). Another is that you cannot take the address of key or value individually, but if your code was already using uint64_t, you probably don't need to.union slot { uint64_t keyvalue; struct { uint64_t key: 32; uint64_t value: 32; }; };Edit: Note also that you can cast a pointer to slot to a pointer to uint64_t and that does not break strict aliasing rules.
- I never interacted with any of that, to me Perl was always "Bash with text processing built-in and no string interpolation pitfalls". I reach for it when I need to write one to two page long utility scripts. Python is too willing to deprecate features (plus the whole 2 to 3 fiasco burned me badly), so I only use it for things I know I will maintain. Perl is for writing a shell script that will run unchanged in perpetuity.
- Back when those machines existed, UB meant "the precise behaviour is not specified by the standard, the specific compiler for the specific machine chooses what happens" rather than the modern "a well-formed program does not invoke UB". For what it is worth, I compile all my code with -fwrapv et. al.
- There really ought to be a subset of C that lets you write portable assembly. One where only a defined set of optimisations are allowed and required to be performed, "inline" means always inline, the "register" and "auto" keywords have their original meanings, every stack variable is allocated unless otherwise indicated, every expression has defined evaluation order, every read/write from/to an address is carried out, nothing is ever reordered, and undefined behaviour is switched to machine-specific behaviour. Currently if you need that level of control, your only option is writing it in assembly, which gets painful when you need to support multiple architectures, or want fancy features like autocomplete or structs and functions.
- Reads like paid copypasta. In the unlikely case you're sincere, have you tried testosterone blockers medication? I checked out SLAA (SA and SAA yielded no results) and while learning to control yourself is nice, why should you have those urges in the first place if they are making your life miserable. I find most porn kind of boring and even icky. I would never get tired of seeing pretty women (especially naked), but porn itself is kind of meh.
- Mass surveillance is far more damaging. Also there are several porn block solutions on offer for parents to install on their children's devices. There is absolutely zero need for the government to be regulating mass surveillance on everyone to block porn for children. We are replacing the damage caused by porn on a small handful of people who are predisposed to get addicted and got exposed to it at a young age due to bad parenting, with damaging all of society with mass surveillance, which is not even guaranteed to stop kids from seeing porn.
- The best option for me would be to release it in whatever format preserves the most of the original colour data without modification, then let the viewer application apply colour grading. Give me the raw renders in a linear 16bpc colour space with no changes. Sadly, I don't think we have digital movie formats that can handle that.
- I do believe the C standards committee got it completely backwards with regards to undefined behaviour optimisations. By default the language should act in a way that a human can reason about, in particular it should not be more complicated than assembly. Then, they can add some mechanism for decorating select hot program blocks as amenable to certain optimisations[1]. In the majority of the program the optimisation of not writing a single machine word to memory before calling memcmp is not measurable. The saddest part is that other languages like Rust and Zig have picked all this up like cargo cult language design. Writing code is already complicated enough without having to watch out for pitfalls added so the compiler can achieve one nanosecond faster time on SPECint.
[1] As an aside, the last time I tried to talk to a committee representative about undefined behaviour optimisation pitfalls, I was told that the standard does not prescribe optimisations. Which was quite puzzling, because it obviously prescribes compiler behaviour with the express goal of allowing certain optimisations. If I took that statement at face value, it would follow that undefined behaviour is not there for optimisation's sake, but rather as a fun feature to make programming more interesting...
- If you can afford a function call, you can just borrow LISP's names for these functions, as these are literally LISP lists, e.g.:
May you write much LISP in Python.def cons(head, tail=()): return (head, tail) def snoc(pair): ''' Decompose (kind of) pair, transforming () to None, (). So you can write slightly clearer code: pair = cons(head, tail) head, tail = snoc(pair) ''' if pair: return pair else: return (None, ()) def car(pair): return pair[0] if pair else None def cdr(pair): return pair[1] if pair else () def cons_iter(stack): ''' Iterate stack, e.g. for item in cons_iter(stack): ... ''' while stack: head, stack = stack yield head - They could have at least put the types on the left. Types on the right are a good fit for mathematics, where everything is single-letter symbols, so your eyes do not have to go across the line to see the entire definition, but in programming function definitions often span an entire line on screen, so the most important information should be the first thing shown! Also most programmers do not have formal education in mathematics, so the whole "function : domain -> image" syntax is foreign to them. We really should strive to democratise programming for everyone, rather than make it isolated to a small clique of "properly" educated white men who all went to the same university.
The type of a variable and the return type of a function are the most important pieces of information regarding those, so they ought to be on the left. It also fits the data flow going right to left (i.e. how the '=' operator works). C's type declarations can get pretty gnarly, so there is definitely room for improvement there. I would say Java (and C#) got it as close to perfect as possible.
If you want to replace C/C++ you should make your language look as inviting as possible to users of the old one. I truly think this strange fetish for putting types on the right is what gives C programmers the ick when they see Rust for the first time and is hampering its adoption.
- That's a problem within the EU already, no need to travel across the globe. A Bulgarian family moving to Germany would face that exact problem. I hope we can eventually lobby the EU to recognise and allow gendered surnames across the Union, since it is part of our language and culture.
- Because all the heavy number-crunching code is already written in C or Rust or as CUDA kernels, so the actual time spent running Python code is miniscule. If it starts to matter, I would probably reach for Cython first. PyPy is an extremely impressive project, but using it adds a lot of complexity to what is usually a glue language. It is a bit like writing a JIT for Bash.
- >The thing is, after years of doing it, learning new languages, making friends all over, and then leaving knowing you might not see them again for ever or for long stints, you start to feel the yearning to be able to connect with people on a deeper level.
A rolling stone gathers no moss, as they say.
I am thinking that since an option starts with 2 bytes and everything must be padded to a multiple of 4 bytes, we can add 16 bytes to the packet, which would hold 7 extra address bytes per source and destination, giving us 11 byte addresses. ISPs would be given a bunch of 4-byte toplevel addresses and can generate 7-byte suffixes dynamically for their subscribers, in a way that is almost the same as CGNAT used today but without all the problems that has.
Most routers will only need to be updated to pass along the option and otherwise route as normal, because the top level address is already enough to route the packet to the ISP's routers. Then only at the edge will you need to do extra work to route the packet to the host. Not setting the option would be equivalent to setting it to all 0s, so all existing public hosts will be automatically addressable with the new scheme.
There will of course need to be a lot more work done for DNS, DHCP, syntax in programs, etc, but it would be a much easier and more gradual transition than IPv6 is demanding.