> This feature is documented under the -f option of the export built-in command. The implementation detail of using an environment variable whose value starts with "() {" and which may contain further commands after the function definition is not documented, but could still be considered a feature.
This undocumented implementation detail is also a limitation on the use of regular environment variables, and should be documented. When reading documentation about a mechanism, I expect that special magical strings which change behaviour of the mechanism are clearly documented. If such documentation had existed, someone might have noticed it and guarded against it.
> Assumedly programs like apache filter out environment variables properly. But unfortunately, in the validation of input data, they fails to validate correctly input data because they don't expect that data starting with "() {" will be interpreted by their bash child processes. If there's a bug, it's not in bash, but in apache and the other internet facing programs that call bash without properly validating and controlling the data they pass to bash.
It isn't easy to validate and control data against an unknown magical feature in one of many possible shells.
> But on the other hand, it is free software and not difficult to check the source to see as the nose in the middle of the face, what is done. When reusing a component with missing specifications and lacking documentation, checking the source of the implementation should be standard procedure, but it has clearly not been done by Apache or DHCP developers.
I think the shell is specified in POSIX/SUS. Checking the source of all possible open-source shells would be a huge job. I don't know how they should check source code of the closed-source shells. I don't blame them for using the environment variables according to available documentation.
I wish for a standard #once directive. It should be very simple to implement, increase preprocessing speed and reduce the size of visually disturbing boilerplate in header files.
A combined REPL and editor for C# looks useful. I will try it next time I have some spare time.
The name is confusing. A C shell already exists (http://en.wikipedia.org/wiki/C_shell). An alternative name could be CSharpShell. Btw, while googling that name, I found CsharpRepl, which seems to be a somewhat similar tool.
> Most C++ code uses switch frequently, usually without taking advantage of fallthrough.
I am not so sure about this. Thinking back on my uses of switch in C and C++, I am not able to remember using switch without taking advantage of fallthrough. Maybe I am just not a typical C++ programmer...
So his political view made him unsuitable for a job. I am really surprised about this from a company and a foundation I associated with openness and concern about freedom.
You could add the option to filter by programming language, to avoid seeing repositories using languages the potential contributor doesn't know or has no interest in.
> "What happens is that variable i is converted to unsigned integer." No: 'long i' is converted to 'unsigned long'.
Actually, unsigned long is an unsigned integer. He didn't write unsigned int.
> "Usually size_t corresponds with long of given architecture." No: For example, on Win64 size_t is 64 bits whereas long is 32 bits.
"Usually" is the keyword here. He could have said "Usually size_t has at least the same amount of bits as long" and it would be better related to the referred rule.
As a non-designer, I don't have the insight to understand why black text makes a site look outdated and trashy. As a user of web pages, I think that black text makes a site look professional. It also makes it possible to read without hurting my eyes. The light gray suggested in the article is very difficult to read and gives me the impression of a badly designed site. Just my opinion as a non-designer.
Qusetion five: "What does the expression SCHAR_MAX == CHAR_MAX evaluate to?" should be undefined exactly because char type can be signed or unsigned (as admitted in the explanation). If the question is about specific ABIs, it should be stated in the question.
While I understand that a highly customized vim could reduce the number of keystrokes, I think it also makes some tasks more difficult. If using several different computers you must make sure all your cusomizations are copied to the relevant vim installations. Otherwise, your optimized solutions might end up being counterproductive when you use an installation that doesn't have all your newest customizations. Also not that everything in vimrc should work in all the operating systems you are using, including Windows.
Another issue to note is that there is a solution to many of these things hidden somewhere inside vims huge and flexible command set. You just have to learn it:-) Every time I look in to a vim tutorial, I learn something new that can save a lot of keystrokes.
A Hacker News for Europe would be great. A lot of the stories on HN are very USA-centric.
Currently it looks like Hackful focuses on the UK, especially London. Lets hope it expands to cover all of Europe.