• Billy Bob (unregistered)

    Scary. Just scary.

    Captcha: doom

    HA!

  • snoofle (unregistered)

    So this is broken-register syndrome? If it fails the first time, do it a few more times to make sure it really takes?

  • (cs)
    His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.
    Error is set on any error, the value depends on its kind and is probably not 1.

    C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

  • Mojohand (unregistered)

    My brain hurts.

  • IV (unregistered)

    I found the problem! the commenter used the wrong form of its. The one written there is the possessive, not the contraction for it is. I'll have to be careful in my comments from now on so I don't end up on this website.

    Captcha: burned.

  • (cs)

    Oh, I see! It should have been:

    if (error)
  while (fprintf(stderr,"An error occured while writing to the file")<0);

    That's much cleaner...

  • CrystalMethod (unregistered)

    This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

    captcha: I'm not telling you

  • Shi-Killer (unregistered)

    This could be worse. The system I'm testing atm used to log any kind of errors to the windows eventlog. Even if the error is that it doesn't have the rights to write to the windows eventlog....

    I've never seen logfiles (the redundant log-method) being written that fast :)

  • (cs) in reply to Mcoder
    Mcoder:
    His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.
    Error is set on any error, the value depends on its kind and is probably not 1.

    C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

    In my military-subcontractor days, I once saw someone actually do something like this (on a system that could run interactively, or as a headless daemon):

    // paraphrasing...
try {
    // ...
} catch (Exception e) {
  try {
      // write error to message queue
  } catch (MessageQueueException mqe) {
    try {
        // write error to message log
    } catch (IOException ioe) {
      // log file not accessible
      try {
          // print to stderr
      } catch (Throwable t1) {
        // Someone closed 2: might be running as daemon
        try {
            // print to stdout
        } catch (Throwable t2) {
          // Someone closed 1: might be running as daemon
          // intentionally do a divide-by-zero error
          // to force underlying system to puke
        }
      }
    }
  }
}

    This was repeated in every single place where an error occurred. It could have been done once in a common block of error handling code. <Sigh/>

  • Eduardo Habkost (unregistered) in reply to Mcoder
    Mcoder:
    His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.
    Error is set on any error, the value depends on its kind and is probably not 1.

    I think you are confusing 'error' with 'errno'.

  • CrystalMethod (unregistered) in reply to bstorer
    bstorer:
    Oh, I see! It should have been: 
    if (error)
  while (fprintf(stderr,"An error occured while writing to the file")<0);

    That's much cleaner...

    No, no. You want to spawn a thread on each pass of the loop - what else are all these SMP and multicore machines for?

  • CrystalMethod (unregistered) in reply to snoofle
    snoofle:
    Mcoder:
    His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.
    Error is set on any error, the value depends on its kind and is probably not 1.

    C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

    In my military-subcontractor days, I once saw someone actually do something like this (on a system that could run interactively, or as a headless daemon):

            } catch (Throwable t2) {
          // Someone closed 1: might be running as daemon
          // intentionally do a divide-by-zero error
          // to force underlying system to puke
        }

    This was repeated in every single place where an error occurred. It could have been done once in a common block of error handling code. <Sigh/>

    Not to mention printing a stacktrace from the original exception and calling System.exit(1); rather than forcing a divide by zero.

  • Duston (unregistered)

    I don't see where it logs "File Not Found"

  • (cs) in reply to CrystalMethod
    CrystalMethod:
    snoofle:
    Mcoder:
    His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.
    Error is set on any error, the value depends on its kind and is probably not 1.

    C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

    In my military-subcontractor days, I once saw someone actually do something like this (on a system that could run interactively, or as a headless daemon):

            } catch (Throwable t2) {
          // Someone closed 1: might be running as daemon
          // intentionally do a divide-by-zero error
          // to force underlying system to puke
        }

    This was repeated in every single place where an error occurred. It could have been done once in a common block of error handling code. <Sigh/>

    Not to mention printing a stacktrace from the original exception and calling System.exit(1); rather than forcing a divide by zero.

    Well, it's kind of a mixed bag. If it was running as a daemon, simply printing a stack trace wouldn't work as stdout/error would have been closed, thus leaving no place for the trace to be printed. However, the way they attempted to handle it in those cases was admittedly inept.

  • MadJo (unregistered) in reply to Duston
    Duston:
    I don't see where it logs "File Not Found"
    true... or false...

    Captcha: Wigwam. basically the same shape as a pyramid, but easier built. :)

  • Someone (unregistered) in reply to CrystalMethod
    CrystalMethod:
    This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

    Then why does the NetBSD manpage on fprintf contain this:

    Upon successful completion printf(), fprintf(), vprintf(), and vfprintf() return the number of characters printed. Otherwise a negative value is returned and errno is set to indicate the error.
  • (cs) in reply to CrystalMethod
    CrystalMethod:
    bstorer:
    Oh, I see! It should have been: 
    if (error)
  while (fprintf(stderr,"An error occured while writing to the file")<0);

    That's much cleaner...

    No, no. You want to spawn a thread on each pass of the loop - what else are all these SMP and multicore machines for?

    You're right! My code is horribly inefficient. Let's fix it:

    if (error)
  while (fprintf(stderr,"An error occured while writing to the file")<0)
    fork ();

    That's much better. But maybe we should add a sleep statement in there, because any error with stderr is bound to be fixed in, say, 30 seconds:

    if (error)
  while (fprintf(stderr,"An error occured while writing to the file")<0)
  {
    fork ();
    sleep (30);
  }
  • moe (unregistered)

    The REAL WTF is ...

    everyone: ASL???

    Paula, No Quack! VB Wooden Table

    Step 1: Underwear Step 2: Step 3: Profit!

    captcha: wigwam

  • (cs) in reply to bstorer
    bstorer:
    CrystalMethod:
    bstorer:
    Oh, I see! It should have been: 
    if (error)
  while (fprintf(stderr,"An error occured while writing to the file")<0);

    That's much cleaner...

    No, no. You want to spawn a thread on each pass of the loop - what else are all these SMP and multicore machines for?

    You're right! My code is horribly inefficient. Let's fix it:

    if (error)
  while (fprintf(stderr,"An error occured while writing to the file")<0)
    fork ();

    That's much better. But maybe we should add a sleep statement in there, because any error with stderr is bound to be fixed in, say, 30 seconds:

    if (error)
  while (fprintf(stderr,"An error occured while writing to the file")<0)
  {
    fork ();
    sleep (30);
  }
    .

    Ahem... (Ok, I am intermixing C and Java here, but still):

    if (error) {
  try {
      while (fprintf(stderr,"An error occured while writing to the file")<0)
        {
          fork ();
          sleep (30);
        }
  } catch (IOException ioe) {
    // stdout has been closed: file-not-found!
  }
}
  • Harry (unregistered) in reply to Duston
    Duston:
    I don't see where it logs "File Not Found"

    If the log file is not found, how can you expect to see it?

  • Jonathan (unregistered)
    You might [?] that this would prevent these forces from interacting with computers

    You might what?

  • (cs) in reply to snoofle
    snoofle:
    So this is broken-register syndrome?

    Sorry, is that an actual term? I can't find it anywhere, but it sounds interesting.

  • (cs)

    If at first you don't succeed....failure is probably your style. http://www.despair.com/los24x30prin.html

  • Rich (unregistered) in reply to CrystalMethod
    my favourite is the belief that fprintf returns less than zero on error.
    This is actually true. My Linux manpage and BSD (from the BSD man page CGI) confirm it. This is an ANSI function, so i assume it would be the same everywhere.
    on failure it sets errno.
    Technically true, but one could read this to say you don't need to check return values, just check errno. errno could be set on any subfunction calls (maybe i'm writing to a socket, and it returns EAGAIN?). You should check return first, then if it indicates failure, only then look at errno.

    captcha: xevious i hated that game

  • Alan (unregistered)

    The real WTF is that he hasn't got any newline characters in what gets printed!

  • (cs) in reply to Jonathan
    Jonathan:
    You might [?] that this would prevent these forces from interacting with computers

    You might what?

    It's a madlib. I read it as "tapdance". "You might tapdance that this would prevent these forces from interacting with computers." Now it makes total sense.

  • EmmanuelD (unregistered) in reply to bstorer

    That's no longer a pyramid! It can't work!

  • John (unregistered) in reply to CrystalMethod
    CrystalMethod:
    This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

    ... and returns a negative number. (see man fprintf)

    john

  • EmmanuelD (unregistered) in reply to Alan

    I guess that the really real WTF is that I still don't understand why people try to catch some real WTF in what is obviously a really real WTF. To me, such a behavior is really a really real WTF, not just a real Really Worse Than Failure.

    I'm not sure I'm clear.

  • (cs) in reply to Mcoder
    Mcoder:
    C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

    The potential for such a crock is there in any language, really.

  • EmmanuelD (unregistered) in reply to Harry
    Harry:
    Duston:
    I don't see where it logs "File Not Found"

    If the log file is not found, how can you expect to see it?

    The solution is to put it like this:

    /* log("file not found"); */

    Should work well (without producing any error).

  • iToad (unregistered) in reply to Mcoder
    Mcoder:
    His reward was the understanding that error is set to 1 when any error occurs, not just file i/o errors.
    Error is set on any error, the value depends on its kind and is probably not 1.

    C has a lot of potential for bad code, but logging to stderr that it failed to log on stderr is really creative.

    Is this an example of recursive error logging???

  • man page reader (unregistered) in reply to CrystalMethod

    I am reading the Linux man page of fprintf(). It says: Upon successful return, these functions return the number of characters printed. If an output error is encountered, a negative value is returned.

    What happpens if it is possible the write the first half, but there is an error with the second half, is undefined.

  • LizardKing (unregistered) in reply to Volmarias
    Volmarias:
    snoofle:
    So this is broken-register syndrome?

    Sorry, is that an actual term? I can't find it anywhere, but it sounds interesting.

    It's a hacker joke - the author of code that repeatedly does something stupid pretends that it's trying to avoid a "broken register" in the CPU, hence the multiple executions. It's probably in the Hacker's Dictionary / Jargon File unless that numbnuts Eric Raymond has changed it to something about how great guns are.

  • (cs)

    Kind of like locking your keys INSIDE to keep them safe.

  • AnonymousCoward (unregistered)

    At least he optimized the loop!

  • ComputerForumUser (unregistered) 
    void LogError(char *error)
{
    if (fprintf(stderr,error)<0)
    {
        char fmt = "Error logging error '%s' to error log\n";
        char *s = malloc(strlen(fmt) + strlen(error));

        if (s == NULL)
            LogError("Error allocating memory to log an error logging an error; the error could not be logged\n");

        sprintf(s, fmt, error);

        // log the error
        LogError(s);

        // clean up after ourselves so that we never cause a massive memory leak
        free(s);
    }
}
  • (cs) in reply to EmmanuelD
    <quote> /* log("file not found"); */ </quote>

    should definitely work well but we have to think of the gas machines from the steel factory

  • Andrew (unregistered) in reply to CrystalMethod
    CrystalMethod:
    This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

    captcha: I'm not telling you

    This is not true. If the printf() family of functions has internal errors, then they return a negative value. Sometimes, they print less than the intended amount, and the return value is the truncated number of characters.

    In any case, the system has crashed when stderr stream is not available.

  • GRH (unregistered)

    As soon as I saw this I said "Worse Than Failure!!!". Oh, no, I guess not - I probably said "What the F***".

  • pkh (unregistered) in reply to LizardKing

    Yeah, except that it's not a joke. One chip in the one of HW platforms I've worked on had a bug where writes to a particular register would fail somewhere between 1% and 10% of the time, completely at random. The failure to set this register correctly wasn't awful, but a temporary loss of functionality.

    What made it worse was that it was a register that we wrote to to invoke some processing on the chip, and the first thing the chip would do would be to clear the register, so we couldn't read it back. Fortunately, writing the register multiple times was completely safe, so we worked around it by writing six times in a row.

    The explanation for this behavior was very well commented.

  • zmafoo (unregistered) in reply to CrystalMethod

    I'm not sure what language you're using, but in C fprintf returns a negative value if an output or encoding error occurred (ANSI ISO IEC 9899-1999 7.19.6.1 paragraph 14

  • (cs)

    The "guru" must really want to make sure it failed. The C libs really leave room for obfuscation.

  • (cs)

    if (error) if (fprintf(stderr,"All work and no play makes Jack a dull boy")<0){ if (fprintf(stderr,"all Work And No Play Makes jack A Dull Boy")<0){ if (fprintf(stderr,"All work")<0 && fprintf(stderr,"no Play Makes jack A Dull Boy")<0){ if (fprintf(stderr,"All work")<0 && !fprintf(stderr,"Play Makes jack A Dull Boy")<0){ return fprintf(stderr, "An error occured while writing to stderr"); /* lets stop here, its enough */ } } } }

  • (cs) in reply to Rich
    Rich:
    on failure it sets errno.
    Technically true, but one could read this to say you don't need to check return values, just check errno. errno could be set on any subfunction calls (maybe i'm writing to a socket, and it returns EAGAIN?). You should check return first, then if it indicates failure, only then look at errno.

    In fact, I'm not even sure if just checking errno is valid. I'm under the impression that if a function succeeds what it does to errno is undefined, so you can't rely on it being a specific value when it comes out. It could set errno when it succeeds in other words.

    Ignoring practical concerns about if this would ever happen in real code (I'm an academic ;-)), am I right about this? It's been a while.

  • Jeff (unregistered)

    I call BS. This kind of monstrosity could only have been created in VB, because all C/C++/C# developers write amazingly tight, readable & otherwise immaculate code. :p

    Jeff

  • (cs) in reply to snoofle
    snoofle:
    In my military-subcontractor days, I once saw someone actually do something like this (on a system that could run interactively, or as a headless daemon): 
    // paraphrasing...
try {
    // ...
} catch (Exception e) {
  try {
      // write error to message queue
  } catch (MessageQueueException mqe) {
    try {
        // write error to message log
    } catch (IOException ioe) {
      // log file not accessible
      try {
          // print to stderr
      } catch (Throwable t1) {
        // Someone closed 2: might be running as daemon
        try {
            // print to stdout
        } catch (Throwable t2) {
          // Someone closed 1: might be running as daemon
          // intentionally do a divide-by-zero error
          // to force underlying system to puke
        }
      }
    }
  }
}
    I've seen something similar, though not identical. The lead programmer was a true font of WTFs; among them was his invention of his own logging system. Every logging call could throw an exception, so he often had code like this: 
    try {
  myBrillantLogger.log("Something failed");
} catch (Exception e) {
  try {
    myBrillantLogger.log("Something failed");
  } catch (Exception e) {
    try {
      myBrillantLogger.log("Something failed");
    } catch (Exception e) {
      try {
        myBrillantLogger.log("Something failed");
      } catch (Exception e) {
        // I'm not sure what do.  Can't do this forever, right?
      }
    }
  }
}
    We used to gather 'round a monitor and snicker when he wasn't around.
  • adam (unregistered)

    This code truly is enlightened! The output of fprintf(stderr,"An error occured while writing to stderr") is 42.

  • Matt (unregistered) in reply to CrystalMethod
    CrystalMethod:
    This code is so naff, but my favourite is the belief that fprintf returns less than zero on error. fprintf returns the number of characters printed - on failure it sets errno.

    Actually, a negative value must be returned if there is an output or encoding error. The only way you'd get zero returned is if your input string actually specified no characters, eg. fprintf(fp, "%s", "");

    (Otherwise the system does not conform to the C standard).

    Also, whether or not errno is set is up to the individual system, you certainly should not write code that relies on it to detect success or failure.

  • Onaka The Kaka (unregistered)

    At least the code was well indented, well commented and easy to read!:-)

Leave a comment on “The Pyramid of Error”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article