On Thu, 01 May 2008 17:30:35 +0100, Doctor John wrote:

> http://www.computerweekly.com/blogs/it-downtime-blog/2008/04/error-
messages-you-never-want-1.html
> 
> :-)

I still prefer the one I got from Windows + a biometric scanner (during 
GINA login):  "An error occurred:  The operation was successful".  Oh, 
and it wouldn't log me in (I wish I could've gotten a screenshot)

Jim

Post a reply to this message

On Thu, 01 May 2008 19:27:54 +0100, Orchid XP v8 wrote:

> [BTW, WTF is an *expected* error anyway??]

In eDirectory, it's not uncommon to see -601 errors (object not found) in 
a number of circumstances, and in some of those circumstances, the error 
is expected (such as a user mistypes their username).

Jim

Post a reply to this message

>> BTW, irony: At college, we had a C compiler that used to give us all 
>> this error message, and to this day nobody knows what that message 
>> actually means. Including the tutors. Hmm. ;-)
> 
> Yay for open source. You could have looked into the compiler code :)

Nah. Today I can just ask Warp what it means. ;-)

Hey Warp, what does it mean when you call printf() and the compiler says 
"suspicious pointer conversion"?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Hey Warp, what does it mean when you call printf() and the compiler says 
> "suspicious pointer conversion"?

  Difficult to say without seeing the actual code.

-- 
                                                          - Warp

Post a reply to this message

Jim Henderson wrote:

> I still prefer the one I got from Windows + a biometric scanner (during 
> GINA login):  "An error occurred:  The operation was successful".  Oh, 
> and it wouldn't log me in (I wish I could've gotten a screenshot)

Well *clearly* a Windows operation being successful would indicate an 
error; Windows operations are designed to _fail_. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Hey Warp, what does it mean when you call printf() and the compiler says 
>> "suspicious pointer conversion"?
> 
>   Difficult to say without seeing the actual code.

OK, well obviously 10 years later I don't still have it. All I can 
remember is that *loads* of people used to get this error. And it always 
seemed to involve printf().

I also remember that several people found that when you run their 
compiled program, it dumps many, many pages of gibberish to the console, 
and beeps repeatedly, until [if you're lucky] it would randomly stop. 
Presumably this is because you gave printf() an int when it was 
expecting a char*, and it's now printing out the contents of the 
machine's RAM until it happens upon a zero octet... (The deeps are due 
to the 0x07 BEL characters.)

I presume this doesn't work on a protected-mode OS?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I presume this doesn't work on a protected-mode OS?

  Well, the program has some memory allocated for itself, so if the pointer
happens to point to such memory, it will print gibberish. If it points to
unallocated memory you get a segmentation fault.

  The C++ version of printing to stdout (or to a stream) is much safer
from this point of view. (While you *can* make it behave the same way,
it's much harder to do so accidentally.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I presume this doesn't work on a protected-mode OS?
> 
>   Well, the program has some memory allocated for itself, so if the pointer
> happens to point to such memory, it will print gibberish. If it points to
> unallocated memory you get a segmentation fault.

Right. Thought so...

>   The C++ version of printing to stdout (or to a stream) is much safer
> from this point of view. (While you *can* make it behave the same way,
> it's much harder to do so accidentally.)

I don't really know C++, but from what little I've seen printing *looks* 
safer...


OOC, how does C do argument passing? [I'm puzzled as to why it's 
possible for a function with variable arguments to exist.]

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I don't really know C++, but from what little I've seen printing *looks* 
> safer...

  It's more modular too. For example, assume you have abstracted away
a type like this:

typedef int MyType;

  And somewhere else in the code you have something like:

MyType value = something;
printf("The value is: %i\n", value);

  That 'printf' assumes the type is an integer. What happens if you later
change the type? For example like:

typedef double MyType;

  What happens is that the printf breaks horribly and will print gibberish.

  That won't happen using the C++ style:

MyType value = something;
std::cout << "The value is: " << value << "\n";

  Now if the value type changes the output will still be correct.

> OOC, how does C do argument passing? [I'm puzzled as to why it's 
> possible for a function with variable arguments to exist.]

  The C standard (and consequently the C++ standard) defines a special
mechanism for passing a variable amount of arguments to a function.
Simply put, you can declare a function like:

void foo(...);

and then you can call it like:

foo(any, amount, of, arguments, you, want);

  Of course C being C, there's no way for the function to know how many
arguments were passed and what was their type. printf() solves this with
the format string given as first parameter. (And its problem is, of course,
that it simply trusts that the amount and type of the arguments corresponds
to the given format string.)

  The C standard defines special macros which can be used inside foo() to
retrieve the given arguments.

  From the compiler's point of view the implementation of this is rather
simple: All the function parameters are pushed onto the stack, and then
the foo() function simply pops them from the stack. But as I said, there's
no type checking nor anything. It's all just "raw". (But it's not like
there wouldn't be *any* advantage at all in this: The advantage is, of
course, that it's quite fast and memory-efficient to do it this way.)

-- 
                                                          - Warp

Post a reply to this message

On Fri, 02 May 2008 09:02:45 +0100, Invisible wrote:

> Jim Henderson wrote:
> 
>> I still prefer the one I got from Windows + a biometric scanner (during
>> GINA login):  "An error occurred:  The operation was successful".  Oh,
>> and it wouldn't log me in (I wish I could've gotten a screenshot)
> 
> Well *clearly* a Windows operation being successful would indicate an
> error; Windows operations are designed to _fail_. ;-)

That was my thinking; the MS consultants who were there were absolutely 
beside themselves trying to figure out what was going on.

Jim

Post a reply to this message