Why is getpass() considered an obsolete function? - c++

I've been searching for a getpass() alternative and it's in fact the simplest way to hide a password input I've founded. It's kind of a loss for C++ here, being such easy function with a lot of use.
What i would like to know is why is it considered obsolete, does it have any security issues ?
And can/should i still use it professionally, disregarding the warnings and taking them as "exaggerated" ?

Why is getpass() considered an obsolete function?
According to this man page
The getpass() function is not threadsafe because it manipulates
global signal state.
The getpass() function is scheduled to be withdrawn from a future version
of the X/Open CAE Specification.
can/should i still use it professionally
If your C library has the function, then you can use it.
If you consider any of: the lack of thread safety, or the manipulation of global signal state in general, or the fact that as an obsolete function it may be removed in a future version of the C library that conforms to a future POSIX version, a problem, then you should not use it.
The recommended alternative is to write your own function, using termios and disable the ECHO flag. Complete minimal substitute in glibc manual.

The term "obsolete" appears to be an add-on from implementers; the actual SUSv2 was less direct:
The return value points to static data whose content may be overwritten by each call.
This function was marked LEGACY since it provides no functionality which a user could not easily implement, and its name is misleading.
The "obsolete" is mentioned in mailing list in 2003 Re: getpass obsolete?, which pointed to an OSF1/Tru63 manual page citing the lack of thread-safe capability, but in regard to the standard at that point in time was only supported by the comments in SUSv2.

Related

Inferring the implementation of a function in c++

I was going through the documentation of rand() function in c++ and it says
The function accesses and modifies internal state objects, which may cause data races with concurrent calls to rand or srand. Some libraries provide an alternative function that explicitly avoids this kind of data race: rand_r (non-portable). C++ library implementations are allowed to guarantee no data races for calling this function.
As a more general question how can I be sure that I am calling a c++ implementation of a function (rand in this case)?
Calling rand() inside a file having .cc or .cpp extension.
or, any particular header that can ensure this
I am asking this question because my understanding is that when I use cstdlib header, it in turn calls the c implementation of that (stdlib.h). If that's not case then does c++ provide its own implementation for all c functions?
I think you are asking the wrong question.
You've read that C++ library implementations are allowed to give you a version that has no data races. They are allowed, but they are not required to do so. If you had some all-knowing oracle capable of telling you whether you are using a C++ implementation, and if it told you that you are, would that solve your problem? No, not really, because you still wouldn't know whether that implementation would guarantee the absence of data races. Maybe it would, but you'd have no certainty.
So you have to ask the right question: how do I know whether the function I'm using guarantees that? And the answer is: check the specific documentation of the library you are using! I suppose you are reading the cplusplus.com page on rand. That is a generic site, unrelated to a specific library, so it won't help you answering this question. Instead, what compiler and standard library are you using? Check their documentation. If the authors state that their rand function is guaranteed to be race-free, then go ahead and use it. Otherwise, be conservative and assume there are some races, and don't use it.
And by the way, a lot of people would tell you that that site should be avoided, because it isn't very reliable. In general, cppreference is preferred. And it says that
It is implementation-defined whether rand() is thread-safe.
Where "implementation defined" means exactly what I said. And if you continue reading, it will also list some other problems (the numbers it generates aren't that random after all), and
It is recommended to use C++11's random number generation facilities to replace rand().

Alternative for MFC functions in c++?

Alternative for MFC AfxIsValidAddress in c++ ?
That function actually does not do what it says...
It says that it checks the memory range to see whether it is mapped to the space address of the process. But actually, in most versions of the library, it just checks for a NULL value.
The rationale seems to be that in older versions of Windows, it relied on IsBadReadPtr() and friends. But these functions are totally obsolete, and should not be used in newer code (according to MSDN), thus the change in behavior.
That said, if you want to really check for a memory range, your best option is VirtualQuery().

Are the makecontext()/swapcontext() functions compatible with C++

In unix environments the makecontext()/swapcontext() family of functions is sometimes used to implement coroutines in C. However these functions directly manipulate the stack and the execution flow. Often when these low level functionalities are quite different when switching from C to C++.
So the question is, if there would be any problem with implementing coroutines using makecontext() and swapcontext(). Of course one obviously would have to take very good care, that an exception could never escape such a coroutine, since there would be no exception handler on the stack for this and the program would most likely segfault. But other than that is there any incompatibility between the way C++ handles things internally and makecontext() and setcontext() modify the execution path?
I've used makecontext()/swapcontext() with C++ code before, and as you say, the main thing to watch out for are exceptions. Beyond that I haven't had any trouble. Despite their obsolescence according to the standard, they're still well-supported by unix-like operating systems. (there is a caveat for Mac OS X: you have to #define _XOPEN_SOURCE before #including the relevant headers.) The rationale for making them obsolete is pretty lame, too - they could have replaced them with a pthreads-like version, where the function pointer takes a single void* argument.
As you say, threads aren't a useful substitute, so I'd go ahead and use swapcontext(). You may also find this blog post interesting for rolling your own version of the functions.

Is gets() officially deprecated? [duplicate]

This question already has answers here:
Why is the gets function so dangerous that it should not be used?
(13 answers)
Closed 1 year ago.
Based on the most recent draft of C++11, C++ refers to ISO/IEC 9899:1999/Cor.3:2007(E) for the definitions of the C library functions (per §1.2[intro.refs]/1).
Based on the most recent draft of C99 TC3, The gets function is obsolescent, and is deprecated. (per §7.26.9/2)
Can I safely say that gets() is deprecated in both C and C++?
Deprecated means you shouldn't use it and it might be removed in the future. Since both standards say it is deprecated, that means it is deprecated, officially.
Does it matter? The only way you can ever use gets is if stdin is known to be attached to a file whose contents you have full control over. This condition is almost impossible to satisfy, especially on multiprocess systems where other processes may modify files asynchronously with respect to your program. Therefore, for all practical purposes, any program using gets has undefined behavior (i.e. there are possible inputs/environmental conditions for which it will have undefined behavior), and in particular UB which is likely to lead to privilege compromise if your program has higher privileges than the provider of the data.
Edit: OK, here's one safe use of gets, about the only one I can think of right off...
if (feof(stdin)) gets(buf);
Of course some buggy implementations (possibly including glibc..?) permit reads even when the EOF indicator is already set for a stream, so....
Even code which would be broken by the removal of gets() from the library would, after such removal, be less broken than it was before such removal. I suppose it might be necessary for compiler vendors to include it in a "fully-standard compliant" mode, but the number of circumstances where it could safely be used is so vanishingly small that it would probably be reasonable to exclude it from a "normal" build.
It's going to be a while until C++11 is implemented everywhere.
Also, most compilers doesn't even fully support C99 yet.
Microsoft's, for instance, does not.
So no, it's not deprecated in both C and C++.
Well it was removed altogether from the C11 standard, so I'd take that as a yes.

A proposal to add statemachine support to C++-like language

Lately as part of my day job I've been learning IBM Rhapsody and using it to generate code in C++ from the UML.
Yesterday it struck me that it might be cool to think about adding state machine support to my C++ compiler, so I jotted a few notes here: http://ellcc.org/wiki/index.php/State_machines_and_Active_Classes
My motivations for doing this are:
It seems like a cool idea.
The compiler could do much better semantic checking (with better error checking) than the current Rhapsody/normal C++ compiler.
There are many optimization possibilities available when the compiler itself understands the state machine structure.
I may try to extend my grammar to except something like the proposal to see how well it works.
What is your opinion of the proposal? Does it seem readable? Does it seem worthwhile?
Edit:
Thanks for the answers recommending specific libraries to do state machines, but that wasn't my question. I've implemented many state machines using both libraries and code that I've written.
I was really looking for ideas, criticism, etc. about the design of a state machine extension to a C++-like language, not whether this change would be appropriate for addition to standard C++. Think of it as a domain specific extension, where my my domain is real-time control applications.
I've started implementation of the extension in my compiler as described here: http://ellcc.org/wiki/index.php/State%5Fmachines%5Fand%5FActive%5FClasses
So far the concept hasn't had to change much going from proposal to implementation but there have been a few changes in details and I'm refining my understanding of the semantics of the problem.
Time will tell whether the whole concept has any value, however. ;-)
With a few exceptions, C++ has traditionally been extended using class libraries, not new keywords. State machines can easily be implemented using such libraries, so I don't think your proposal has much of a chance.
One problem I see in your proposal is the use of 'goto' to go to another state. What happens if I want to use goto in my own code within a state transition?
Excellent work developing what you've done. Something like you've done probably is possible, but I'm doubtful it would ever get into the C++. Most changes that make it into the language itself are included only to allow people to write more useful and powerful libraries.
There's a library here that provides support for state machines. I haven't tried it, but it might interest you, and you may be able to combine your ideas with a library like this to allow other people to make use of it.
http://www.boost.org/doc/libs/1_34_1/libs/statechart/doc/index.html
Or, you could develop your own extension as you suggest, and it would at least be useful for you. Microsoft implement some extension keywords, so there is no reason why you couldn't create your own extended version of C++.
Keep the new ideas coming.
You should take a look at how another smart developer added State machine support to a C-like language: UnrealScript Language Reference. See the section named "States".
UnrealScript supports states at the
language level. In UnrealScript, each
actor in the world is always in one
and only one state. Its state reflects
the action it wants to perform. For
example, moving brushes have several
states like "StandOpenTimed" and
"BumpOpenTimed". Pawns have several
states such as "Dying", "Attacking",
and "Wandering". In UnrealScript, you
can write functions and code which
exist in a particular state. These
functions are only called when the
actor is in that state
It's an interesting idea, but I think you'd actually have better luck creating your own domain-specific language for state machines than officially extending C++. C++ is designed as a very general-purpose programming language. I think Boost has proven that C++ is flexible enough that most features can be implemented nicely using libraries. It also evolves very slowly, to the extent that standard C++ still doesn't even have built-in threading support as of 2009, (it is planned in 0x). So it's unlikely the committee would consider this addition for some time.
Your solution does not look like it has any advantages to a template- or preprocessor-macro-based solution.
I am also not sure, how you can provide better semantic checking. And I doubt that you can apply many useful code optimizations.
However, to allow better optimizations and semantic checking, you should also replace "goto" with a new keyword (e.g. __change__ newState), and disallow goto for state changes! Allow goto for local jumps as usual.
Then the compiler can extract a list of possible transitions.
Read your proposal, have the following comments:
There's actually no keyword to declare and define an actual state machine! Do you assume a single global state machine (and thus a single global state)? How does that relate to __active__ ?
The closest comparable construct in C++ is actually the enum. Why not extend it?
There seems to be some connection between defined events and states, but I fail to see how it's implemented.
Why are threads and timers needed at all? Some use cases of state machines may benefit from them, but a good proposal should keep these seperate. Most importantly this should allow the use of standard C++0x threads.
Personally, I would extend the enum syntax:
enum Foo {
red, blue, green; /* Standard C++ so far - defines states. State list ends with a ; not a , */
Foo() { *this = red; } // Reuse ctor syntax, instead of __initial__
~Foo() { } // reuse dtor syntax, instead of __onexit__
void Bar() {/**/} // Defines an event, no return value. Doesn't need keyword __event__
};
It follows naturally that you can now declare your events in a header, and define them in a .cpp file. I don't even need to suggest the syntax here, any C++ programmer can guess that at this point. Add a bit of inheritance syntax for combined states:
enum DrawingObject : public Shape, public Color { /** } // allows (red && circle)
and you're pretty much at the point where your proposal is, without any new keywords, all by reusing an already familiar syntax.