When a call says "Internat" in the caller ID, I answer in French and refuse to speak anything other than French. (The only people I know who are abroad and phone me by conventional means are French - all those living further afield use Skype.)
It's quite fun. My French isn't that good, but it's better than that of the average scammer.
Would dir/s produce a listing of all subdirectories of the current working directory?
Yes. A space followed by a slash would always be interpreted as a switch introducer.
Directory separators generally occur in the middle of a string, the only exception being when you want to talk about the root directory of a drive, without specifying which drive you want.
You use "C:/" to mean the root directory of C. It would be quite natural to use ":/" to mean the root directory of whatever drive is current.
It's not as if all this hadn't been done before - Microsoft were just never very good at reading manuals and learning from what had gone before. (See their totally brain-dead handling of daylight saving time.)
And indeed, it was used as a switch character in VMS too. The error however was in changing the directory separator character (which in underlying MS-DOS is still "/") to the totally unsuitable "\".
I remember the early OS/2 development kit tools, where clearly a dictat had gone out to the developers saying that both "-" and "/" were to be used as switch characters. The trouble was, they hadn't done it properly by implementing some library code, but instead each tool developer had done it himself. The end result was that some accepted "-", some accepted "/", some accepted both, and some would take one or the other, but not both in the same command line. A horrible mess.
It would not have been hard though to allow "/" to be used as a switch character to COMMAND.COM, whilst still retaining its use as a directory separator.
Agreed - it was a really stupid mis-feature in early browsers which has unfortunately been carried on and some people have become used to it and don't want to lose it. Although "Backspace" and "Go back" both contain the four-letter sequence "back", they actually do completely different things and the key should never have been overloaded to do something so totally different.
It probably seemed like a good idea at the time to the person who thought of it, and unfortunately he or she implemented it without really thinking it through. Much pain has thus been inflicted.
It's a bit like the twit at Microsoft who decided to change the directory separator understood by COMMAND.COM from "/" to "\" because he wanted to use "/" for something else. (N.B. it was only ever the command shell which required this. The underlying OS has always understood "/" as a directory separator.) It seemed like a good idea at the time, but it similarly wasn't thought through and has caused endless pain since.
10B-2 phase, which gave you all the disadvantages of TR
I'd agree it gave you some, but never quite all.
I remember walking the length of the network at my first job, carrying a terminator, unplugging each device in series to figure out where the problem was.
True, but the terminators had the advantage that they were passive devices. Once you had a good set of cables and terminators, they then very seldom went wrong. The BNC connectors had a very positive latching action and you could be confident that they would stay together. You then just had to indoctrinate users with the idea that their hands would be chopped off if they unplugged any of them.
TR on the other hand relied on very active components in the MAU, which had a high failure rate. That awful sound of an MAU continually clicking as it tried to remember how to do networking.
Basically it's what you want to run your Nuclear Power Plants, live-saving medical devices and bizarly expensive "failure is not an option" Space Equiment with.
The design intention was to produce something more reliable, but the implementation failed miserably. Those clunky connectors where you could never be quite sure that they'd mated correctly. Lost tokens resulting in periods of no connectivity. The fun game of going into your comms cupboard and unplugging each lead in turn from the MAU in order to plug in that magic reset gadget, which might then restore connectivity to your LAN. Token Ring was a train-wreck with an awful lot of money pushing it to big business.
The point of Token Ring was to have plugs and sockets where it was impossible to put the plug in the wrong way around - or the right way around.
And indeed, you could simply plug two plugs together.
I used to do quite a few joint pitches with IBM sales-folk back then, and it was amusing to watch the show as they addressed the question of which networking hardware to go for. The plot was always the same. At early meetings they would say, "IBM sells both Ethernet and Token Ring and we recommend whichever is most appropriate for each customer. We'll need to learn more about your particular requirements before we can say which one is more suitable for you." Then, several meetings later when lots of things had been discussed, but nothing really relevant to the networking hardware the message would become, "Now we've had a chance to assess your particular requirements, we can say that for your particular case Token Ring would be better." It was always Token Ring, and never any explanation as to why.
The real point of Token Ring was that IBM owned it and they didn't own Ethernet. It set out to solve a problem which didn't exist if you designed your network properly in the first place (overloaded Ethernet provides poor service to everyone) and introduced far more of its own. Like so many IBM technologies, it was a mess. Don't get me started on APPC.
No I do not want LibreOffice as it doesn't implement all of the features and sometimes has compatiblity issues from time to time that MS never has.
I love this argument. LibreOffice has compatibility issues with MS Office, and MS Office never has compatibility issues with MS Office.
Apart from the fact that the second bit isn't even true - we regularly get compatibility issues when asking MS Office to open older files created in MS Office - it's totally cock-eyed. It assumes that MS Office is filled with god^h^hates-given correctness and anything which isn't the same is wrong. A bit like MS's train-wreck of an ISO standard for office documents, which says in some places, "Do what Office does", without specifying what that is.
I've recently been forced to use LibreOffice to overcome a bug in MS Excel when importing some data. MS Excel fails to read CSV files correctly if there are embedded line breaks within a field. Faced with a supplier who lacked the technical expertise to read the CSV files directly (and not the slightest comprehension of what an encoding is), I had to read them into LibreOffice, save them in XLSX format, then read them into Excel. For some weird reason, Excel is phenomenally slow when faced with a sheet containing line breaks within a field - think 2 to 3 minutes just to open the file - but it did at least overcome the immediate problem. The supplier remains totally clueless, and with an attitude much like yours. It's not their fault for having no idea what they're doing - it's the real world's fault for not fitting in around Excel's bugs.
The inner function would be "extern 'C' char* membla(...)" and the outer one "static char* membla(...)"
No, the outer one wouldn't be static (meaning in this context, private) because it has doesn't have the static keyword. You're also introducing the complication of wondering what it would look like to a C++ program, which if we're working in pure C doesn't matter.
I've now checked the signature of memmove() and realise that the one someone posted earlier in the thread is wrong. My implementation should therefore read:
Note that they're void* pointers, not char* pointers. This is one of the areas where C and C++ differ quite distinctly.
What about C++? The linker certainly could distinguish them, but the compiler?
Now you remind me of a project a long time ago (80s?) where we had to implement a comms library in pure C to run across 5 different platforms. The trouble was, at least one of the platforms didn't have an ANSI/ISO C conformant compiler (it was only a draft in those days), and something (K&R C) guaranteed you only 6 significant characters when things hit the linker. One platform did indeed recognise only 6 characters. We got around that with a header file containing:
Erm... John Wulff? Is that you? Just seeing your nick.
Sorry, no.
That would only work on systems that have a heap and support malloc and free:D
Which are both part of the standard library, so provided you're working in a hosted environment, you're fine.
That is from a scientific point of view not inefficient.
By the specific measure of how the amount of work varies with the amount of data to be handled, you're right - it's no worse than a good algorithm. However it is still very inefficient, because it involves twice as much work for any given amount of data as a good implementation would. Effectiveness is a measure of whether or not it does the job, which it would - just not efficiently.
I bet 90% of all programmers who consider themselves 'competent' did their first memmov() implementation wrong.
I'd agree with you. However, having now thought about it a bit more (and trying to drag my detailed knowledge of C back from hither regions of my brain), I'm tempted to suspect that it's not even possible to implement a robust and correct version of memmove() without having a special relationship with the compiler. In other words, it needs to be done by the implementation. You can't (in general) compare the two pointers which are passed in unless you have extra knowledge of the particular implementation on which you are running.
My best idea for a portable - horribly inefficient - implementation so far would be to malloc a temporary buffer, copy the data from the source to the temporary buffer, then copy it again to the destination. I'm open to better suggestions.
You would need to implement memmove because, believe it or not, there are people out there who implement the libraries that memmove is implemented in.
But if you're the person implementing the standard library for a compiler then you're not constrained in the same way as someone asked to re-implement it in portable C. As various people have said, it's very hard when you can't rely on, for instance, a cast from a pointer to a long int working correctly.
If you're actually implementing the standard library function, you're not even constrained to writing it in C at all. It might well be done in raw assembler in order to make use of the maximum number of available registers.
I've known at least one implementation (Norcroft C for the Acorn Archimedes) where the two were in fact the same function. memmov guarantees not to corrupt your data due to an overlap, memcpy does not guarantee that it will corrupt your data in that case.
The only reason to have a separate memcpy is it might be possible to make it faster by skipping the checks. The ARM's block copying capabilities were so blindingly fast by the standards of the day there was no need to implement a separate memcpy.
This ability meant that the GUI gave you solid window drags when almost everything else still had you dragging an outline.
I'm now slightly boggled by my Nexus One, which must be nearly 6 years old. The battery still has no difficulty making it through the day. (Although I had to install CyanogenMod and move some of the system to a uSD card in order to keep using it.
In that entire time, I've had only 5 (maybe 6) occasions when I had to pay attention to the road.
You need to pay attention to the road the whole time. I think you mean you've had only 5 or 6 occasions when you've needed to take emergency evasive action. I'm intrigued as to where you live. I've been driving a similar length of time in the UK and would reckon on incidents such as you describe happening 5 or 6 times a year. My most recent one was when I was driving a mini-bus last week, and a lady coming out of a side road just decided she could pull across my path right in front of me. Cue emergency stop and people nearly sliding off seats.
If you aren't paying attention to the road all the time, then you won't be ready to respond when these things happen.
In fact, most the time driving home from work people are in a semi-trance like state.
Online stores and even in-person transactions often require the CVV if you swipe them, as well.
On-line stores have to ask for the CVV. It's been a while since I ran my own business, but back then we were explicitly forbidden from capturing the CVV for in-person transactions. The idea is that nobody has it but the physical card holder.
I do admit to being puzzled by this story though. If the wireless conversation between a contactless card and any kind of reader carries enough information for the card to be cloned, then the design is terminally broken. It's not as if the necessary crypto techniques are not very well known.
I have no first hand experience of Teslas, but from the descriptions I've seen it sounds like this is a black box type of recording. It doesn't appeared to be used for anything until you crash the car, when it can be used to investigate what happened.
The tracking in Windows 10 on the other hand serves no such purpose. Call Microsoft and say, "I've corrupted my vital spreadsheet. Please check your tracking data and tell me what I did wrong." and you're not going to get much in the way of useful assistance. The Windows 10 stuff exists purely for the purpose of Microsoft extracting value from their customers.
I may be wrong - it may be that Tesla track where you drive and when and then use it to try to sell you stuff, or to sell information about you to third parties. I've seen no evidence of it so far though.
What I did was to arrange for all his files to be rsynced daily to one of my servers, which in its turn was backed up nightly.
We had a couple of instances of him accidentally deleting stuff and I was able to restore it for him easily. Happily he never got hit with any malicious software - not after I weaned him of Windows anyway.
Slashdot Mirror
When a call says "Internat" in the caller ID, I answer in French and refuse to speak anything other than French. (The only people I know who are abroad and phone me by conventional means are French - all those living further afield use Skype.)
It's quite fun. My French isn't that good, but it's better than that of the average scammer.
Would dir /s produce a listing of all subdirectories of the current working directory?
Yes. A space followed by a slash would always be interpreted as a switch introducer.
Directory separators generally occur in the middle of a string, the only exception being when you want to talk about the root directory of a drive, without specifying which drive you want.
You use "C:/" to mean the root directory of C. It would be quite natural to use ":/" to mean the root directory of whatever drive is current.
It's not as if all this hadn't been done before - Microsoft were just never very good at reading manuals and learning from what had gone before. (See their totally brain-dead handling of daylight saving time.)
And indeed, it was used as a switch character in VMS too. The error however was in changing the directory separator character (which in underlying MS-DOS is still "/") to the totally unsuitable "\".
I remember the early OS/2 development kit tools, where clearly a dictat had gone out to the developers saying that both "-" and "/" were to be used as switch characters. The trouble was, they hadn't done it properly by implementing some library code, but instead each tool developer had done it himself. The end result was that some accepted "-", some accepted "/", some accepted both, and some would take one or the other, but not both in the same command line. A horrible mess.
It would not have been hard though to allow "/" to be used as a switch character to COMMAND.COM, whilst still retaining its use as a directory separator.
Agreed - it was a really stupid mis-feature in early browsers which has unfortunately been carried on and some people have become used to it and don't want to lose it. Although "Backspace" and "Go back" both contain the four-letter sequence "back", they actually do completely different things and the key should never have been overloaded to do something so totally different.
It probably seemed like a good idea at the time to the person who thought of it, and unfortunately he or she implemented it without really thinking it through. Much pain has thus been inflicted.
It's a bit like the twit at Microsoft who decided to change the directory separator understood by COMMAND.COM from "/" to "\" because he wanted to use "/" for something else. (N.B. it was only ever the command shell which required this. The underlying OS has always understood "/" as a directory separator.) It seemed like a good idea at the time, but it similarly wasn't thought through and has caused endless pain since.
10B-2 phase, which gave you all the disadvantages of TR
I'd agree it gave you some, but never quite all.
I remember walking the length of the network at my first job, carrying a terminator, unplugging each device in series to figure out where the problem was.
True, but the terminators had the advantage that they were passive devices. Once you had a good set of cables and terminators, they then very seldom went wrong. The BNC connectors had a very positive latching action and you could be confident that they would stay together. You then just had to indoctrinate users with the idea that their hands would be chopped off if they unplugged any of them.
TR on the other hand relied on very active components in the MAU, which had a high failure rate. That awful sound of an MAU continually clicking as it tried to remember how to do networking.
Basically it's what you want to run your Nuclear Power Plants, live-saving medical devices and bizarly expensive "failure is not an option" Space Equiment with.
The design intention was to produce something more reliable, but the implementation failed miserably. Those clunky connectors where you could never be quite sure that they'd mated correctly. Lost tokens resulting in periods of no connectivity. The fun game of going into your comms cupboard and unplugging each lead in turn from the MAU in order to plug in that magic reset gadget, which might then restore connectivity to your LAN. Token Ring was a train-wreck with an awful lot of money pushing it to big business.
The point of Token Ring was to have plugs and sockets where it was impossible to put the plug in the wrong way around - or the right way around.
And indeed, you could simply plug two plugs together.
I used to do quite a few joint pitches with IBM sales-folk back then, and it was amusing to watch the show as they addressed the question of which networking hardware to go for. The plot was always the same. At early meetings they would say, "IBM sells both Ethernet and Token Ring and we recommend whichever is most appropriate for each customer. We'll need to learn more about your particular requirements before we can say which one is more suitable for you." Then, several meetings later when lots of things had been discussed, but nothing really relevant to the networking hardware the message would become, "Now we've had a chance to assess your particular requirements, we can say that for your particular case Token Ring would be better." It was always Token Ring, and never any explanation as to why.
The real point of Token Ring was that IBM owned it and they didn't own Ethernet. It set out to solve a problem which didn't exist if you designed your network properly in the first place (overloaded Ethernet provides poor service to everyone) and introduced far more of its own. Like so many IBM technologies, it was a mess. Don't get me started on APPC.
No I do not want LibreOffice as it doesn't implement all of the features and sometimes has compatiblity issues from time to time that MS never has.
I love this argument. LibreOffice has compatibility issues with MS Office, and MS Office never has compatibility issues with MS Office.
Apart from the fact that the second bit isn't even true - we regularly get compatibility issues when asking MS Office to open older files created in MS Office - it's totally cock-eyed. It assumes that MS Office is filled with god^h^hates-given correctness and anything which isn't the same is wrong. A bit like MS's train-wreck of an ISO standard for office documents, which says in some places, "Do what Office does", without specifying what that is.
I've recently been forced to use LibreOffice to overcome a bug in MS Excel when importing some data. MS Excel fails to read CSV files correctly if there are embedded line breaks within a field. Faced with a supplier who lacked the technical expertise to read the CSV files directly (and not the slightest comprehension of what an encoding is), I had to read them into LibreOffice, save them in XLSX format, then read them into Excel. For some weird reason, Excel is phenomenally slow when faced with a sheet containing line breaks within a field - think 2 to 3 minutes just to open the file - but it did at least overcome the immediate problem. The supplier remains totally clueless, and with an attitude much like yours. It's not their fault for having no idea what they're doing - it's the real world's fault for not fitting in around Excel's bugs.
The inner function would be "extern 'C' char* membla(...)" and the outer one "static char* membla(...)"
No, the outer one wouldn't be static (meaning in this context, private) because it has doesn't have the static keyword. You're also introducing the complication of wondering what it would look like to a C++ program, which if we're working in pure C doesn't matter.
I've now checked the signature of memmove() and realise that the one someone posted earlier in the thread is wrong. My implementation should therefore read:
#include <stdlib.h>
void *memmov(void *dst, const void *src, size_t count) {
return memmove(dst, src, count);
}
Note that they're void* pointers, not char* pointers. This is one of the areas where C and C++ differ quite distinctly.
What about C++? The linker certainly could distinguish them, but the compiler?
Now you remind me of a project a long time ago (80s?) where we had to implement a comms library in pure C to run across 5 different platforms. The trouble was, at least one of the platforms didn't have an ANSI/ISO C conformant compiler (it was only a draft in those days), and something (K&R C) guaranteed you only 6 significant characters when things hit the linker. One platform did indeed recognise only 6 characters. We got around that with a header file containing:
#define EPC_OpenConnection EPC001
#define EPC_CloseConnection EPC002
#define EPC_WaitForOpen EPC003
#define EPC_WaitForClose EPC004
Ah the delights which are forgotten to today's programmers.
Erm ... John Wulff? Is that you? Just seeing your nick.
Sorry, no.
That would only work on systems that have a heap and support malloc and free :D
Which are both part of the standard library, so provided you're working in a hosted environment, you're fine.
That is from a scientific point of view not inefficient.
By the specific measure of how the amount of work varies with the amount of data to be handled, you're right - it's no worse than a good algorithm. However it is still very inefficient, because it involves twice as much work for any given amount of data as a good implementation would. Effectiveness is a measure of whether or not it does the job, which it would - just not efficiently.
No - no spelling error.
You asked for an implementation of memmov(), which by implication it appeared you wanted to work the same as memmove().
If I had spelled them both the same, then it definitely wouldn't have worked.
I bet 90% of all programmers who consider themselves 'competent' did their first memmov() implementation wrong.
I'd agree with you. However, having now thought about it a bit more (and trying to drag my detailed knowledge of C back from hither regions of my brain), I'm tempted to suspect that it's not even possible to implement a robust and correct version of memmove() without having a special relationship with the compiler. In other words, it needs to be done by the implementation. You can't (in general) compare the two pointers which are passed in unless you have extra knowledge of the particular implementation on which you are running.
My best idea for a portable - horribly inefficient - implementation so far would be to malloc a temporary buffer, copy the data from the source to the temporary buffer, then copy it again to the destination. I'm open to better suggestions.
I doubt you can write in 4 lines of C a memmov() function that works correctly, when source and target area are overlapping.
#include <stdlib.h>
void memmov(void *dst, const void *src, size_t count) {
memmove(dst, src, count);
}
How did I do?
Disclaimer - it's years since I did any serious C programming.
You would need to implement memmove because, believe it or not, there are people out there who implement the libraries that memmove is implemented in.
But if you're the person implementing the standard library for a compiler then you're not constrained in the same way as someone asked to re-implement it in portable C. As various people have said, it's very hard when you can't rely on, for instance, a cast from a pointer to a long int working correctly.
If you're actually implementing the standard library function, you're not even constrained to writing it in C at all. It might well be done in raw assembler in order to make use of the maximum number of available registers.
memcpy doesn't necessarily handle overlapping regions.
I've known at least one implementation (Norcroft C for the Acorn Archimedes) where the two were in fact the same function. memmov guarantees not to corrupt your data due to an overlap, memcpy does not guarantee that it will corrupt your data in that case.
The only reason to have a separate memcpy is it might be possible to make it faster by skipping the checks. The ARM's block copying capabilities were so blindingly fast by the standards of the day there was no need to implement a separate memcpy.
This ability meant that the GUI gave you solid window drags when almost everything else still had you dragging an outline.
I'm now slightly boggled by my Nexus One, which must be nearly 6 years old. The battery still has no difficulty making it through the day. (Although I had to install CyanogenMod and move some of the system to a uSD card in order to keep using it.
Can anyone explain why some people have such an irrational hatred of Ruby?
There are some really bad languages out there (Ruby isn't one of them) but none seems to garner quite the same mindless abuse.
I've been driving for 40 years now.
In that entire time, I've had only 5 (maybe 6) occasions when I had to pay attention to the road.
You need to pay attention to the road the whole time. I think you mean you've had only 5 or 6 occasions when you've needed to take emergency evasive action. I'm intrigued as to where you live. I've been driving a similar length of time in the UK and would reckon on incidents such as you describe happening 5 or 6 times a year. My most recent one was when I was driving a mini-bus last week, and a lady coming out of a side road just decided she could pull across my path right in front of me. Cue emergency stop and people nearly sliding off seats.
If you aren't paying attention to the road all the time, then you won't be ready to respond when these things happen.
In fact, most the time driving home from work people are in a semi-trance like state.
Now there I have to agree with you.
...that's no moon!
Online stores and even in-person transactions often require the CVV if you swipe them, as well.
On-line stores have to ask for the CVV. It's been a while since I ran my own business, but back then we were explicitly forbidden from capturing the CVV for in-person transactions. The idea is that nobody has it but the physical card holder.
I do admit to being puzzled by this story though. If the wireless conversation between a contactless card and any kind of reader carries enough information for the card to be cloned, then the design is terminally broken. It's not as if the necessary crypto techniques are not very well known.
What does "much-sophisticated" mean?
In what way has history shown us that Microsoft will screw its customers?
You must be new here.
The two are (potentially) very different.
I have no first hand experience of Teslas, but from the descriptions I've seen it sounds like this is a black box type of recording. It doesn't appeared to be used for anything until you crash the car, when it can be used to investigate what happened.
The tracking in Windows 10 on the other hand serves no such purpose. Call Microsoft and say, "I've corrupted my vital spreadsheet. Please check your tracking data and tell me what I did wrong." and you're not going to get much in the way of useful assistance. The Windows 10 stuff exists purely for the purpose of Microsoft extracting value from their customers.
I may be wrong - it may be that Tesla track where you drive and when and then use it to try to sell you stuff, or to sell information about you to third parties. I've seen no evidence of it so far though.
The trouble with that is, after remembering a couple of times the job will then be forgotten.
Whatever it is, it has to be automated.
I had the same problem with my father.
What I did was to arrange for all his files to be rsynced daily to one of my servers, which in its turn was backed up nightly.
We had a couple of instances of him accidentally deleting stuff and I was able to restore it for him easily. Happily he never got hit with any malicious software - not after I weaned him of Windows anyway.