Good bye Silverlight Road
-
You mean GCC, right?
Though WTF are you using either of those things these days?
Go Unicode or go home.
-
Hell if I know. Some other developer is using them in one of our products and I need it to compile on Linux as well.
-
Go Unicode or go home.
Both of those functions are totally applicable to Unicode if you're doing the normal thing and representing them as UTF8 strings.
-
Add a macro to a common header which causes a compiler error if those functions are used?
-
-
-
Right now I wish someone would sue Linux for not having strcpy_s and sprintf_s.
Well, you really want
strlcpy
andsnprintf
...Filed under: hitting MS over the head with a cluebat for their broken
snprintf
implementation
-
And if you did use them, your code wouldn't run on Sun's JVM? Like @powerlord said?
Yes. But you wouldn't have a good reason to except in certain circumstances.
People made it out like MS was making their JVM widely incompatible such that if you just compiled your program on it, you couldn't use it against Sun's, and that just plain wasn't true. Within days of people hearing about the issue, all the suspect APIs had been identified and analyzed for how much of a problem they would cause.
There were a few places where they'd be really useful. But it was very niche.
-
@mott555 said:
Right now I wish someone would sue Linux for not having strcpy_s and sprintf_s.
Well, you really want
strlcpy
andsnprintf
...Filed under: hitting MS over the head with a cluebat for their broken
snprintf
implementation
I write very little C/C++... but I just wrote something that usedsnprintf
last week.What's wrong with Microsoft's
snprintf
?
-
It doesn't put null terminator at the end.
-
Actually, I think TWRTF is probably that C string functions are being used in C++-land where std::string is a better choice, but I just want it to compile and don't feel like re-writing all of someone else's code.
-
It doesn't put null terminator at the end.
That's because it is a "safe" replacement for wsprintf, which was added to the windows API way back (maybe 3.0? Can't remember if it was in Windows/286) because back then you couldn't use ANY C run time functions. And wsprintf didn't include line terminator because they figured you were using the output to paint on the screen via GDI functions (which is what I used it for).
-
Unfortunately, I don't have the choice for using std::string as this is dealing with data I don't control that comes in (and goes out) as
char*
.I'm going through this code now to see if
snprintf
is actually using the base copy from the library or if its redefined somewhere (likestrncpy
is)checks
Hovering over
sprintf
has VS2013u4 highlight it with#define snprintf _snprintf
. Not sure what's going on in there, particularly since that's defined in stdio.h.
-
Meh, this is actually for turning a string into a shorter string, so given
_snprintf
's documentation1, I should be OK.1
and appends a terminating null character if the formatted string length is strictly less than count characters
-
Well, you really want strlcpy and snprintf...
At some point, I agreed, but I've actually come around and think that the "secure CRT" string functions are actually much better-designed. I kind of think thatstrlcpy
andstrlcat
in particular doesn't necessarily do anything useful. I mean, it's still better thanstrcpy
because it converts an immediate memory corruption bug (and possible vulnerability) to something else, but the problem is that it can return results that are "wrong" in the case of a would-be overflow. So you can't really use it for anything where you need to rely on the results unless you check for truncation anyway, which means you might as well have not used it to begin with.By contrast, the "secure CRT" string functions abort by default in MS's implementation and can easily be made to abort in anything that implement's C11's Annex K (the standardization of them). That's harsh, but it means you won't produce incorrect results that could lead to problems.
The time I flipped my opinion was when I started looking at them through the lens of exploit mitigation. DEP, ASLR, and stack canaries aren't perfect, but they sure as hell raise the bar for attackers. And none of them try to do any correction, because they can't; DEP violations lead to an abort, canary violations lead to an abort, sigsegvs because some thing isn't at an expected address lead to an abort. Same with the secure CRT functions. There is no corrective action they can take that is likely to lead to correct execution of the program -- silent truncation isn't -- so the only reasonable action is to abort.
(Sure, there're situations where the
strlcpy
behavior is what you want, but you can get that behavior easily enough with an explicit bound.)
-
Actually, I think TWRTF is probably that C string functions are being used in C++-land where std::string is a better choice
It would be great if C++ offered a replacement for printf family of functions but it doesn't.That's because it is a "safe" replacement for wsprintf, which was added to the windows API way back
You forgot that UNIX guys had snprintf much earlier, and that MS implemented it because it was in POSIX standard, which MS wants to make Windows complaint with, but as every other POSIX function, they implemented it slightly wrong - just the right amount of wrong that people used to POSIX still feel comfortable using it, but which makes writing portable code a nightmare.
-
You forgot that UNIX guys had snprintf much earlier, and that MS implemented it because it was in POSIX standard, which MS wants to make Windows complaint with, but as every other POSIX function, they implemented it slightly wrong - just the right amount of wrong that people used to POSIX still feel comfortable using it, but which makes writing portable code a nightmare.
Yep -- the return value on_snprintf()
is not POSIX-compliant sigh
-
Surprise: I never owned any handheld console! Not even Gameboy!
Oh come on, you had to have had this:
Everybody had this.
agsfdfdbkafdhoufdbja piuvtmumcrew qaweaweKN42
Your typos are really going out of hand.
I never have let flash install for FireFox
Except so many fucking pages run Flash ads covering content that you have no way to dismiss without enabling Flash...
-
Except so many fucking pages run Flash ads covering content that you have no way to dismiss without enabling Flash...
Can't you just open the inspector and kill the div they're in?
-
Can't you just open the inspector and kill the div they're in?
Sounds like work. I'd rather ramble about it.
(seriously though, guess I could, never really thought about it... but it's still ramble-worthy, because it's such an asshat move)
-
Oh come on, you had to have had this:
Got me. I actually told more lies in this topic than just that.
-
Can't you just open the inspector and kill the div they're in?
Adblockers are nice but they're a step back, as I've said before, from filtering proxies like Proxomitron.
-
Adblockers are nice but they're a step back, as I've said before, from filtering proxies like Proxomitron.
Our proxy at work does that (among other things) -- and I've actually seen sites break because of it. (News-TV-station video player thingamajigs are the the typical culprits)
-
Since Proxomitron let you control everything that was blocked, you could take out any filter rules that would break a site, if it's important to you.
-
Microsoft included a small number, maybe a dozen, functions to a tiny handful of classes, none of which were anything but convenience functions. If you avoided them, anything you wrote would be as portable as Java is capable of being.
Flat-out utterly wrong.
-
Nobody had to use delegates. Just like nobody had to use the few functions MS added to a few classes. I was there, I remember reading about it at the time, because someone did an analysis of it.
BTW, literally 2 minutes of Googling substantiated this:
" Specifically, Microsoft does not support the Java Native Interfaces (JNI) or the Remote Method Invocation (RMI), and [b]it has altered the Core Java class libraries with about 50 methods and 50 fields that are not part of the public Java Application Programming Interfaces (APIs) published by Sun[/b]." (emphasis mine).
Yes, I forgot the part about MS not implementing JNI/RMI, which I haven't thought about in 18 years, and I was off slightly in my numbers.
-
https://msdn.microsoft.com/en-us/library/aa260511(v=vs.60).aspx
Seriously MSDN, just get semantic URLs already.
-
which MS wants to make Windows complaint with
And did exactly that, from your description.
-
pinging @accalia to let xem know ze's not alone... <actually, I noticed this long ago and was just waiting to see if someone notices it too>
-
xem
ze's
I know i'm a terrible typist, but even i know that those are not words.
-
Me too. But I can never remember which of you two is a guy and which is a gal. And those words are so godawful I can't help but use them everywhere. Kinda like Windows.
-
-
But I can never remember which of you two is a guy and which is a gal.
but there's only one of me...
-
Both @accalia and @RaceProUK are to be handled as female, I understand. I'll refrain from mentioning real-life genders, as far as formerly communicated.
-
-
Both @accalia and @RaceProUK are to be handled as female, I understand. I'll refrain from mentioning real-life genders, as far as formerly communicated.
Since both of them liked this answer, I guess I'll refer to @accalia as she from now on.
-
I know i'm a terrible typist, but even i know that those are not words.
Tsk. Such misogyny.
-
I'm currently installing the most recent version of LabVIEW (not sure if I'm allowed to print the version number since it's not officially released yet) and guess what... I had to agree to the Silverlight 5 EULA in the installer!
-
-
Wonder how long until you have to update again.
-
-
A dirty mind[1] is a joy forever.
[1] yours
-
I'm currently installing the most recent version of LabVIEW
Now you have multiple problems!
What is it about LabVIEW that people like?
It always seems to result in a mess that nobody understands, with a GUI that breaks all OS conventions.
-
I don't know anyone who actually likes LabVIEW. Some of our products can be operated through LabVIEW so we need to deal with it for testing and support. As it stands, most of our LabVIEW support is actually just a thin VI wrapper around C code living in a DLL because it's far quicker for most of us to write stuff in C than actually write it in LabVIEW.
It wouldn't be quite so bad if they used a vector graphics interface with zoom support instead of bitmaps.
-
-
Over/under on when that msdn URL will be broken?
-
Flash
still is not x64 compatible
-
still is not x64 compatible
Note that Pepper Flash (Chrome) is 64-bit and has ASLR along with a custom allocation pool for
Vector<almost_all_types>
now. (The favorite exploitation technique was to corrupt thelength
on aVector<uint>
and use that to browse the heap.)
-
Cool story that.
there's also a linux clone of flash called gnash that's 64 bit and is about on par with pepper flash
neither of those are adobe flash which is still exclusively 32bit.
-