Seriously, try loading the page with NoScript, and you get nothing. Apparently, it needed nearly a megabyte of JavaScript (somehow managing to make Firefox unresponsive for a several seconds on every page load) to asynchronously load a 600 word plain text article.
Not the author's fault (apart from choosing to use Blogger), but wow, how do you fuck web design up that badly? It's just a blog, a few paragraphs and links to more articles, it doesn't need to be an entire fucking web app complete with 5 other useless ways to view a list of summaries (Pinterest is big right now, people love grids, right? Here, let me smack you in the face with this stupid zooming JQuery effect).
Hi. I wrote this post and I agree with you about this particular annoyance (and apparently so do a lot of other people). Blogger themes are limited and while I can customize it I think a better solution is to move to another blogging platform.
I can't help wondering if back buttons should work differently. If you are here on this page as a result of a quick, automatic redirect and you hit "back", don't go back to the page that sent you here; skip over it to the most recent page that didn't automatically fling you forward.
I never liked those microsoft functions, and disable all the warnings in each new project. What are you supposed to use instead of memcpy?
It's a bit of a rant but I find myself in agreement with this:
The same is true for memcpy ya know... that's what memmove is for. Perhaps you should make sure you know what you're talking about before bashing others ("others" who are probably far more experienced than yourself).
Eh, I believe that was his point. If you're going to go to the trouble of building a safe memcpy with no sharp corners, don't leave the overlapping buffer razor blade sticking out. Perhaps you should settle down.
Hmmm... well perhaps I did miss that, but your (his?) suggestion is a terrible idea. memcpy should be fast. Checking for overlap slows it down. Want to allow for overlap? Use memmove, that's what it's there for. I don't want to have to roll my own optimized version of memcpy when I know that I don't need any special handling or error checking.
you know memcpy is my 'classical' example of why you should never trust library code to be well optimised. its almost always a dumbass byte-by-byte copy - its pretty much the worst case performance unless you go out of your way to slow down your implementation.
the speed improvement from good register usage and appropriate cache hints was >35% the last time i had to do this (iirc against the VS 2008 implementation)
MS provided a special memcpy variant for 360 that did this for you using the PPC dcb* instructions and good use of the wider registers.
this looks pretty recent, good to know that memcpy is improving (maybe). i suspect the reason icc is winning so hard is exactly what i mention - cache hints and good register usage. the things is that stuff isn't new... its much more than 10 years old now.
no memcpy implementation has an excuse to be that slow under any compiler imo.
i'd imagine the intel guys will make use of this stuff because its why they put it in the hardware to start with... :)
incidentally, as a complete tangent, really great bunch of guys to work with if you get the chance - at least in my experience. a definite passion for and focus on performance in a serious way. :)
Those aren't "Microsoft functions"; they're C's optional Annex K functions which Microsoft happens to mostly implement (though in true MS fashion, they did manage to get a few wrong before the standard was finalized).
> They were Microsoft functions long (6 years?) before they were standardized.
And most of what's in ANSI C (the first C standard, before ISO stepped in, from 1989) was in C compilers before ANSI C existed. I think void and void* were the only things ANSI C really added to the language.
My point is, the C standards body likes to standardize common usage, and 'what a Microsoft compiler does' is pretty close to being common in some parts of the world.
Sorry no, I was referring to the C11 multi threading stuff.
http://en.cppreference.com/w/c/thread
They are not exactly the same as POSIX threads which were standardised in 1995.
Microsoft put in the deprecated warnings long before C11.
Thanks for pointing out that they were made part of C11.
It's a little amusing that MS have this optional part of C11 implemented years in advance and standardised on their work, but haven't got C99 support. It must suit them to have it that way.
Can you tell me whether the C11 Bounds checking stuff from this optional Annex K had fully made it in to GCC 4.9? If not what's missing?
On the status page here it implies the project has had issues:[0]
Clang has "fixit"s for this but they are defined in its checker code, you can't specify custom ones in your own source/header. Though you could probably do so by writing a plugin!
don't worry, i can't do this across /all/ code anymore - some lazy ms monkeys were unkind enough to dump dynamic casts in library headers sometime around 2008.
C-style cast at least doesn't make you pay through the nose in debug time or performance overheads - even if it is easily confusing :)
While there is probably no meaningful use for gets() (which is missing from that list and certainly is not Win32 specific) and maybe sprintf() and even more maybe strcat(), what is exactly so insecure about things like memcpy() or alloca()?
gets is not missing from the list. As for alloca() please see http://blog.exodusintel.com/2013/01/07/who-was-phone/ as an example of how things can go very wrong. memcpy() isn't bad in itself but its easy to get wrong when you're dealing with untrusted user supplied size parameters. memcpy_s is a better alternative because it encourages the developer to think about the size parameters being passed in.
I'm not convinced people should be writing applications in C if they can't call memcpy safely. (I say this not to downplay the many pitfalls of writing correct C, but to suggest that anyone giving less than careful consideration of the arguments to memcpy each time it is used is better off not using C at all -- we have many fine alternatives.)
Short of implementing some kind of drivers license for C coders, I think this is a bad way to look at things. There will always be programs written by people who don't know about buffer overruns, or SQL injection, or just aren't thinking about security at the time because it's a trivial piece of code that "won't make it into a production environment". You can tell them they shouldn't be doing what they are doing all you want, but that doesn't fix the security problem.
Fix the tools, don't blame people for using them as best they know how.
I think there are limits. How do you "fix" assembly language without simultaneously breaking it? The best way to fix C is to use OCaml or Rust or something instead.
I don't disagree, but the fact of the matter is that people do - and even people who know how to use these things safely have been known to make mistakes. Flaws are found in all kinds of software and there is a LOT of C code out there where these functions were and are the cause of serious security flaws.
So sure, you can say that people shouldn't write in C if they can't call memcpy safely, but the truth is that people do and mistakes do get made.
It takes a lot of effort and care to make sure that memcpy is never used to copy data that isn't too large for the destination buffer and there are alternatives like mempcpy and memccpy.
Perhaps, and in some cases memcpy_s can definitely provide peace of mind, but in a large number of invocations of memcpy (most?), the buffer size is either constant or always equal to the source size (because the buffer was just allocated with that size), and it would feel nannying to me to be required to write the same size twice.
Empirically, in my experience, a much higher risk is an integer overflow in the allocation in question. Rather than memcpy_s, I'd prefer a malloc_s that takes a count and element size - like calloc, but without zeroing the buffer, so it doesn't feel like a performance waste to use when that isn't required.
I am actually happy that gcc doesn't find it important to support a library that prevents its users from using functions that are clearly defined in the specification of the language it supports.
I don't understand why functions like gets and sprintf weren't removed from the standard and headers a long time ago. It can't be for legacy reasons, because removing them from the headers has no effect on binaries and when you compile source it should easy to replace gets with fgets and sprintf with snprintfe etc.
gets has no right to exist. But sprintf does. It's a workaround for some old embedded C compilers that lack the safe string copy functions (strcpy_s, strlcpy.)
Which brings it back again to my initial comment:
"I don't understand why functions like gets and sprintf weren't removed from the standard and headers a long time ago."
And by a long time I mean before 1989 (certainly before 1999).
Why should I not be allowed to allocate a buffer that has like 10 or 20 extra characters of space and use a format string with %d in it? Why does sprintf have to be banned?
But banning gets is obvious because it is by definition facing external input
I’m currently doing a school project in C and we wrote a shell script to check every source file for these insecure functions. It displays a warning and suggest you a more secure alternative function.
Yeah, various Blogger themes work fine in Chrome, but break horribly in Firefox on Android. [Though even in Chrome, the performance can be pretty glacial.]
My theory (based purely on using the site, mind you) is that the all the crazy dynamic display stuff in Blogger (before that, it was a much more normal/boring blogging platform) was one last hurrah before the project was relegated to "legacy barely-maintained-mode," and that it hasn't had proper testing in years...
Given that, I think really the best thing would be if they come up with a way to integrate it into Google+ and retire Blogger as a platform. Hopefully they'd add some more features[1] to G+ to keep the functionality roughly equivalent and support the longer-form type of article which is more common on blogs, and keep the domain and blog identities from Blogger around as a thin skin. At least then it would be well maintained.
[1] E.g. better markdown support, multiple embedded images, some sort of easier access to older articles (Blogger lets you browse by year/month), etc.
It turns out there is a project - the safe C library - that implements strcpy_s and friends as an open source library (MIT license). so this header can be used with the Safe C library.
Also interesting: with gcc you can add the -include poison.h command line option; now the poison.h header file is included as the first include of the source file.
-include file
Process file as if "#include "file"" appeared as the first line of the primary source file. However, the first directory searched for file is the preprocessor's working directory instead of the directory containing the main source file. If not found there, it is searched for in the remainder of the "#include "..."" search chain as normal.
If multiple -include options are given, the files are included in the order they appear on the command line.
Can we please, please stop breaking shit that worked just fine in '95?
http://motherfuckingwebsite.com/