murrpurr


/*
 * Copyright (C) 1904-2011 by Anon Y. Mous.
 *
 * Permission to use, copy, modify, and distribute this software and its
 * documentation under the terms of the GNU General Public License is hereby
 * granted. No representations are made about the suitability of this software
 * for any purpose. It is provided "as is" without express or implied warranty.
 * See the GNU General Public License for more details.
 *
 * Documents produced by Doxygen are derivative works derived from the
 * input used in their production; they are not affected by this license.
*/
#include <stdio.h>

int main()
{
    /* this is a highly complex algorithm and you are
       not expected to understand it */
    fprintf(stderr, "Segmentation fault\n");
    return 139;
}

VIP

That's not a segmentation fault. It's also not portable (will not work as expected in Windows or other non-*nix OSes). Here's a real segmentation fault:


/* Useless crap isn't worth a license */
void main()
{
     *(unsigned int *)0 = 0;
}

Which compiles neatly to:

.00401000: C7050000000000000000          mov         d,[0],0
.0040100A: C3                            retn
on x86.

Not that my code is portable in any way. It will not cause a segmentation fault in any OS which lets you write to address 0 (although it may or may not mess up other stuff in that case).

>>3
How is that not portable, Fagotron-2000?

>>4
Since it will never return, I optimized it:
00000000  C606000000        mov byte [0x0],0x0

>>6
fuck you faggot

>>6
Because printing "Segmentation fault" to stderr and returning 139 is the default behaviour on some *nix'es. In other OSes, the behaviour will vary. For example, in Windows, it'll invoke the SEH, then VEH (or other handlers), if those can't handle the access violation error, it will call UnhandledExceptionFilter, which can also be set by the user, but if it's not, it will then display an error or not do anything (depending on settings), or if you have a JIT debugger set, it will launch the debugger neatly allowing you to see what caused the application crash. Other OSes have different ways of handling it as well.

The point is that your program tries to create the illusion that a segmentation fault happened, and this illusion would only work in OSes which actually display such errors and return with that error code. Since this will only produce the required effect in some OSes, it's not portable in the truest sense as while the code is portable, the behavior is not the expected one. Instead, you should generate a real segmentation fault which will give consistent behavior across a wider range of OSes. The problem with generating a real segmentation fault is that you need to know which area of memory is protected (if you're even in an OS which has such a thing, for example you can't cause a segmentation fault/access violation in an application running in x86 real mode (such as DOS), or in various microcontrollers).

>>6,8
イメジボードへ戻れ，糞虫。

>>9
Please post more, disregard >>6.

>>10
Your faggotry level is over 9000, fagotron.

>>10
ヒョウ陰茎。

>>11
Fagotron2k detected.

>>14
DETECT MY ANUS

#!/bin/sh
######### ENTERPRISE PROGRAMMING RIGHT UP IN THIS BITSCH
######### YES BITSCH WITH SCH
######### BECAUSE FUCK YOUR GRAMMAR BULLSCHIT
######### REPLACE SCHIT WITH SCHEISSE
######### BECAUSE SWEARING IN GERMAN IS CRUISE CONTROL FOR ``BETTER THAN YOU''
#########
## BBBB     IIIIII   TTTTTTTTTT    SSSSSSS   ... TOO LAZY TO FINISH
## BB  BB     II         TT      SS
## BB  BB     II         TT      SS
## BBBB       II         TT        SSSSSSS
## BB  BB     II         TT               SS
## BB  BB     II         TT               SS
## BBBB     IIIIII       TT        SSSSSSS
##
echo "Segmentation fault" >&2
exit 139


 int main(void)
 {
     char *s = "hello world";
     *s = 'H';
 }



#include <stdlib.h>
 
int main(int argc, char **argv) {
    int *iptr;
    char *cptr;
 
#if defined(__GNUC__)
# if defined(__i386__)
    /* Enable Alignment Checking on x86 */
    __asm__("pushf\norl $0x40000,(%esp)\npopf");
# elif defined(__x86_64__)
     /* Enable Alignment Checking on x86_64 */
    __asm__("pushf\norl $0x40000,(%rsp)\npopf");
# endif
#endif
 
    /* malloc() always provides aligned memory */
    cptr = malloc(sizeof(int) + 1);
 
    /* Increment the pointer by one, making it misaligned */
    iptr = (int *) ++cptr;
 
    /* Dereference it as an int pointer, causing an unaligned access */
    *iptr = 42;
 
    return 0;
}

>murrpurr
Was this made by a furry?

>>18
It has indentation and int so no, it was not FV.

>Anon Y. Mous.
>Anon
>Y.
>Mous.
Mous.
Definitely not furry

>>20
You're are an evolutionary dead-end clinging to defective monkey culture, while we will adapt and change the world.

>>21
That's exactly what a jew would say.
Also oh god furry too?

>>21

How does it feel posting after people found out you were gay and you ra away to bawh in a corner somewhere? Does it feel good posting now that you let it all out?

>>7

just make it empty:


section .text
  global _start

start:

and let the program counter run out of bounds.

>>24

Nevermind, this seems to not assemble. But you could compile your assembly and check out the binary file, whatever it might be for your platform, and then delete as much as possible, so long as the OS still decides to run it.

>>25
Let me tell you why it won't link (though it will assemble, since it's perfectly valid syntax):

+ You're declaring the label '_start' as global, yet you only define 'start', instead of '_start'.

Also


section .text
    global _start

_start:


$ nasm -f elf proggles.asm 
$ ld proggles.o -o proggles
$ file proggles
proggles: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), corrupted program header size, not stripped
$ ./proggles
bash: ./proggles: cannot execute binary file


Solution (PROTIP: you have to return to the kernel):

section .text
    global _start

_start:
    ret 0x80

>>26

wow, thank you! I'll have to learn more about what happens when a program is run.

>>27
You're welcome. You may address me as sensei-kun

Also, for the sake of completion, writing these kind of things in assembly can be a serious partypooper. don't actually do it for anything else than just4fun/compilerwriting. Please.

>>28
sensei-kun
Mister Master? That makes no sense. >>26-sensei is better.

>>29
Mister Master really sounds like an 80s pop band, or something.

i like it

>>29
Mister Master
Sounds awesome actually.

>>31
Mister Masters
http://www.youtube.com/watch?v=6uZWArSOmCc