You misunderstood the 8.3 patent. Storing all the information in a different file (as Profession Write does) is the "obvious" and thus unpatentable way of doing it. (also "obvious" is the idea of using more than 8.3 letters in a filename at all).
The novel part of the M$ scheme is to not use a separate file but to instead use extra hidden directory entries. This has the particular advantage that if an old system deletes all the files the directory really will look empty, rather than having an undeletable file of information. I think it is an innovation, in that every other known scheme used an extra file, and thus this M$ patent is not anywhere near as questionable as others.
That said, I have no idea why changing the 8.3 mangling could possibly work around the patent, which has been proposed, therefore I may not understand the patent and they may have somehow patented the wrong (and thus obvious) part. Name mangling I consider pretty obvious.
You would still use that contractor if they promised to build a mansion for the same price as a shack and you knew they were the only ones that could do so.
I don't consider "touch" to mean "leave combined" and I don't think anybody else does either, except perhaps you. "Touch" implies that you later can separate the items, otherwise I would use "attach" or "glue" or some other permanent-sounding word.
Sorry, but he clearly said it "infects everything it TOUCHES" and the word touch clearly implies that if it is removed it is still "infected". This is blatently untrue but serves Microsoft's interests to imply it.
Certainly a programmer "touches" all the code they write. Ballmer distincly implied that the GPL would attach itself to the programmer and thus to every other item they wrote. You can claim he did not really say that, but the implied meaning of his sentence is pretty obvious and he has now been shown, by his own companies actions, that he LIED.
No I'm claiming the argument is silly, but that some people seem to be comparing such technical infringement with willful plagiarism and considering them to be equal, in order to try to be clever and claim that posters here are not being consistent about copyright.
That said, I do not feel that companies that stick Linux on their machine and do not modify it should be blasted for not releasing the source as though they are somehow evil. Maybe quietly told that they are violating the copyright and it is really easy and free for them to fix it, but it really is not a big deal. This is one area where people here do seem to be inconsistent.
What I meant was that a bittorrent node splits up things into blocks and thus technically it is very likely it is transmitting a piece of GPL compiled code without including the necessary notice of availability of the source.
Less theoretical: I suspect an awful lot of installed Linux systems do not provide any indication of how to get the source code and thus the installer also violated the GPL. This is especially true if the end user wants to actually recreate the code they have installed, rather than perhaps building a different or generic distribution of Linux.
the proper way to tackle this is to ditch null-terminating strings entirely and use ones with explicit length, a la Pascal/Java/C#. Extra 4 bytes are well worth the added convenience, it's much safer (as you always know the lengths in advance, and can always allocate exactly as much as needed without overhead of scanning the string to figure it out), and it can often improve performance as well, depending on what is done with the string.
A big advantage you forgot to mention is that all possible byte values (ie 0) can be put into the string.
Pascal (for most of it's history, at least) used 1-byte counts so the string length was limited to 256 bytes. Until about 1990 it seems nobody thought it logical to waste 3 bytes storing the length, so everybody saw the choices as either limiting string length to 256 or not allowing nul, and everybody chose the latter.
On current machines it makes perfect sense to use a length. If you want to save memory and have so many small strings that the space wasted by the length makes a significant difference, you can save far more memory by using either a hash table (because you must have lots of duplicates) or some cryptic compressed encoding.
One advantage C strings have however is that the operation "return the tail of the string" is O(1). This is not true for any other string representation. This does not sound like a big deal but a lot of software depends on it for speed and this has derailed previous attempts to rewrite things away from C strings or into other languages.
Hey I actually wrote all of Linux in my basement, and all these geeks stole it! I emailed it to Linus and he stole it, I just never bothered to mention it until now. How can you possibly prove otherwise! Yes you can't prove anything, not beyond a shadow of a doubt.
Also this is true of every single possible copyright case in the world, and is not GPL specific.
The point is that they released it GPL because they wanted it in the kernel. They did not GPL it because of any other requirement. It does not matter whether writing a Linux driver requires releasing it GPL or not, because they wanted the GPL anyway so it would be in the kernel.
The claim is that MS used GPL'd code in their drivers and were forced to GPL it because they were "caught", but that's simply not true.
I fully agree. The writers of that code intended from the start to release it GPL, this story that they were "caught" is nonsense and makes it look like they are idiots, which they are not.
where exactly did MS claim that GPLing some drivers would force them to GPL every bit of code they ever wrote?
"The GPL is a cancer that will infect everything you write". Or are you going to pretend Ballmer did not say that?
I certainly did read 6.1.4.4, which is why I thought the default behavior was for the error handler to return. Certainly the description of strcpy_s implied that it returned because it spent some time describing exactly the value it returned.
In any case I think you are underestimating the problem with the buffer being truncated to zero length. In your rm example, it is certainly plausable that it will now remove the ENTIRE DISK, because "" may be the name of the root filesystem. If you don't believe this, try looking at real code, concatenating a slash is really common. I greatly prefer the strlcpy result where the chances of hitting an actual filename are somewhat lower.
I also think you are missing the fact that the DOS is likely to happen when the program is in use and that it could be far worse than the buffer overflow. The buffer overflow will probably crash, and may not be exploitable. The DOS is GUARANTEED to happen.
The biggest problem is that everybody seems to ignore the fact that strlcpy returns a clear error indicator that contains useful information and that it is useful for actual fast code. If you are unconcerned about speed it is nonsense to use char* pointers at all, use some safe string object, this is another reason why I think warningsencouraging you to replace strcpy with some other slightly safer call is wrong, as it justs wastes programmers time when they should be doing a true replacement, or figure out how to use strlcpy correctly.
Anyway, none of my complaints is about the _s functions, except they seem to be typical crap designed by committee. My complaint is about Microsoft putting warnings into their code to try to force people to alter it to be non-portable, that is pretty insidious and inexcusable.
Copying a Metallica disk and clearly labelling that it is Metallica and that they wrote the songs is copyright infringement.
Copying a Metallica disk and claiming you wrote and performed the songs is stealing attribution and certainly is stealing. If you are successful in doing this you would get all the rewards of making that music and Metallica would not get them, so there certainly is a tangible asset transfer and thus theft.
For some reason all the anti-GPL people seem to completely ignore the distinction.
Technically the GPL is violated a million times a day. Any bittorrent site distributing a GPL binary is violating it by not simultaneously distributing the source code. Anybody installing Linux and not putting the source code on the machine is violating the GPL. Yet nobody is trying to sue them and nobody is saying they are "stealing".
The original code is still under the GPL license because it is irrevocable. Unless Yoyodyne can prove that Bob's copy includes information that they added that was not in the original GPL version then they can't do anything.
Of course Yoyodyne can make modifications, or even redistribute the unmodified program, with it's own copyright. It can keep it closed source or put it in the public domain. This is totally irrelevant.
Your argument amounts to "if we assume the GPL is revocable, then I can make a scenario where it looks like it is revocable". Not a very good argument imho.
This is ok as the employess are under contract to not divulge trade secrets. They therefore cannot redistribute the software and thus there is no GPL requirement that they redistribute the code.
I suppose it is possible the employees themselves should have access to the code but you could put it on a locked-down machine in the company basement, and they will have access to the code.
The term "lesser" is because RMS thinks the license is worse, not the libraries, you idiot. In fact libc is considered superior in the cases where there still remains a competitor such as on Solaris.
Personally I think he is being an ass with this and prefer calling it the "library" GPL like it was named originally.
He can continue to merge in any changes that the community makes, and certainly can take advantage of them.
Also if there is some bug or feature in mysql they need, they can make a stripped-down version of their application, such as an otherwise useless page of code that demonstrates the desired feature or bug, submit that, and hope the mysql guys fix it.
They could also fix mysql itself, contribute the fix back, and if it gets incorporated into the main source they are in exactly the same state but their code is still secret.
Because in any realistic scenario, customized code costing $1,000,000 probably contains more than $1,000,000 of trade secrets of the customer and thus it makes no sense to sell it. In fact the original author is probably not allowed to sell or redistribute it either (I believe the GPL would allow this as they are only required to distribute source to customers and a contract saying nobody else can be a customer can still be enforced).
Okay I understand. I was using "character" as "char".
Trying to write a "character" stream is a big problem and seriously causing grief in programs now. One big peeve I have is with otherwise intelligent programmers who seem to become complete morons when presented with Unicode and start thinking it is impossible to manipulate it unless they can count the "characters" and they are all the same size, leading to horrid things like UTF-16 and multiple api's to everything. Raw byte streams are the way to go, containing UTF-8 or whatever, the only stuff that needs to look at "characters" are the actual display routines and text editors. This would get rid of an enormous mess of complexity and incompatability, mostly because errors in the UTF-8 could be deferred until they really matter. Lots of security problems would be fixed if you could know that two unequal byte streams will evaluate to two different objects, something that is not true for anything that translates them into a different internal representation.
The standard docs pretty clearly state that the default error hander does nothing and returns to the function, and that the strcpy_s function truncates the buffer and then returns after the error handler returns.
Well that really sucks. Did not realize it was as bad as that.
I can certainly see how there could be a design with a single virtual flush() function plus a pointer and length of buffer in the base class, and a virtual destructor. But not the mess you are showing me there.
The template problem is that it makes it so complicated you cannot even see this, and they are not taking any advantage of the templates to remove the virtual functions. Though I guess using templates that way would make it impossible to pass an arbitrary new stream object to an existing function. Gah.
Agreed. Well, there's nothing wrong with character streams as such (in the same way as TextWriter is distinct from Stream in.NET), and it makes sense to specialize for various character types there, but there should be a raw byte stream underneath - and there isn't one in C++, as streambufs are still character-oriented.
I don't quite understand what you are getting at. My complaint is that streambufs are NOT character-oriented, in that they take a template argument of the data type. I think it would be much better if they were char-only.
strlcpy does indeed return a clear "failure" result, because it returns the length of buffer that would be needed. This can be tested on the return value, and also provides information on exactly what needs to be done by the program to fix it.
Here is an example of how to use it, as some people do not seem to understand strlcpy at all. No other function design lets you do this. (in case you don't understand this, please assume this is a function that needs to be very fast and that the programmer knows that 99.99999% of the time the string is less than 200 characters):
func() {
char localbuffer[200];
char* bufferpointer;
int n = strlcpy(localbuffer, x);
if (n > 200) {
bufferpointer = new char[n];
strcpy(bufferpointer, x);
} else {
bufferpointer = localbuffer;
do_something(bufferpointer);
if (bufferpointer != localbuffer)
delete[] bufferpointer;
}
This is immensely more useful than strcpy_s and strncpy.
strlcpy is used in Linux, thousands and thousands of times. It is also used in Windows software just as much. The fact that Ulrich Depper hates strlcpy does not give an excuse for Microsoft. Yes there are asshats in Linux but that does not mean you can't complain about them also being at Microsoft.
Actually _snprintf *DOES* produce a warning, unless they changed things more recently. My mistake. We did have some problem with macros but the switch to turn off the warnings did work for all of the interesting ones. There was some warning about the use of varargs that was unavoidable but is a different bug in vc++.
The default behavior for the strcpy_s error handler is to return, with the buffer truncated. Since programs don't change this (and they can't if any library routines are relying on the behavior) then any theoretical advantages you list are moot.
It is certainly possible to do pointer arithmetic in a language that does not allow arithmetic between pointers to two different objects, and thus subtracting NULL is not allowed.
I do not see any reason why a GC could not be designed so that pointers into an object indicate it is in use just as well as a pointer to the start of the object, which is why I don't see how pointer arithmetic itself is a problem.
Your second description of conservative/accurate matches what I described, but your earlier email said something like "accurate cannot be done with the inability to write to pointers" which implied to me that you thought "accurate" meant "relocating".
I don't think iostreams uses virtual functions or base classes.
It is using templates which causes it's problems.
This was caused by the ludicrous idea that it would be used to write streams of objects other than bytes. About the only reasonable thing to write is UTF16 and even that is pretty much obsoleted by using UTF-8 to write Unicode. Writing larger or arbitrary objects looks nice initially but you quickly realize that it is entirely pointless to use an API designed for string constants to write objects that are not letters.
There are alternative iostream implementations that ditch the types (and also the allocator arguments) and work significantly better and are much much smaller. Unfortunately they are not standard.
Template specialization may help here but we need to get the considerable subset of developers who are not really writing real code and thus think writing UTF-16 with iostreams is important to be recipients of the clue stick before that will ever happen...
A few points because I have also had to deal with those warnings:
Microsoft wrote and forced through that standard.
At the time they wrote it, other solutions like strlcpy were FAR more popular, and still are, yet they ignored them and purposely wrote an alternative with different behavior and the argument order rearranged.
The behavior of truncating the destination buffer to an empty string on error is quite useless and can destroy data in the strcat replacement.
They produce the "unsafe" warning for strncpy, which actually is not any less safe then their alternative.
They do not produce the "unsafe" warning for thousands of other calls that can overwrite buffes, only mysteriously for a subset that happens to be in the cross-platform library.
They produce the "unsafe" warning if you use any kind of macro to make _snprintf be called "snprintf" but don't do this if you directly call their function and thus have an unportable program.
Slashdot Mirror
You misunderstood the 8.3 patent. Storing all the information in a different file (as Profession Write does) is the "obvious" and thus unpatentable way of doing it. (also "obvious" is the idea of using more than 8.3 letters in a filename at all).
The novel part of the M$ scheme is to not use a separate file but to instead use extra hidden directory entries. This has the particular advantage that if an old system deletes all the files the directory really will look empty, rather than having an undeletable file of information. I think it is an innovation, in that every other known scheme used an extra file, and thus this M$ patent is not anywhere near as questionable as others.
That said, I have no idea why changing the 8.3 mangling could possibly work around the patent, which has been proposed, therefore I may not understand the patent and they may have somehow patented the wrong (and thus obvious) part. Name mangling I consider pretty obvious.
You would still use that contractor if they promised to build a mansion for the same price as a shack and you knew they were the only ones that could do so.
I don't consider "touch" to mean "leave combined" and I don't think anybody else does either, except perhaps you. "Touch" implies that you later can separate the items, otherwise I would use "attach" or "glue" or some other permanent-sounding word.
Sorry, but he clearly said it "infects everything it TOUCHES" and the word touch clearly implies that if it is removed it is still "infected". This is blatently untrue but serves Microsoft's interests to imply it.
Certainly a programmer "touches" all the code they write. Ballmer distincly implied that the GPL would attach itself to the programmer and thus to every other item they wrote. You can claim he did not really say that, but the implied meaning of his sentence is pretty obvious and he has now been shown, by his own companies actions, that he LIED.
No I'm claiming the argument is silly, but that some people seem to be comparing such technical infringement with willful plagiarism and considering them to be equal, in order to try to be clever and claim that posters here are not being consistent about copyright.
That said, I do not feel that companies that stick Linux on their machine and do not modify it should be blasted for not releasing the source as though they are somehow evil. Maybe quietly told that they are violating the copyright and it is really easy and free for them to fix it, but it really is not a big deal. This is one area where people here do seem to be inconsistent.
The original Solaris license for one.
GPL incompatability was not what killed them, it was the reciprocation agreement. Witness the CDDL, which is doing ok, although GPL incompatible.
What I meant was that a bittorrent node splits up things into blocks and thus technically it is very likely it is transmitting a piece of GPL compiled code without including the necessary notice of availability of the source.
Less theoretical: I suspect an awful lot of installed Linux systems do not provide any indication of how to get the source code and thus the installer also violated the GPL. This is especially true if the end user wants to actually recreate the code they have installed, rather than perhaps building a different or generic distribution of Linux.
the proper way to tackle this is to ditch null-terminating strings entirely and use ones with explicit length, a la Pascal/Java/C#. Extra 4 bytes are well worth the added convenience, it's much safer (as you always know the lengths in advance, and can always allocate exactly as much as needed without overhead of scanning the string to figure it out), and it can often improve performance as well, depending on what is done with the string.
A big advantage you forgot to mention is that all possible byte values (ie 0) can be put into the string.
Pascal (for most of it's history, at least) used 1-byte counts so the string length was limited to 256 bytes. Until about 1990 it seems nobody thought it logical to waste 3 bytes storing the length, so everybody saw the choices as either limiting string length to 256 or not allowing nul, and everybody chose the latter.
On current machines it makes perfect sense to use a length. If you want to save memory and have so many small strings that the space wasted by the length makes a significant difference, you can save far more memory by using either a hash table (because you must have lots of duplicates) or some cryptic compressed encoding.
One advantage C strings have however is that the operation "return the tail of the string" is O(1). This is not true for any other string representation. This does not sound like a big deal but a lot of software depends on it for speed and this has derailed previous attempts to rewrite things away from C strings or into other languages.
Wow! Hypothetical scenario!
Hey I actually wrote all of Linux in my basement, and all these geeks stole it! I emailed it to Linus and he stole it, I just never bothered to mention it until now. How can you possibly prove otherwise! Yes you can't prove anything, not beyond a shadow of a doubt.
Also this is true of every single possible copyright case in the world, and is not GPL specific.
The point is that they released it GPL because they wanted it in the kernel. They did not GPL it because of any other requirement. It does not matter whether writing a Linux driver requires releasing it GPL or not, because they wanted the GPL anyway so it would be in the kernel.
The claim is that MS used GPL'd code in their drivers and were forced to GPL it because they were "caught", but that's simply not true.
I fully agree. The writers of that code intended from the start to release it GPL, this story that they were "caught" is nonsense and makes it look like they are idiots, which they are not.
where exactly did MS claim that GPLing some drivers would force them to GPL every bit of code they ever wrote?
"The GPL is a cancer that will infect everything you write". Or are you going to pretend Ballmer did not say that?
I certainly did read 6.1.4.4, which is why I thought the default behavior was for the error handler to return. Certainly the description of strcpy_s implied that it returned because it spent some time describing exactly the value it returned.
In any case I think you are underestimating the problem with the buffer being truncated to zero length. In your rm example, it is certainly plausable that it will now remove the ENTIRE DISK, because "" may be the name of the root filesystem. If you don't believe this, try looking at real code, concatenating a slash is really common. I greatly prefer the strlcpy result where the chances of hitting an actual filename are somewhat lower.
I also think you are missing the fact that the DOS is likely to happen when the program is in use and that it could be far worse than the buffer overflow. The buffer overflow will probably crash, and may not be exploitable. The DOS is GUARANTEED to happen.
The biggest problem is that everybody seems to ignore the fact that strlcpy returns a clear error indicator that contains useful information and that it is useful for actual fast code. If you are unconcerned about speed it is nonsense to use char* pointers at all, use some safe string object, this is another reason why I think warningsencouraging you to replace strcpy with some other slightly safer call is wrong, as it justs wastes programmers time when they should be doing a true replacement, or figure out how to use strlcpy correctly.
Anyway, none of my complaints is about the _s functions, except they seem to be typical crap designed by committee. My complaint is about Microsoft putting warnings into their code to try to force people to alter it to be non-portable, that is pretty insidious and inexcusable.
The argument about "stealing" is totally bogus.
Copying a Metallica disk and clearly labelling that it is Metallica and that they wrote the songs is copyright infringement.
Copying a Metallica disk and claiming you wrote and performed the songs is stealing attribution and certainly is stealing. If you are successful in doing this you would get all the rewards of making that music and Metallica would not get them, so there certainly is a tangible asset transfer and thus theft.
For some reason all the anti-GPL people seem to completely ignore the distinction.
Technically the GPL is violated a million times a day. Any bittorrent site distributing a GPL binary is violating it by not simultaneously distributing the source code. Anybody installing Linux and not putting the source code on the machine is violating the GPL. Yet nobody is trying to sue them and nobody is saying they are "stealing".
The original code is still under the GPL license because it is irrevocable. Unless Yoyodyne can prove that Bob's copy includes information that they added that was not in the original GPL version then they can't do anything.
Of course Yoyodyne can make modifications, or even redistribute the unmodified program, with it's own copyright. It can keep it closed source or put it in the public domain. This is totally irrelevant.
Your argument amounts to "if we assume the GPL is revocable, then I can make a scenario where it looks like it is revocable". Not a very good argument imho.
This is ok as the employess are under contract to not divulge trade secrets. They therefore cannot redistribute the software and thus there is no GPL requirement that they redistribute the code.
I suppose it is possible the employees themselves should have access to the code but you could put it on a locked-down machine in the company basement, and they will have access to the code.
The term "lesser" is because RMS thinks the license is worse, not the libraries, you idiot. In fact libc is considered superior in the cases where there still remains a competitor such as on Solaris.
Personally I think he is being an ass with this and prefer calling it the "library" GPL like it was named originally.
Yes there are LOTS of such licenses. In fact for a long time the majority of available source code was under such licenses.
The fact that they are not popular is an indication that people don't like them.
He can continue to merge in any changes that the community makes, and certainly can take advantage of them.
Also if there is some bug or feature in mysql they need, they can make a stripped-down version of their application, such as an otherwise useless page of code that demonstrates the desired feature or bug, submit that, and hope the mysql guys fix it.
They could also fix mysql itself, contribute the fix back, and if it gets incorporated into the main source they are in exactly the same state but their code is still secret.
Because in any realistic scenario, customized code costing $1,000,000 probably contains more than $1,000,000 of trade secrets of the customer and thus it makes no sense to sell it. In fact the original author is probably not allowed to sell or redistribute it either (I believe the GPL would allow this as they are only required to distribute source to customers and a contract saying nobody else can be a customer can still be enforced).
Okay I understand. I was using "character" as "char".
Trying to write a "character" stream is a big problem and seriously causing grief in programs now. One big peeve I have is with otherwise intelligent programmers who seem to become complete morons when presented with Unicode and start thinking it is impossible to manipulate it unless they can count the "characters" and they are all the same size, leading to horrid things like UTF-16 and multiple api's to everything. Raw byte streams are the way to go, containing UTF-8 or whatever, the only stuff that needs to look at "characters" are the actual display routines and text editors. This would get rid of an enormous mess of complexity and incompatability, mostly because errors in the UTF-8 could be deferred until they really matter. Lots of security problems would be fixed if you could know that two unequal byte streams will evaluate to two different objects, something that is not true for anything that translates them into a different internal representation.
The standard docs pretty clearly state that the default error hander does nothing and returns to the function, and that the strcpy_s function truncates the buffer and then returns after the error handler returns.
http://www.open-std.org/jtc1/sc22/wg14/www/projects#24731
I never actually tried calling these things as I want to write portable software.
Anyway I don't see how a DOS is much better than a buffer overflow.
Well that really sucks. Did not realize it was as bad as that.
I can certainly see how there could be a design with a single virtual flush() function plus a pointer and length of buffer in the base class, and a virtual destructor. But not the mess you are showing me there.
The template problem is that it makes it so complicated you cannot even see this, and they are not taking any advantage of the templates to remove the virtual functions. Though I guess using templates that way would make it impossible to pass an arbitrary new stream object to an existing function. Gah.
Agreed. Well, there's nothing wrong with character streams as such (in the same way as TextWriter is distinct from Stream in .NET), and it makes sense to specialize for various character types there, but there should be a raw byte stream underneath - and there isn't one in C++, as streambufs are still character-oriented.
I don't quite understand what you are getting at. My complaint is that streambufs are NOT character-oriented, in that they take a template argument of the data type. I think it would be much better if they were char-only.
strlcpy does indeed return a clear "failure" result, because it returns the length of buffer that would be needed. This can be tested on the return value, and also provides information on exactly what needs to be done by the program to fix it.
Here is an example of how to use it, as some people do not seem to understand strlcpy at all. No other function design lets you do this. (in case you don't understand this, please assume this is a function that needs to be very fast and that the programmer knows that 99.99999% of the time the string is less than 200 characters):
func() {
char localbuffer[200];
char* bufferpointer;
int n = strlcpy(localbuffer, x);
if (n > 200) {
bufferpointer = new char[n];
strcpy(bufferpointer, x);
} else {
bufferpointer = localbuffer;
do_something(bufferpointer);
if (bufferpointer != localbuffer)
delete[] bufferpointer;
}
This is immensely more useful than strcpy_s and strncpy.
strlcpy is used in Linux, thousands and thousands of times. It is also used in Windows software just as much. The fact that Ulrich Depper hates strlcpy does not give an excuse for Microsoft. Yes there are asshats in Linux but that does not mean you can't complain about them also being at Microsoft.
Actually _snprintf *DOES* produce a warning, unless they changed things more recently. My mistake. We did have some problem with macros but the switch to turn off the warnings did work for all of the interesting ones. There was some warning about the use of varargs that was unavoidable but is a different bug in vc++.
The default behavior for the strcpy_s error handler is to return, with the buffer truncated. Since programs don't change this (and they can't if any library routines are relying on the behavior) then any theoretical advantages you list are moot.
It is certainly possible to do pointer arithmetic in a language that does not allow arithmetic between pointers to two different objects, and thus subtracting NULL is not allowed.
I do not see any reason why a GC could not be designed so that pointers into an object indicate it is in use just as well as a pointer to the start of the object, which is why I don't see how pointer arithmetic itself is a problem.
Your second description of conservative/accurate matches what I described, but your earlier email said something like "accurate cannot be done with the inability to write to pointers" which implied to me that you thought "accurate" meant "relocating".
I don't think iostreams uses virtual functions or base classes.
It is using templates which causes it's problems.
This was caused by the ludicrous idea that it would be used to write streams of objects other than bytes. About the only reasonable thing to write is UTF16 and even that is pretty much obsoleted by using UTF-8 to write Unicode. Writing larger or arbitrary objects looks nice initially but you quickly realize that it is entirely pointless to use an API designed for string constants to write objects that are not letters.
There are alternative iostream implementations that ditch the types (and also the allocator arguments) and work significantly better and are much much smaller. Unfortunately they are not standard.
Template specialization may help here but we need to get the considerable subset of developers who are not really writing real code and thus think writing UTF-16 with iostreams is important to be recipients of the clue stick before that will ever happen...
A few points because I have also had to deal with those warnings:
Microsoft wrote and forced through that standard.
At the time they wrote it, other solutions like strlcpy were FAR more popular, and still are, yet they ignored them and purposely wrote an alternative with different behavior and the argument order rearranged.
The behavior of truncating the destination buffer to an empty string on error is quite useless and can destroy data in the strcat replacement.
They produce the "unsafe" warning for strncpy, which actually is not any less safe then their alternative.
They do not produce the "unsafe" warning for thousands of other calls that can overwrite buffes, only mysteriously for a subset that happens to be in the cross-platform library.
They produce the "unsafe" warning if you use any kind of macro to make _snprintf be called "snprintf" but don't do this if you directly call their function and thus have an unportable program.