It seems that the intent there is to make C into something a lot like C++/STL. Once you've done it once, nothing to prevent Complex types and others being builtins... but this seems to bring C further from its "portable ASM" status.

Not that I'm entirely sure this would be bad... and the struct could be just a typedef. Now all we need is operator overloading, which is also a C++ism. Maybe a C++ minus the type-strictness, and minus all of the automatic copying. and the templates.

I've seen this done in serialization formats, but never seen it actually done in a program.

So you're saying you want native-size-word (int) followed by the string chars, so you'd malloc(strlen+4) for the dynamic string, and then in the reader read the first 4 bytes and set the ptr to stringPtr=basePtr+(void *)(sizeof(size_t)). It just doesn't feel natural in C as we know it. But then again, I'm sure they could have defined it to be natural. it would be an implied struct.

I meant that if you were to actually pass the struct as not a structptr, but as the 2 values themselves. After all, you could optimize for fewer regs, or fewer memory accesses. Pointer indirection used to be considered a problem. Albeit not anymore.

Yes, that would be an ABI change, but this was back when they could choose the ABI as they wished... so we can throw many current assumptions of ABI out the window.

I'll admit to not being an assembly programmer, but for one, I was referring more to what they would have done back then... when register renaming wasn't available. Nowadays many programmers don't care about cycle counting... I know I haven't had to. Writing in perl or C++/STL leaves me too far away from the metal to even know how many cycles I'm wasting.

But since the question is one of yesteryear, lack of regs could be a question. And I was under the impression you weren't supposed to use esi and edi as tmp stores or as the output of an expr. They're ptrs into stack and data-area, respectively.

The real problem with the addr+len approach is that now every string becomes a struct, or a structptr.

This means that when passing a string to a function, either the string takes up two register/stack slots, or you're passing around a const-ptr (but the contents of the struct are not const), which means one more memory access due to pointer indirection.

x86 and the PDP-11 are register-starved. the x86 has 8 registers, with 4 or 5 available as general-purpose registers.
The PDP-11 was similar with 8 registers total as well.

But the meat comes out so tender afterwards... and the horse-beaters do it all for free!

I don't know about the GP, but myself, I am using elinks + console-mode. I doubt I'm the only one... albeit there are few.

I do it for more a choice than b/c I don't have GUIs available.

There's also various cities that have passed regulations about grey-water, that then means you can't clean your car in the driveway anymore.

Apartment complexes that strictly disallow you to do car-repairs in the parking-lot.

Office buildings and strip-malls that do the same thing (even if there is an AutoZone/whatever in that mall).

I've been accosted before for taking 5 minutes to change out a burned headlight bulb... b/c I was doing it at an office park waiting for my flatmate to get out of work.

Saying that they cut the copper to prevent others from using it... is somewhat unfair.

Last time I was involved in renting a building, when we moved out we were REQUIRED to cut the cable, by zoning regulations and our lease agreement. This was in Santa Clara, CA.

It's considered public exposure, give or take... b/c you were pissing on a tree, somebody might have come up alongside you and saw your dong.

And yes, it does happen.

Factually incorrect. Before being [re]elected as Governor, he was the State Attorney General. Since this was a case before the STATE court, he would have been involved, if only as the superior of the actual DA or ADA involved in the case.

Notepad, which is so often used by the technically non-clueful. Of which, I seem to work with a few.

Of course, you should use a real editor. This somehow doesn't prevent people from using notepad b/c they don't know better, or using vim but not knowing HOW to use vim and still we lose all indenting.

and I never said you needed a special editor for XML. Not even that you need one for JSON or YAML.

Pretty printing isn't MANDATORY for XML... which is really the point. With it NOT necessary, means you can fuck up the whitespace and NOT break the data. That's what I need.

I use JSON (and occasionally YAML), but only for data interchange formats where I don't expect a human to need to modify it.

Yes, I am aware that JSON and YAML are largely related. And I a few times tried to write up files in JSON, just as a mockup of my intended data structure. Yes, I used a real editor with proper tab indenting. It still got to be pretty unreadable. I use Data::Dumper whenever I want the data format to be as explict as possible, but only for debugging.

But it's so much worse than that. XML doesn't NEED the indenting, so if some tard uses wordpad or notepad or something equally stupid to modify the file, he CANNOT mess it up.

Yes, you want to assume that only Real Programmers will be modifying your data. I had to unlearn that theory, and I'm working for a very well known internet company (I'd rather not say, albeit I may have left clues [or even spilt the beans] in other comments).

In particular, I had used XML for a human writable/readable data file (the same project I had tried to use JSON for), and was told a month ago that I had to write a GUI editor for it, or it just wouldn't get used. That and I've watched a few QA contractors and simply how little actual programming they know.

XML also gets a lot of flack b/c it is typically 'too hard to parse' whereas YAML and JSON are intended to be trivially parsed into a natural tree format... On the other hand, I found a perl module (XML::TreePP) that makes XML just as simple to manipulate.

Great for human readability. Terrible (due to some python-like indent rules) for humans to add content to.

Meanwhile, XML might not be quite as nice as YAML for reading, but it is easier to figure out where you made a mistake, assuming you're pretty printing it (but the best thing is that pretty printing it is unnecessary).