Thread: gets() not so bad

Originally Posted by nonoob

Maybe programmers are getting dumber and we need to have nice bubble-wrapped soft and cozy functions for everything to protect us.

That is actually the trend over recent years. Java, for example, had its genesis in being a "safer C++". In part because programmers expect things to "just work" (i.e. they don't take the care to avoid using constructs in an unsafe manner) and in part - like gets() - the constructs are inherently unsafe.

Using gets() is all well and good if you can trust the user of your program not to do something silly that overruns the buffer length. In the real world, programmers have to be paranoid and assume the user of their program CANNOT be trusted to do the right thing. Teaching students otherwise is teaching them habits that will be frowned on when they go for a job.

However, it is usually better to use some means that allows the programmer to prevent a buffer overrun. fgets() does that, without too much ado. Although there are trade-offs in its usage - extra care is needed to properly handle lines that exceed the buffer length. Not difficult, but care needed. In practice, the code is often less complicated by using fgetc() in a loop, if your code needs to read multiple lines.

gets() is your typical "trip on a landmine" C function.

As for the deriding of instructors, I think that was referring to my recent post in another thread. However note, that the instructor I was deriding also encouraged students to fflush(stdin) and to use void main(). So, I am pretty justified in deriding him and will continue to do so.

Furthermore, instructors like these that learn C at "band camp", then figure out that because they liked it they are ready to teach someone else, are dangerous elements for the profession in general.

If I could add my 2 cents, being a technical interviewer. I've seen post-doc students applying for C++ positions, who listed on their resume the fact that they taught first-year programming modules. So essentially people with no real world experience are teaching the next generation. What's worse is that these guys normally fail the interview as well, as they don't really understand what they're doing when it comes to memory management and pointers. Personally I'm scared of the people graduating in the next few years.

QuantumPete

Originally Posted by Bayint Naung

Probably they don't know there are free compiler + necessary complete tools
gcc + gdb + splint + (yacc|bison) + flex + valgrind + cproto + indent + cdecl + etc.

Sounds a little more realistic than the jwenting fantasy which itself is stuck 20+ years in the past

I am 100% sure this is not because people are failing to buy the proper MS products!

Originally Posted by MK27

I find that super-paranoia irritating too -- I presume it is a product of certain workplaces, and for good reason (but that does not make it "true" or justified in a more pure and abstract sense).

Didn't we go over that last time? It's not super paranoia; it's security.
Imagine Microsoft not using all those security checks. Well, we'd have a 1000x more patches today.
Teach newbies to write safe code and do so early. It's growing all the more important in today's world. Even if they're not going to write real world applications in the future, they won't be happy if their machine gets hacked because they forgot about security.
Or heck, how about when they take it up as a hobby and distribute some pieces here and then and maybe compile an application.
...And then people's computers start crashing. Wonderful.

It's the right thing to do to ban gets. Now I also hope they will consider adding safe variants of other unsafe (but rarely mentioned) functions such as strcpy, memcpy, strcat, etc.

Originally Posted by Elysia

Didn't we go over that last time? It's not super paranoia; it's security.
Imagine Microsoft not using all those security checks. Well, we'd have a 1000x more patches today.
Teach newbies to write safe code and do so early. It's growing all the more important in today's world.

You are assuming the purpose is to prepare everyone for employment at Microsoft, or some other place where scale would necessitate this kind of paranoia, because they probably have employees that will intentionally incorporate buffer overrun bugs on a bad day, so the move has been more and more toward "foolproof" languages to help management manage this not doubt insidious and significant problem.

However, while this may be true for many, it's not true for everyone. I have no desire to work anywhere like that -- I'd rather just do unskilled labour, in fact. So your perspective is valid, but it should never never be taken as a universal rule (eg, so that we start adapting the C standard to it*). Programming as business concerns are not synonymous with pure programming concerns, where I think freedom is more important.

The fact that some software houses have problems with people shooting each other in the foot is not my problem. Let them use Java or something, or spend money on mem checkers (which I believe is a cost of doing such business).

* however, I could care less if they ban gets(), since it is silly and redundant.

No, it is absolutely necessary. Microsoft don't use C# for the kernel because it just doesn't work. They are stuck with C/C++. That means they need safe facilities.
Similarly, we see a lot of C programmers here developing in C for Windows. For basic apps. Yes, for basic apps. Should we force them to go C++/Java/C#, then? Because there are no safe facilities in C.

Anyway, the thing is, at Microsoft, they have a lot of security guidelines and stuff. Making sure there are no buffer overruns is just one of them. And to be fair, buffer overruns is a huge problem these days, so yes, I completely believe that it should be mandatory for everyone, as a rule, to use safe facilities.

Unsafe use of memcpy/strcpy/strcat is just as bad as gets.

Originally Posted by Elysia

No, it is absolutely necessary. Microsoft don't use C# for the kernel because it just doesn't work. ...the thing is, at Microsoft, they have a lot of security guidelines and stuff.

Terrific! BUT MICROSOFT IS NOT ANSI OR THE ISO.

Unsafe use of memcpy/strcpy/strcat is just as bad as gets.

Okay, so in house MS can ban the use of these functions. Or use strict C++ or Java or whatever. The rest of use will just have to toughen up and learn to use your brain whilst coding, because all three of those functions are perfectly safe when used properly.

Originally Posted by Bayint Naung

Microsoft to banish memcpy
next time, Assignment operator ?maybe

See, problem solved! I don't think cboard has to do their work for them. Bill has $54B, let him pay someone for that tish.

Originally Posted by MK27

Terrific! BUT MICROSOFT IS NOT ANSI OR THE ISO.

Okay, so in house MS can ban the use of these functions. Or use strict C++ or Java or whatever. The rest of use will just have to toughen up and learn to use your brain whilst coding, because all three of those functions are perfectly safe when used properly.

I'm not saying to use Microsoft functions. I'm saying to create your own safe functions that add security checks so that you don't commit to these mistakes.
That's why I said it would be nice is safe alternatives were added to the language (in the standard, of course).

Originally Posted by Bayint Naung

Microsoft to banish memcpy
next time, Assignment operator ?maybe

They're only banning it in their internal development. This doesn't affect the rest of the world's C programmers.
(Though they should take a hint and consider security.)

Originally Posted by Elysia

I'm not saying to use Microsoft functions. I'm saying to create your own safe functions that add security checks so that you don't commit to these mistakes.
That's why I said it would be nice is safe alternatives were added to the language (in the standard, of course).

This is completely unnecessary. 95% of memcpy calls can be done without checks simply by setting up the input and output correctly.

Please do not say "oh but what if I do this":

Code:

char buffer[16];
memcpy(buffer, something_else, 1000000);

That is JUST STUPID. TOO BAD. YOU LOSE. LEARN TO PROGRAM.

This is only a problem in "real world" settings like MS where economics and scale have made $$$ the priority, so quality of the product (and the people who produce it) is second seat to the quantity they can produce. That's what needs to be fixed.

Since it won't be, they can just make C# faster or something. Won't happen if half the underlying code is totally redundant safety checks, of course.

Originally Posted by MK27

This is completely unnecessary. 95% of memcpy calls can be done without checks simply by setting up the input and output correctly.

...And one day you'll shoot yourself in the foot because you didn't think right. You introduced a bug. The bug didn't crash the program and you got a buffer overrun. Yay.
...Of course, this could have been prevented in the first place had you used safety checks.