The variant found by OP is apparently the very last option that my tool generates. These days, Firefox is a bit boring (okay, okay, I'll admit it's a good choice for security) and translates these at the first opportunity. Even hyperlinks are translated on hover in the 'status bar' (if we can still call it that). For mobile users, this is what it shows when you paste one of those addresses in Firefox: https://snipboard.io/kbLTso.jpg
Octal is a great way to mislead both human beings and software, and I kind of hope it gets removed by browsers as a result of this new attention. It’s one of those things that isn’t productive or useful in any way in our modern era and serves only to complicate with no benefit in return.
I would refuse any PR that used octal unnecessarily, and I generally ask people to use chmod plus-addressing rather than octal where possible, so that there’s a lower risk of math errors and a higher chance of good review.
This is funny for me to read because I converted a bunch of constants for file permissions to octal values in the Linux kernel because they're harder to read and there's multiple ways of arriving at the same value.
You wanna look up what a constant is and you find
#define S_IRUGO (S_IRUSR|S_IRGRP|S_IROTH)
or you could see 0444 and immediately know what it means.
I agree in cases where you're modifying existing permissions it's much better to do a `chmod u+w` than to replace the whole thing with octal. When you're defining permissions at the time of creation though, everyone can parse 0644 at a glance.
a=rX,u+w isn't so bad but I don't know if I'd prefer it personally, in code where you can't use chmod syntax I'm definitely preferring octal.
Oh, I didn't know what X did and made assumptions.
If you split file permissions into two halves - defining the initial permissions / modifying something that already exists - I can see how it makes sense to do both with the same syntax since modifying existing permissions is worse with octal.
Doesn’t this just highlight that php development ecosystem doesn’t value quality much? What even is a “file” in context of a web request? What about dependencies or logic defined in other files?
This is just bizarre, I can’t see a sane codebase where this would be preferable to going on GitHub and pressing “.”
> Doesn’t this just highlight that php development ecosystem doesn’t value quality much?
As opposed to which web development ecosystem exactly? The only web development ecosystem with overall decent quality software that I could come up with is Java, and their understanding of quality is... enterprise-y.
Give me a mature PHP framework over a NPM dependency tree, python web framework, or ruby on rails any day. At least when looking for 'quality'. Relatively.
I agree with these points although going back to the grandparent comment, the value of being able to show the source code of a controller with these frameworks by appending a query string is close to zero.
On the contrary, doesn't it highlight that the PHP development ecosystem values simplicity? That is, a simple application (which this is) can be contained within one file, rather than something requiring several folders, dependencies, and an 'init' command?
I don't understand your criticism and I suggest you might not either.
The irony of thinking files and folders are too much for simple app and also praising a feature that is in direct relation to php’s MO of conflating codebase folder structure with requests’ path.
Edit: this reminds me, I was like this too at the beginning of my dev career, I also was completely in favor of this supposed “simplicity” of php, only much later, thanks to hickey’s nice talk I realized that I was confusing simplicity with ease.
Sorry, I don't understand your first point, even after reading it several times. I think I might have inferred what you meant by looking at the second (edited in) point, but I'm not sure.
Are you suggesting that it is bad that PHP applications often have a request path that relates to the folder structure?
In other words, are you suggesting that simplicity means an application should not have a request path that relates to the folder structure?
To give an example, are you saying it's a bad thing that example.com/profile/ loads /profile/index.php, rather than passing /profile through a single controller function to identify what code should be responsible for handling it?
The first approach actually seems pretty straightforward paradigm and it's what most new programmers would expect. Adopting a MVC/routes method is more complex and arguably overkill for a simple application.
If that is what you are contending, it should be said that PHP does not require this approach. Although it is often a preferred approach, because it doesn't depend on additional web server configuration.
I’m not suggesting, I’m saying that conflation is mother of confusion. Conflating request path with file path is not a great idea, especially for new developers that get a mental model of how web apps work that is completely irrelevant for the rest of their careers.
There's plenty of large PHP projects that adopt this paradigm. Is it really fair to say it will be completely irrelevant for the rest of their careers?
Also, let's not lose sight that this arises in a context of criticism of the model adopted for programming a simple form. This is just a simple one page form. More complex or abstract paradigms or design patterns is overkill.
You replace your “init” command with some VIMming of your nginx configuration.
The next on the line is that PHP doesn’t even need anything like version control because you can just copy files over SFTP.
PS: if your project is simple enough to fit in a single file I would argue that most of the time you may use absolutely anything (including a Google Sheet) and you would be equally happy with the results.
This program, "ip4dec", converts lists of IPv4 addresses to decimal and prints them as unsigned integers. Wrote this while experimenting with storing domain->ip mappings in a trie, such as https://github.com/tlwg/libdatrie
This program, "ip4dec", converts lists of IPv4 addresses to decimal. Wrote this while experimenting with storing domain->ip mappings in a trie, such as https://github.com/tlwg/libdatrie
It can't only be that, or 127.1 would not work. It is doing some parsing beyond just calling a parseInt on each of them in order to recognize domain names and use name resolution rather than directly putting the bytes in the IP header. That must be why 0x9000000.-16250872 doesn't work (if negative worked, that should also resolve to 8.8.8.8).
I looked into this a while back, IIRC BSD added the "omit zeroes" as a nonstandard convenience feature and other OSes copied it. I'm far afk for I'd find my notes on this.
It's not "omit zeroes". It's, "represent the last three octets with just one integer".
127.256 is valid, and would be equivalent to 127.0.1.0. The last integer can be up to 16777215 (2²⁴-1).
Similarly, if you instead include three groups of integers, the first two represents one octet each, and the last represents two. 127.2.256 is equivalent to 127.2.1.0.
https://lucb1e.com/randomprojects/php/funnip.php?ip=8.8.8.8
The variant found by OP is apparently the very last option that my tool generates. These days, Firefox is a bit boring (okay, okay, I'll admit it's a good choice for security) and translates these at the first opportunity. Even hyperlinks are translated on hover in the 'status bar' (if we can still call it that). For mobile users, this is what it shows when you paste one of those addresses in Firefox: https://snipboard.io/kbLTso.jpg