Difference between revisions of "371: Compiler Complaint"

Explain xkcd: It's 'cause you're dumb.
Jump to: navigation, search
Line 14: Line 14:
 
A {{w|Segmentation Fault|Segmentation Fault (segfault)}} is an error that occurs when a program attempts to access an invalid section of memory. Segfaults usually cause a program to crash in an ungraceful fashion and fixing them can be difficult.
 
A {{w|Segmentation Fault|Segmentation Fault (segfault)}} is an error that occurs when a program attempts to access an invalid section of memory. Segfaults usually cause a program to crash in an ungraceful fashion and fixing them can be difficult.
  
In the comic, the computer starts talking to the man and compares a segfault with the unpleasant feeling one gets when they experience a {{w|Hypnic jerk||hypnic jerk}}. The computer then tells the programmer to, "Double-check your damn pointers," as segfaults usually arise from a program attempting to access memory that is referenced by an invalid pointer.
+
In the comic, the computer starts talking to the man and compares a segfault with the unpleasant feeling one gets when they experience a {{w|Hypnic jerk|hypnic jerk}}. The computer then tells the programmer to, "Double-check your damn pointers," as segfaults usually arise from a program attempting to access memory that is referenced by an invalid pointer.
  
 
==Transcript==
 
==Transcript==

Revision as of 02:11, 6 December 2012

Compiler Complaint
Checking whether build environment is sane ... build environment is grinning and holding a spatula.  Guess not.
Title text: Checking whether build environment is sane ... build environment is grinning and holding a spatula. Guess not.

Explanation

A Compiler is a program that converts code into machine instructions that a computer can run.

A Pointer is a variable within a computer program that is used to reference a memory location.

A Segmentation Fault (segfault) is an error that occurs when a program attempts to access an invalid section of memory. Segfaults usually cause a program to crash in an ungraceful fashion and fixing them can be difficult.

In the comic, the computer starts talking to the man and compares a segfault with the unpleasant feeling one gets when they experience a hypnic jerk. The computer then tells the programmer to, "Double-check your damn pointers," as segfaults usually arise from a program attempting to access memory that is referenced by an invalid pointer.

Transcript

[A man sits at a computer, hand over the keyboard]
Computer: Okay, human.
Man: Huh?
Computer: Before you hit 'compile,' listen up.
Computer: You know when you're falling asleep, and you imagine yourself walking or something, and suddenly you misstep, stumble, and jolt awake?
Man: Yeah!
Computer: Well, that's what a segfault feels like. <<Pause>> Double-check your damn pointers, okay?


comment.png add a comment! ⋅ comment.png add a topic (use sparingly)! ⋅ Icons-mini-action refresh blue.gif refresh comments!

Discussion

The test "whether build environment is sane" have nothing to do with libraries (those are tested later) or compilation at all (ditto). It seems to test ls and creating new files. Failing this test will surely means lot of problems, but certainly there are other possible sources of problems (some tested later), so not sure why it's labeled this way ... there is probably interresting history behind this.

The test goes like this (example taken from coreutils-5.94):

 { echo "$as_me:$LINENO: checking whether build environment is sane" >&5
 echo $ECHO_N "checking whether build environment is sane... $ECHO_C" >&6; }
 # Just in case
 sleep 1
 echo timestamp > conftest.file
 # Do `set' in a subshell so we don't clobber the current shell's
 # arguments.  Must try -L first in case configure is actually a
 # symlink; some systems play weird games with the mod time of symlinks
 # (eg FreeBSD returns the mod time of the symlink's containing
 # directory).
 if ! (
  set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
  if test "$*" = "X"; then
     # -L didn't work.
     set X `ls -t $srcdir/configure conftest.file`
  fi
  rm -f conftest.file
  if test "$*" != "X $srcdir/configure conftest.file" \
     && test "$*" != "X conftest.file $srcdir/configure"; then
 
     # If neither matched, then we have a broken ls.  This can happen
     # if, for instance, CONFIG_SHELL is bash and it inherits a
     # broken ls alias from the environment.  This has actually
     # happened.  Such a system could not be considered "sane".
     { { echo "$as_me:$LINENO: error: ls -t appears to fail.  Make sure there is not a broken
 alias in your environment" >&5
 echo "$as_me: error: ls -t appears to fail.  Make sure there is not a broken
 alias in your environment" >&2;}
  { (exit 1); exit 1; }; }
  fi
 
  test "$2" = conftest.file
  )
 then
  { { echo "$as_me:$LINENO: error: newly created file is older than distributed files!
 Check your system clock" >&5
 echo "$as_me: error: newly created file is older than distributed files!
 Check your system clock" >&2;}
  { (exit 1); exit 1; }; }
 fi
 { echo "$as_me:$LINENO: result: yes" >&5
 echo "${ECHO_T}yes" >&6; }

-- Hkmaly (talk) 10:15, 17 September 2013 (UTC)

Made slightly more efficient. 173.245.54.31 14:11, 22 March 2014 (UTC)

segfaults

I do not think Randall is suggesting that segfaults are a compiler issue. The insane computer stopped the person before compiling, because this would be the only time that he could change the code to prevent possible segfaults during runtime. -- Flewk (talk) (please sign your comments with ~~~~)

You're totally right; unless it's an interpreter, or the compiler is running some code at compile-time, the compiler will almost never get a segfault itself due to a buggy program. I updated the explanation to clarify this. APerson (talk!) 06:17, 29 October 2018 (UTC)
Reference in the title text

Could the title text be a reference to the ending of the movie "Identitiy" (2003)? SPOILER ALERT - At the end of the movie we see Timmy grinning and holding a spatula just before murdering Paris. And Timmy is very much insane. - END SPOILER Prallax (talk) 21:35, 25 July 2023 (UTC)