Thread: Password field with: **********

Originally Posted by quzah

I didn't miss anything. I answered him first. Nearly all of my other posts were directed to you.

And God himself is still wondering "Why?"

I didn't tell him it wasn't portable. I told you that your code wasn't portable. But even if I did tell him that, it would have been regarding my first post, and it is important to know that, because they didn't mention their compiler or operating system in the first post. As such, since there is no portable way to do that, I would have still been in the right telling them that it's not portable. Because without knowing their platform, there's no way to tell them how to do it.

Great, we'll get a sing along of yet another verse of "Gloom, Despair, and no port-a-bility!"

That will REALLY help get a function coded!

I'm not a damn bit surprised you didn't catch it though, because you've proven yourself a bit on the slow side.

Yet leaving you in the dust - amazing. I cheat, and listen to the OP, and not to the no-bird chorus.

You're just mad that it took you six posts to realize that \r and \n aren't the same thing. So you're being intentionally stubborn insisting that your way, putting the number 8 is better than putting '\b'.

I never said that, never inferred that, and stated exactly why I did it 2 or 3 times now. It's just easier for me to work with ASCII values than to work with escape char's. I have experience with coding ASCII values from years ago. I haven't done much coding with escape char's.

Indio now has a basic password function he can polish up to his wants and needs.

Why do I have to keep repeating the same info, over and over? Read my posts and quit stating obvious misstatements of what I posted.

Adak

Originally Posted by laserlight

I can see where you are coming from, and indeed in this case there is no portable way of doing the job, so the use of getch() is fine, as long as it is noted to be nonportable. On the other hand, seeking on stdin can be avoided with alternatives that are both portable and compliant with the standard, so you should recommend such an alternative instead.

That's not true, and I challenge you to find concise, clear, and portable code that will pause that program, for ONE (and only one), enter key to be hit. REGARDLESS of the state of the keyboard buffer. Yes, I'm talking about an extra 20 char's being keyboarded after the password array is full (and not accepting any more input).

I tried three - and none worked right for both a full keyboard buffer, and an empty keyboard buffer.

Newer compiler's may have something that will do this better than the old Borland I was using, but you give me the code, and I'll try it on my compiler (or you can also try it). But it has to work on Borland or Turbo C compilers, prior to version 2.

Adak

Originally Posted by quzah

Code:

char buf[ 21 ] = {0};
fgets( buf, sizeof buf, stdin );

fgets says "Hi".

Line buffered, one, and only one, enter at a time. Just like you wanted, reading a limited number of characters at once. Now naturally you'll have some stupid ass argument that makes no sense to anyone here, something like "I wanted a portable password box that wouldn't allow any more than that amount of characters! See, I can type 4000 there!" -- But before you do, that's not what you said you wanted. You said you wanted a function that read up to a newline, and disregarded everything past a set amount. Well, there you go. Now after you've hit enter, clear your buffer on your own if the last element in your array isn't a newline. Problem solved.

No, this isn't going to mask your password, but that's not what you said you wanted for this question.


Quzah.

You've misunderstood my post to laserlight.

I was asking about a line or two of code, to just pause the program and await ONE enter key hit, regardless of the state of the keyboard buffer. Something clear, concise, and portable.
(Not System("pause"), obviously). Has to work on Borland/Turbo Compilers prior to ver. 2.

This has NOTHING to do with the password being displayed, etc. That's all done now.

Until you can show some respect, I really don't care what code you propose.

Originally Posted by laserlight

I can see where you are coming from, and indeed in this case there is no portable way of doing the job, so the use of getch() is fine, as long as it is noted to be nonportable.

The definition of "portable" I use in my daily work is somewhat different. In essence, a codebase is "portable" if it can be reasonably altered to run on an arbitrary platform. "Reasonable" is a subjective term, but one which you can get a good feel for with experience. As others pointed out here, there is simply no way to do certain things "portably" in the sense that the exact same code works everywhere. For instance, clearing the screen. But a program which clears the screen on many different platforms can be written.

Portability, like encapsulation, is a quantifiable spectrum, not a binary concept. A better term for the latter idea might be "adherence to the standard." A program might be extremely portable in that it can easily be made to run on any given system, or it might be horrendously unportable in the sense that its system-dependent features are grossly intertwined with its system-independent features. This is just a symptom of bad design.

I'm drunk and this thread makes me laugh.