Nope. If you did, I'm pretty sure the EPA would shut you down. Emissions regulations aren't quite as strict for tractors as for cars and trucks, but they are headed in the same direction. I don't think it's possible to meet emissions without computerized controls. And once you've put hundreds or thousands of dollars worth of electronics on the tractor, it's hard to resist the temptation to add DRM.

I know nothing about engines and found this article a good introduction about how computer controls help reduce emissions. https://www.pitchcare.com/news-media/diesel-engine-emissions...

But it probably used : to separate the volume name from the file name.

Checked the phone book (https://en.wikipedia.org/wiki/Inside_Macintosh). As I remembered, all APIs used a volume reference number and a file name.

However, it also says (emphasis added):

”When accessing a closed file on a volume, you must identify the volume by the method given above, and identify the file by its name in the fileName parameter. FileName can contain either the file name alone or the file name prefixed by a volume name.

(note)

Although fileName can include both the volume name and the file name, applications shouldn’t encourage users to prefix a file name with a volume name.”

So ,that, sort-of, but not fully, confirms your statement.

I don’t remember ever using a path like that, and wonder what the OS did with those volume names: ignore them, and use the volume reference number to determine the volume to use, allow them to override the volume reference number, or check them against the name of the volume with the reference number?

Actually, agua is feminine. But it takes el instead of la because it starts with an accented a. The common language-learning advice is "Don't learn the genders of nouns; learn the articles that go with them." But it doesn't quite work in Spanish.

I assume that some site has hostgator-related links with two slashes instead of one. Due to the two slashes, the GoogleBot doesn't realize that it's indexing their own results pages.

Go provides straight-ahead, blocking-is-OK concurrency. GCD provides callback-based concurrency, like node.js, but with several worker threads instead of just one.

On the other hand, there are firewall administrators who do extensive filtering on ports 80 and 443 and allow other outgoing traffic by default. We get pretty ticked off when some thermostat, credit card machine, or postage meter decides to send its bizarre and undocumented data stream over port 80 or 443 in the name of firewall compatibility and therefore becomes incompatible with our firewall. (Yes, we can put in exceptions for those machines' IP addresses, but if they didn't try to use HTTP ports, they would Just Work.)

Let me tell you that where I live, networks like yours are the minority. Sadly, when 99% are going for the 80/443 are free and the rest forget-about-it, I'm going to "tunnel" my stuff over 443 because I don't like being called 10-20 times a day with "nothing works"-type complaints that I can't properly remotely debug because obviously, nothing works.

Edit: my "tunnel" is actually WebSockets over SSL on port 443. Not sure if you guys would block that as supposedly this should be no different from, say, gmail or facebook traffic.

Yes, websockets should be fine. Making my proxy support websockets was a little difficult, but I think it works now.

If the traffic is compliant with the protocols that ports 80 and 443 are supposed to use, it's not a problem. The one that really gets me is a thermostat using a proprietary protocol over port 443. This protocol is one where the server sends the first data over the connection; in TLS the client always sends first. So my proxy was just waiting for the TLS client hello while the thermostat was waiting for its server's message. If the thermostat had sent something first, the proxy could have seen that it was invalid TLS and passed it through; instead it deadlocked.

That is the OP's main point, except turned around. He was measuring progress by results, not by effort expended, and saying that it takes exponential effort to reach linear results.

But considering that the total amount of scientific knowledge is limited, linear progress will find "everything" in a manageable amount of time. Of course we don't know how big the percentage of our total knowledge is, but it's quite possible that we are already getting close to know "everything".

The singularity doesn't promise certain invention (for example it's possible that there is no and will never be a way to go faster than the speed of light) it only promises exponential growth which will bring the "end of science" into the foreseeable future. So if we found maybe 80% of all physics in the last 200 years, with linear progress we would reach the end of physics in 40 years.

It works when unions are used correctly. If they are used to deliberately subvert the type system (e.g., put in an int, get an array of char out) it doesn't work. But C has so many other ways to subvert the type system that there's no need to do that.

Probably about the only place you'll see them used like that is in the code produced by web2c in compiling TeX. Knuth used variant records a lot to get around Pascal's type safety, and they get translated to unions.

That code is not valid according to the C standard, so there is no guarantee it will work anywhere. In particular, many modern compilers have optimizations that would break that code. I would be a little surprised if modern web2c still uses unions this way and gets away with it.

The only standard compliant way to, say, convert a float to an int is to use memmove:

  uint32 i;
  float32 f;
  i = 0x80000000;
  memmove(&f, &i, 4);

I finally managed to track down the definition of memoryword from texlive-20130530-source/texk/web2c/texmfmem.h. Here it is:

        typedef union
	{
	#ifdef TeX
	  glueratio gr;
	  twohalves hh;
	#else
	  twohalves hhfield;
	#endif
	#ifdef XeTeX
	  voidpointer ptr;
	#endif
	#ifdef WORDS_BIGENDIAN
	  integer cint;
	  fourquarters qqqq;
	#else /* not WORDS_BIGENDIAN */
	  struct
	  {
	#if defined (TeX) && !defined (SMALLTeX) || defined (MF) && !defined (SMALLMF) || defined (MP) && !defined (SMALLMP)
		halfword junk;
	#endif /* big {TeX,MF,MP} */
		integer CINT;
	  } u;

	  struct
	  {
	#ifndef XeTeX
	#if defined (TeX) && !defined (SMALLTeX) || defined (MF) && !defined (SMALLMF) || defined (MP) && !defined (SMALLMP)
		halfword junk;
	#endif /* big {TeX,MF,MP} */
	#endif
		fourquarters QQQQ;
	  } v;
	#endif /* not WORDS_BIGENDIAN */
	} memoryword;

Once you sort through all the ifdefs and typedefs, it boils down to a union of a float (glueratio), an int32 (integer), a pair of int16s (twohalves), and a struct of 4 bytes (fourquarters). When TeX creates its memory dump file, it does it all in terms of the bytes in the fourquarters struct. (And I think there are other times that it does similar things.)

This may very well be undefined behavior, but it seems to work when compiled with GCC anyway. Thankfully gc isn't such crazy code as this.

C99 6.5.2.3.5 seems to suggest that non-overlapping union members could break conforming code:

``One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. Two structures share a common initial sequence if corresponding members have compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members.''

Which part of the C standard would forbid type punning a uint32 to a float32? http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_283.htm suggests that C89 explicitly allowed this, C99 at first glance did not, and was errata'ed to make it clear that this is still allowed. C11 seems to have the same verbiage.

Devil's advocate example:

  union hack { int x; float y};

  int foo( int *i, float *f)
  {
     *i = 3;
     *f = 42.0;
     return *i;
  }

Aliasing rules say foo need not read from that int pointer, may switch the order of the write to f and the write to i, and can assume that foo returns 3, so

  struct hack h;

  foo( &h.i, &h.f);

might return 3 or something else. I think that last call introduces undefined behavior, but only becuase of the definition of foo that the writer of that call might not even have the source for.

But of course, that is an "you shouldn't do that" edge case. One could also claim that the corrigendum doesn't apply because foo doesn't "use a member to access the contents of a union".

Sure, but that's an aliasing issue, not a type punning issue. I agree that the code you cite there is a violation of the aliasing rules, and will not work "as expected" on modern compilers unless one does the equivalent of gcc's -fno-strict-aliasing.

And I agree that the corrigendum doesn't apply in this case. Once you hand different-typed pointers to the same memory to people, whether via union or just casting pointers, the aliasing rules will up and bite you.

That's why I said "not always". Here is an example which will print different result if you define

  #define union struct

Here you go:

  #include <stdio.h>
  union U { char a; char b; };

  int main() {
    U u;
    u.a = 13;
    u.b = 10;
    printf("%d\n", int(u.a));
    return 0;
  }

I don't think a and b need necessarily overlap. I think the types need to be more like this:

    struct A {char a;};
    struct B {char a;};
    union U {struct A a; struct B b;};

Probably because a lot of Go users _are_ generics-hating curmudgeons :-) (even though the team aren't)