Fix my program

[CBFalconer]

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];

The above line is unique. Apart from lines with only a lone '}',
it is the only line in the program without an obvious error.

fflush(stdin);
password = gets(NULL);
if (password != "november13") {
10 PRINT "INVALID PASSWORD"
20 BEEP
30 GOTO 10
}
}

 

[Thad Smith]

Wouldn't "november13" still exist in the executable? Unless sha384 is some
clever macro?

When <sha384.h> is included, sha384() computes the hash of the string
literal at compile time, but the hash of password at run time, since it
points to a run-time variable.

 

[Sebastian G.]

When <sha384.h> is included, sha384() computes the hash of the string
literal at compile time, but the hash of password at run time, since it
points to a run-time variable.

A optimizing compiler may decide to not optimize away any sufficiently
complex calculation.

 

[Thad Smith]

A optimizing compiler may decide to not optimize away any sufficiently
complex calculation.

Obviously such a compiler is not up to the task!

 

[Sebastian G.]

Obviously such a compiler is not up to the task!

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;
}

 

[CBFalconer]

Wouldn't "november13" still exist in the executable? Unless sha384
is some clever macro?

Perhaps encrypted in a separate program and the result put in here.

And obviously sha384 has nothing to do with the C language,
inasmuch as it never appears in any C standard. Followups have
been set to eliminate c.l.c, where this is off-topic.

 

[Chris Dollin]

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;
}

As the previous poster said, /such a compiler/ may not be up to the task
/of compile-time evaluation of/ `sha384` from the possibly-built-in-as-
suggested-by-the-<> `<sha384.h>.

A compiler that decides it cannot do X is -- obviously -- not up to
the task of doing X.

 

[Mark Wooding]

When <sha384.h> is included, sha384() computes the hash of the string
literal at compile time, but the hash of password at run time, since it
points to a run-time variable.

Indeed.

(Of course, the real question is why I chose SHA384 of all things...)

-- [mdw]

 

[Sebastian G.]

Chris Dollin wrote:

As the previous poster said, /such a compiler/ may not be up to the task
/of compile-time evaluation of/ `sha384` from the possibly-built-in-as-
suggested-by-the-<> `<sha384.h>.

<> only means that the included header should be searched in the default
search path, nothing more. And there's absolutely no indication that the
definition it contains might be suitable, much less feasible for
compile-time evaluation.

A compiler that decides it cannot do X is -- obviously -- not up to
the task of doing X.

See the example above. Even though the compile could do it, may have very
good reason not to do so; especially if it involves running a part of the
code itself, machine-specific implementation details.

 

[Richard Heathfield]

CBFalconer said:

And obviously sha384 has nothing to do with the C language,
inasmuch as it never appears in any C standard. Followups have
been set to eliminate c.l.c, where this is off-topic.

Whoosh!

 

[Richard Tobin]

And obviously sha384 has nothing to do with the C language,
inasmuch as it never appears in any C standard. Followups have
been set to eliminate c.l.c, where this is off-topic.

Er, this whole thread is just responses to a troll, or perhaps a joke,
and is no more on- or off-topic in comp.lang.c than anywhere else. If
you don't find it funny, just don't respond to it, and eventually it will
die out.

-- Richard

 

[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!

 

[Chris Dollin]

Chris Dollin wrote:



<> only means that the included header should be searched in the default
search path, nothing more. And there's absolutely no indication that the
definition it contains might be suitable, much less feasible for
compile-time evaluation.

From an earlier post:

That's an indication. "Absolutely no indication", I sneer.

See the example above. Even though the compile could do it, may have very
good reason not to do so; especially if it involves running a part of the
code itself, machine-specific implementation details.

If it has a good reason not to, it's not up to it.

 

[Kenny McCormack]

And obviously sha384 has nothing to do with the C language,
inasmuch as it never appears in any C standard. Followups have
been set to eliminate c.l.c, where this is off-topic.

You are so precious.

(As they say, you couldn't make up someone like CBF)

 

[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.