The C Paradox

If gets() is so dangerous and should never be used,

Why was it created in first place and kept in the C standard until now?

>>80
Type qualifiers are to programming languages as genital herpes are to sex. Itches, scratches and overall low-quality results.
When performance matters, they are invaluable.  Performance always matters.

uint32_t min:0 max:100 noboundschecks optimization_priority:4.9 align:best written_from:1 read_from:4 loop_index;

>>81
Seems like you want dependent types.

>>81

When performance matters on that level, you should be doing straight machine-code instead of trying to tweak the compiler guesses. And obviously after a decent profiling session. No amount of keywords will ever evaluate to any sensible, objective measurement of performance gain.

That's a reason why no one uses individual '-foptimize-whatever-fuck-trees' flags and instead use '-O3' flags, without ever profiling anything. People just say they care, but they don't really care; they're satisfied in _believing_ the compiler will get things any better in terms of performance. Keywords give them an extra self-delusional power.

For what is worth, the only keyword that matters in C is 'restrict'. 'restrict' is a C99 keyword; the vast majority of the programs are still written in C89, thus not getting 'restrict' or getting them as an extension. And often getting them wrong.

typedef const int * restrict fast_t;

int main(void) {
  register fast_t vroooooooooooooooooooom;

  return 0;
}

>>83
Hardware optimization is always a suckers game, even ace asm coders like Michael Abrash say its impossible to to guess how all the factors interrelate in the CPU pipeline

>>84

Look, Batman! Non-compliant code! The '_t' suffix is actually reserved for standardization, and usage likewise yields undefined behavior!

How come such an innocent snippet fall within the clutches of Mighty Portable C!

>>85

There's a difference between handwiring a very limited hotspot in machine language and attempting to optimize the entire code branch through arcane microfusion knowledge. No doubt, anyway, that a compiler does it worse -- specially if the 'register const int array[const static restrict 0x10]' declaration of a function parameter was your best attempt at 'optimizing access to an array' through language keywords.

One doesn't need to know everything about optimization to produce better-than-average code in assembly, specially because, indeed, knowing every possible correlation is impossible. By design, assembly code is much tighter, which by itself is a great advantage -- higher cache hit ratios, reduced number of overall instructions due to non-redundant calculations, etc. Good assembly programmers know how to healthily produce maintainable, optimized code, when they really need to. They only do if it can be proved it's worth the effort.

>>86
IIRC ANSI and ISO C don't prohibit the use of the `_t' suffix for types, only POSIX does. So as long as you don't include any POSIX headers, you can use such type names.

>>88
only POSIX does.
That's why it sucks. "Hey, guys, look! C89 uses cool style for typedefing types! Let's steal it awesomess and telly anyone to not use it". Fuck this bullshit.

>>88

You're correct, albeit no need to include POSIX headers to 'be' in POSIX. Just by choosing a POSIX environment (#define _POSIX_C_SOURCE) you're already limited to their namespace.


>>89

It does suck steel balls, though much better as a standard than ANSI/ISO is.

>>90
Except POSIX doesn't work everywhere.

NOT STANDARD!

And then, assembler drove up alongside C and shot C in the head.

>>88
wtf, but... time_t and all are POSIXLY defined!

>>92
S/SHOT/SUCK'D

>>92
With that kind of irresponsible road rage, I don't get why people still use assemblers for drivers.

C is just a fast procedural language. Go with C# and save yourself the road rash.

i dont think so.

>>96
GC is shit.

Preventing doubles hijack.

Preventing doubles hijack.

>>99
_ni^ce du^bz bro

Thread was over when >>3 posted. He's basically 100% right.

>>102
Yeah.

>>1
Quoting from Rationale for International Standard—Programming Languages—C, revision 5.10:
[quote]7.19.7.7 The gets function
Because gets does not check for buffer overrun, it is generally unsafe to use when its input is
not under the programmer’s control. This has caused some to question whether it should appear
in the Standard at all. The Committee decided that gets was useful and convenient in those
special circumstances when the programmer does have adequate control over the input, and as
longstanding existing practice, it needed a standard specification. In general, however, the
preferred function is fgets (see §7.19.7.2).[/quote]

>>99,101
Fuck off, spammer.