
GCC Poison - glazskunrukitis
http://blog.leafsr.com/2013/12/gcc-poison.html#
======
MBlume
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/](http://motherfuckingwebsite.com/)

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

~~~
dmix
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>

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

------
eliasmacpherson
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...](http://unspecified.wordpress.com/2009/05/16/microsoft-bans-memcpy/)

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

~~~
comex
They were Microsoft functions long (6 years?) before they were standardized.

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

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

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

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

~~~
eliasmacpherson
Sorry no, I was referring to the C11 multi threading stuff.
[http://en.cppreference.com/w/c/thread](http://en.cppreference.com/w/c/thread)
They are not exactly the same as POSIX threads which were standardised in
1995.

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

~~~
hsmyers
Has GCC got the necessary pragma foo to implement this?

~~~
jheriko
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

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

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

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

~~~
dkersten
Buffer overflows

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

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

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

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

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

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

~~~
finnw
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".

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

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

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

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

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

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

~~~
aidenn0
Firefox on Kyocera Torque

------
MichaelMoser123
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/](https://sourceforge.net/projects/safeclib/)

~~~
MichaelMoser123
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](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.

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

