Warp wrote:
>   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. 

Well, technically, the foo() function indexes into the stack (with a 
compiler-provided macro to move the stack pointer into a pointer 
variable, basically), and then whoever called foo() has to pop the 
arguments. Which is one reason you don't see many "ret N" instructions 
in compiled C code - the callee never knows how many arguments the 
caller pushed.  (Altho you'd think that's something the compiler could 
optimize if you didn't have a variable numbers of arguments for a 
particular function.)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

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

FWIW, that usually happens when a function returns an error indication 
but doesn't set the secondary information that says what error it was. 
Or, in C terminology, the function returned -1 but didn't assign 
anything to errno.   Yet one more reason to dislike C. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message

On Fri, 02 May 2008 09:53:59 -0700, Darren New wrote:

> Jim Henderson wrote:
>> That was my thinking; the MS consultants who were there were absolutely
>> beside themselves trying to figure out what was going on.
> 
> FWIW, that usually happens when a function returns an error indication
> but doesn't set the secondary information that says what error it was.
> Or, in C terminology, the function returned -1 but didn't assign
> anything to errno.   Yet one more reason to dislike C. :-)

Oh, yes, I do know that side of the coding - but that didn't make it any 
less funny, especially to see the MS consultants (and I'm not saying 
"Consultants who consult on Microsoft technologies", but "Microsoft 
Consulting") try to figure that one out. :-)

Jim

Post a reply to this message

"Jim Henderson" <nos### [at] nospamcom> wrote in message
news:481b5695@news.povray.org...
> On Fri, 02 May 2008 09:53:59 -0700, Darren New wrote:

> (and I'm not saying
> "Consultants who consult on Microsoft technologies", but "Microsoft
> Consulting")

I've worked with some guys from MCS before. Some are really good. Others are
.... not so good. (to put it politely)

Post a reply to this message

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_. ;-)
> 
My interpretation was that because an error occurred the process could 
not validated your login, hence it should not log you in and indeed it 
was successful at not letting you in. In my opinion it is thus a 
correct, though slightly confusing, message.

Post a reply to this message

On Fri, 02 May 2008 20:23:38 +0200, Gail Shaw wrote:

> "Jim Henderson" <nos### [at] nospamcom> wrote in message
> news:481b5695@news.povray.org...
>> On Fri, 02 May 2008 09:53:59 -0700, Darren New wrote:
> 
>> (and I'm not saying
>> "Consultants who consult on Microsoft technologies", but "Microsoft
>> Consulting")
> 
> I've worked with some guys from MCS before. Some are really good. Others
> are .... not so good. (to put it politely)

The guys I worked with were pretty good - and they did appreciate the 
humour of the situation. :-)

Jim

Post a reply to this message

On Fri, 02 May 2008 21:17:36 +0200, andrel wrote:

> 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_. ;-)
>> 
> My interpretation was that because an error occurred the process could
> not validated your login, hence it should not log you in and indeed it
> was successful at not letting you in. In my opinion it is thus a
> correct, though slightly confusing, message.

That's possible - Digital Persona (whose stuff we were using) had 
absolutely no idea what the issue was.  We ended up rebuilding the 
machine - it borked things up so badly that even booting in safe mode 
didn't work (ISTR we ended up with no ability to login at all even in 
safe mode).

Jim

Post a reply to this message

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_. ;-)
> 

I actually saw a couple of programming languages designed around that 
concept.  One of them was termed "quantum", in that any operation in it 
had a 90% chance of success, and a 10% chance of alternative behavior.

The other language was designed such that all program logic was 
controlled through purposefully causing errors.

I don't remember the name of either language, but I'm sure others here do.

...Chambers
www.pacificwebguy.com

Post a reply to this message

Warp wrote:

>  default:
>     error("Unexpected error happened.");
>     // This should never happen because all possible cases were dealt above.
>     // If we ever get here, it's a clear sign of a bug in the program.

or of memory corruption. :-)

Where I work, most default cases mean: "stop the train".

--
Jonathan.

Post a reply to this message

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

Here's something I've been wondering about that. Say you have your own 
type, and you want a set of flags like hex/oct/decimal or setfill or 
something like that. I.e., you want to be able to say

std::cout << prettyprintindent(4) << myvalue << "\n";

Where does the "4" there get stored? And how can you make it so that 
(say) passing -1 puts back what it was before the previous call for the 
same stream? It would seem that you'd need some sort of data structure 
mapping streams to pretty print indent levels, yes? And no automated way 
of cleaning that up with a destructor?

What am I missing here?




Incidentally, I've seen the problem with printf that you're talking 
about here solved by doing something like this:

typedef long MyInt;
#define MyIntPrintf "%l"

Then, you write something like
   MyInt counter;
   printf("I counted " MyIntPrintf " instances\n", counter);
so it's really not that much harder to change, if at all.

-- 
   Darren New / San Diego, CA, USA (PST)
     "That's pretty. Where's that?"
          "It's the Age of Channelwood."
     "We should go there on vacation some time."

Post a reply to this message