Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Fix my program

Reply
Thread Tools

Fix my program

 
 
Richard Tobin
Guest
Posts: n/a
 
      03-06-2008
In article <(E-Mail Removed)>,
CBFalconer <(E-Mail Removed)> wrote:

>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

--
:wq
 
Reply With Quote
 
 
 
 
Falcon Kirtaran
Guest
Posts: n/a
 
      03-07-2008
Nomen Nescio wrote:
> 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)
 
Reply With Quote
 
 
 
 
Thad Smith
Guest
Posts: n/a
 
      03-07-2008
Sebastian G. wrote:
> Thad Smith wrote:
>
>> Sebastian G. wrote:
>>> Thad Smith wrote:
>>>
>>>> Bartc wrote:
>>>>> Mark Wooding wrote:
>>>>>> Nomen Nescio <(E-Mail Removed)> wrote:
>>>>>>
>>>>>>> if (password != "november13") {
>>>>>> It's probably worth pointing out that you can improve security by
>>>>>> hashing the passwords. You should probably replace the above with
>>>>>> something like
>>>>>>
>>>>>> if (strcmp(sha384(password), sha384("november13"))) { ... }
>>>>> 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.
>>> A optimizing compiler may decide to not optimize away any
>>> sufficiently complex calculation.

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


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!

--
Thad
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      03-07-2008
Sebastian G. wrote:

> Chris Dollin wrote:
>
>
>>>>> A optimizing compiler may decide to not optimize away any sufficiently
>>>>> complex calculation.
>>>> 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(int64_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>.

>
> <> 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:

> >> When <sha384.h> is included, sha384() computes the hash of the string

>> literal at compile time


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

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


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

--
"Creation began." - James Blish, /A Clash of Cymbals/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      03-07-2008
In article <(E-Mail Removed)>,
CBFalconer <(E-Mail Removed)> wrote:
>Bartc wrote:
>> Mark Wooding wrote:
>>> Nomen Nescio <(E-Mail Removed)> wrote:
>>>
>>>> if (password != "november13") {
>>>
>>> It's probably worth pointing out that you can improve security by
>>> hashing the passwords. You should probably replace the above with
>>> something like
>>>
>>> if (strcmp(sha384(password), sha384("november13"))) { ... }

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


You are so precious.

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

 
Reply With Quote
 
Mark Wooding
Guest
Posts: n/a
 
      03-07-2008
Sebastian G. <(E-Mail Removed)> wrote:

> 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]
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      03-07-2008
Mark Wooding wrote:
> Sebastian G. <(E-Mail Removed)> wrote:
>
>> 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 ...


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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
David Thompson
Guest
Posts: n/a
 
      03-24-2008
On Wed, 5 Mar 2008 12:59:41 +0000 (UTC), Mark Wooding
<(E-Mail Removed)> wrote:

> Nomen Nescio <(E-Mail Removed)> wrote:
>
> > if (password != "november13") {

>
> 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
 
Reply With Quote
 
Sebastian G.
Guest
Posts: n/a
 
      03-24-2008
David Thompson wrote:

> On Wed, 5 Mar 2008 12:59:41 +0000 (UTC), Mark Wooding
> <(E-Mail Removed)> wrote:
>
>> Nomen Nescio <(E-Mail Removed)> wrote:
>>
>>> if (password != "november13") {

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



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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[FIX] Another possible fix for the missing ASP .Net tab problem Patrick Philippot ASP .Net 0 04-14-2006 11:48 AM
Xah's Edu Corner: The Concepts and Confusions of Pre-fix, In-fix, Post-fix and Fully Functional Notations Xah Lee Perl Misc 21 03-21-2006 07:02 AM
Xah's Edu Corner: The Concepts and Confusions of Pre-fix, In-fix, Post-fix and Fully Functional Notations Xah Lee Python 23 03-21-2006 07:02 AM
Xah's Edu Corner: The Concepts and Confusions of Pre-fix, In-fix, Post-fix and Fully Functional Notations Xah Lee Java 22 03-21-2006 07:02 AM
why browser cache setting affects program behavior? Fix? =?Utf-8?B?anVubGlh?= ASP .Net 2 05-20-2005 06:27 PM



Advertisments