GCC Poison | Hacker News Reader

GCC Poison

blog.leafsr.com

89 pointsglazskunrukitis70 comments

Open articleView on HN

Somewhat off-topic, but I can't use my back-button to get off this page.

Can we please, please stop breaking shit that worked just fine in '95?

http://motherfuckingwebsite.com/

+1. Seriously. Is this from circular redirects? faulty browser plugin?

While we are at it, if a site needs tweaking of noScript settings for displaying text...

Did you seriously load 22kb of Google Analytics because you weren't strong enough to truly uphold your ideals? You piece of shit.

(to prevent confusion: this is a parody of the site MBlume linked)

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).

It's funny because "degrade gracefully" was the standard for a very long time as javascript blew up in popularity.

Now the pioneer of JS apps doesn't even bother trying to put <noscript>There is usually a blog post here if you are using javascript</noscript>

and I don't bother to use such sites. I think I can pass up this content.

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.

Depending on the type of redirect, that is how it works.

there has been websites breaking the back button forever... this isn't new.

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.

Is this like the first time you've read a Blogger blog in years? Google mandated the Javascript nonsense quite some time ago.

Because I feel your pain, I wrote you a quick, dirty fix.

  # how to fetch a blogger.com blog 
  # without the gratuitous javascript
  # usage: nameofthisfile blog.whatever.com > html_file

  #! /bin/sh
  case $# in
  1)

  {
  a=${1%%/*}
  printf "%b" "GET / HTTP/1.1\r\n"; 
  printf "Host: ${a##http://}\r\n"; 
  printf "Connection: Close\r\n";
  printf "\r\n";
  } \
  |nc -vv $1 80 \
  |sed '
  /targetBlogID/!d;
  s/.*targetBlogID=//;
  s/&.*//;
  ' \
  |while read a
  do
  {
  printf "%b" "GET /feeds/$a/posts/default HTTP/1.1\r\n"; 
  printf "Host: www.blogger.com\r\n";
  printf "Connection: Close\r\n";
  printf "\r\n";
  } \
  |nc -vv www.blogger.com 80 \
  |sed '
  s/&lt;/</g;
  s/&gt;/>/g;
  s/&amp;/\&/g;
  s/&quot;/\"/g;
  1i\
  <br><br>

  s/<name>/<br><br>name &/g;
  s/<uri>/<br>uri &/g;
  s/<generator>/<br>generator &/g;
  s/<id>/<br>id &/g;
  s/<published>/<br>published &/g;
  s/<email>/<br>email &/g;
  s/<title type=.text.>/<br><br>&/g;
  s/<openSearch:totalResults>/<br>total results &/g;
  s/<openSearch:startIndex>/<br>start index &/g;
  s/<openSearch:itemsPerPage>/<br>items per page &/g;
  s/<updated>/<br>updated &/g;
  s/<thr:total>/<br>thr:total &/g;
  s/<\/feed>/&<br><br><br>/;
  '
  done
  ;;
  *)
  echo usage: $0 blog.whatever.com >&2
  esac

Thank you very much. Your script does the trick. I was able to read the blog without enabling JavaScript for that site.

You're most welcome. What OS are you using?

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:

http://unspecified.wordpress.com/2009/05/16/microsoft-bans-m...

memcpy_s:

http://msdn.microsoft.com/en-us/library/dswaw1wk(v=vs.80).as...

edit: I read the link you included and I have to take exception with this line:

    it’s a perfectly safe function if you use
    it properly

Sure, same thing as automobiles, alcohol, condoms… Problems arise because people do not use them correctly.

LOL, That's a fucking joke!

"If the source and destination overlap, the behavior of memcpy_s is undefined."

Wow, way to improve things microsuck! It's not like anyone has ever mistakenly used memcpy on overlapping buffers....

You can use memmove_s, you know.

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.

"memcpy should be fast"

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.

Am gobsmacked by the differences in benchmarks:

http://nadeausoftware.com/articles/2012/05/c_c_tip_how_copy_...

http://software.intel.com/en-us/articles/memcpy-performance

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. :)

I did say "should" :D

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.

Microsoft led the standardization process for the Annex K functions.

> 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.

They also 'standardised' threads which were hardly common usage.

> They also 'standardised' threads which were hardly common usage.

Didn't the POSIX standard do that, as opposed to the ANSI C standard?

Well, yes, for operating systems that implement POSIX. Which doesn't account for all of them, last I checked.

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]

[0]http://gcc.gnu.org/wiki/C11Status

Yet, on the release notes it says "Substantially complete" but it's really as clear as mud whether it's all there[2].

[2]http://gcc.gnu.org/gcc-4.9/changes.html

I suppose that on Linux and Windows the intel compiler relies on the GCC/MS implementation of memcpy_s.

This header would be much more useful if it suggested safe alternatives for each of the functions it poisions

Has GCC got the necessary pragma foo to implement this?

Probably not, but could put comments in the header?

one of my favourite old school tricks for achieving such breakery is:

#define const_cast CONST_CAST_IS_FORBIDDEN #define dynamic_cast DYNAMIC_CAST_IS_NEVER_NECESSARY

etc...

its dirty, but it gets the job done

Then I'll just use a C-style cast. :P

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 :)

if it does, it should be called antidote.

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!

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()?

Buffer overflows

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.

Yeah... if only I could get an OCaml compiler for my micro...

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.

Hmm, so a function similar to fread, but reading from another buffer instead of a file.

You can actually use fread on a buffer after opening it with fmemopen(). (POSIX).

I'd rather just do the overflow checking before arithmetic.

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 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.

These functions have no right to exist.

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.)

    char dst[5];
    sprintf(dst, "%.*s", (int)sizeof(dst)-1, "Hello!");

Copies a null-terminated string to dst, truncating if necessary to avoid overflow.

Just don't forget the "." or the "-1".

That code is just as easily converted to use snprintf, and then you don't need to worry about the . Or -1.

snprintf is C99 IIRC. Which means legacy C89 compilers (or worse!) don't have it.

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

it should always be optional, just like the ms implementation, also this is part of a standard too...

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.

this site is unusable on my phone.the sidebar dominates the screen.

Which phone?

(It is perfect with no sidebar on Dolphin/Note 2. Arstechnica on the other hand has been broken for a few days already.)

Firefox on Kyocera Torque

It works fine on chrome for android

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.

https://sourceforge.net/projects/safeclib/

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.

http://linux.die.net/man/1/gcc

-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.

Good! I had never ignored that unsafe notices from visual studio console.

Reply on news.ycombinator.com