Fix my program

[Falcon Kirtaran]

Hello, for an assignment I need to protect my files with a
password. Can anyone please tell me why my C/C++ program is
not working?!!

void main() {
char password[40];
fflush(stdin);
password = gets(NULL);
if (password != "november13") {
10 PRINT "INVALID PASSWORD"
20 BEEP
30 GOTO 10
}
}

Thank you for fixing my program! Also please do not tell
anyone the password, it is copywrited.

-- Nth Complexity --
-- Have A Nice Day! --
"However, these criteria, admirable as they are, are insufficient
for a *liberatory* postmodern science: they liberate human beings
from the tyranny of 'absolute truth' and 'objective reality', but
not necessarily from the tyranny of other human beings. In Andrew
Ross' words, we need a science 'that will be publicly answerable
and of some service to progressive interests.'" -- A.D.S.

(looks for a bat to beat off the troll)

 

[Thad Smith]

Nonsense. Please show me a compiler that would be so stupid to optimize
away the following function:

BOOL foo(void) {
for(iint64_t i=0; i < 0x0FFFFFFFFFFFFFFF; i++)
if (strcmp(DES_encrypt(i,"foo"),"bar")
return TRUE:
return FALSE;
}

I confess that the humor may have been too subtle. Sigh...

I was continuing from Mark's tongue in cheek remark.
The humor's no good if nobody gets it.

Sooooo sorry!

 

[Mark Wooding]

Nonsense. Please show me a compiler that would be so stupid to
optimize away the following function:

BOOL foo(void) {
for(iint64_t i=0; i < 0x0FFFFFFFFFFFFFFF; i++)
if (strcmp(DES_encrypt(i,"foo"),"bar")
return TRUE:
return FALSE;
}

Compile-time evaluation of calls to pure functions comes under the
heading of `partial evaluation', which is, in some circles at least, a
fairly common optimization. Obviously, a compiler which is going to
perform partial evaluation needs to be careful to get stuck doing
computations which

* may take a very long time, or even fail to terminate, and

* whose results won't necessarily be needed at run-time.

The obvious thing to do is just put a time-cap on the computation, and
put off until run-time anything which takes too long.

In practice, I don't know of any C compilers which actually do partial
evaluation without needing heavy-handed prompting. But there's no
reason a sufficiently advanced compiler couldn't.

Of course, I was actually attempting `humour' by suggesting hashing
while leaving the original password in the code. And the more subtle
reason why I chose SHA384 versus (say) SHA1, SHA512 or Whirlpool still
seems to evaded people. ;-)

-- [mdw]

 

[CBFalconer]

Compile-time evaluation of calls to pure functions comes under
the heading of `partial evaluation', which is, in some circles
at least, a fairly common optimization. Obviously, a compiler
which is going to perform partial evaluation needs to be careful
to get stuck doing computations which ...

Why don't you look at the calling code? If TRUE and FALSE are
macros for constants, and the result of the function is never used,
and 'DES_encrypt' is a macro without side-effects, then there is no
point to ever calling the function.

 

[David Thompson]

It's probably worth pointing out that you can improve security by
hashing the passwords. You should probably replace the above with

Not much, but that's a different newsgroup.

something like

if (strcmp(sha384(password), sha384("november13"))) { ... }

<joke=continued>
Assuming the obvious semantics for (nonstandard) sha384(), it will
'return' data that can include zero bytes and thus cannot safely be
treated as a C string. Morever, for it to return pointers as required
here, it must either allocate dynamic space (which is now leaked) or
use static space (which generally won't work right if one call is not
optimized away as suggested downthread).

<ObTopic> There is actually a way to make this sort of thing work:
cycle through an adequate static pool. But that's Horribly Yucky. </>

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Sebastian G.]

Not much, but that's a different newsgroup.

<joke=continued>
Assuming the obvious semantics for (nonstandard) sha384(), it will
'return' data that can include zero bytes and thus cannot safely be
treated as a C string.

C-style string or CString? The latter is always safe, but the cast to a
C-style string isn't required to be implemented.

Morever, for it to return pointers as required
here, it must either allocate dynamic space (which is now leaked) or
use static space (which generally won't work right if one call is not
optimized away as suggested downthread).

Possibility #3: This is C++ with a garbage collector (becoming mandatory in
C++0x).

Anyway, there's no memory leak since the programs ends after a fixed
sequence of instructions.