You are recommending strncpy and strncat. These are slow functions that
occasionally leave off the terminating '\0'.
Thanks, strncpy removed & replaced with memcpy recommendation
(thinking later that strlcpy(), obviously it one day will be part of
the C standard).
(But limited -- obviously I would recommend removing all of str* and add in Bstrlib >as an alternative, but, I've said this before, and this is likely beyond what you are >looking at/for.)
Originally I planned to use your Bstring library in making the t3d's
string type. However the t3d arrays would need to allow UTF32 formed
(wbyte) arrays and automatic garbage collector, so I designed a new
safe string system.
fgets is not an ideal substitute for gets as explained here:
http://www.pobox.com/~qed/userInput.html (though obviously gets must be
removed.) So I would also recommend removing fgets if you have a
replacement for it (such as getInputFrag, or perhaps just fgetstr)
Even Microsoft is suggesting a safer replacement version for fgets()
-->fgets_s(); in Microsoft's "safe C" proposal sent to C working
group. So apparently fgets() has also been collecting bugs / exploits.
However I don't yet dare to write off the fgets(), because of the
respect for using the standard tools as possible.
I am not sure why you want to get rid of srand() or rand(). Its true
they suck as PRNGs, and race conditions mess them up in ways that can be
worse than you think (and RAND_MAX is generally pathetically small), but
Well you said it, they are not particularly good as PRNG's and
apparently classed unsafe for multithreading.
the real world. Again, if you had a *substitute*, that would be fine.
I think snippet collection
http://c.snippets.org/browser.php#12
provides good public domain alternatives for c99 conforming portable
t3d's rand functions like:
t3d_create_RANDOM_NUMBER
t3d_create_RANDOM_NUMBER_MINXXX_MAXXXX
t3d_ create_Rint_RANDOM_NUMBER_MINXXX_MAXXXX
t3d_create_int_int_Rint_RANDOM_NUMBER_n_MIN_MAX
(The right answer here is to demand that the standard change how it works --
however a quick perusal of their guiding principles, indicates there is
no mechanism by which you could reasonably do this.)
C is like bacteria perfectly adapted to its environment, major changes
would likely affect it and the C community somehow negatively, so the
standard resist the change. The truth is that if the people
participating in this thread would be at gunpoint forced to develop
the C into world's best programming language…
--> Out would go: the null-terminated string, and with them str*
functions, all the illogicality in C's return values and parameter
orders, all the multithreading unsafe elements
--> In would come: dynamic memory management, Bstrings, pthreads, GUI
support and lots of easy to use functions which would be utilizable in
those environments which support those features.
Ok, lets be more realistic if the C standard committee members were to
be taken into the US concentration camp at Guantanamo and tortured
there until they would produce a more secure-C. In matter of 0.15
seconds gets() would be history and in less 15 seconds all str*
functions would be retired, simultaneously as Bstrings and garbage
collector happily welcomed into language.
So who do we need to write about the C standard committee (except nice
Mr. P.J Plauger) which is keeping the insecure stuff within the C to
facilitate terrorist acts.
Ok, as for other things that should obviously be removed: ftell() and
fseek(). Use fgetpos() and fsetpos() as the alternatives.
Good point C.L.C FAQ says:
12.25: What's the difference between fgetpos/fsetpos and ftell/fseek?
What are fgetpos() and fsetpos() good for?
A: ftell() and fseek() use type long int to represent offsets
(positions) in a file, and may therefore be limited to offsets
of about 2 billion (2**31-1). The newer fgetpos() and fsetpos()
functions, [~can use any size]
--> ftell and fseek --> gone fishing
I would get rid of ungetc just on principle (can't unread at the
beginning of a file, may screw up fgetpos(), only does a single
character -- its just super lame, and throws a monkey wrench into too
many other functions.)
C standardization working group writes in its latest 'working paper'
(WG14), that
Major changes from the previous edition include:
....
- deprecate ungetc at the beginning of a binary file
....
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
Of course I think "register" and "inline" are functional placebos in
modern C compilers. They are also deceptively named (both should be
replaced by a single adjective "nonaddressable" or something like that.)
I don't yet dare to touch the C's register, inline or pointer
properties - I believe most C purists love that warm feeling of just
knowing of that those things are there if needed.
C also accepts things like 3[a] as equivalent to a[3], when there
doesn't seem to be a really good reason to do this. This appears to be
strictly for the obfuscated C code competition.
The obfuscated C competition winners probably sit in the standard
committee designing themselves some new triks. How else you can
explain the thing like having Trigraph sequences which require
repeated question marks to be translated into something which causes
the code just to look totally cryptic.
Trigraph sequences
All occurrences in a source file of the following sequences of three
characters (called trigraph sequences12)) are replaced with the
corresponding single character.
??= #
??( [
??/ \
??) ]
??' ^
??< {
??! |
??> }
??- ~
Standard says :
The sequence ?? cannot occur in a valid pre-C89 program except in
strings, character constants,comments, or header names. The character
escape sequence '\?' (see §6.4.4.4) was introduced to allow two
adjacent question marks in such contexts to be represented as ?\?, a
form distinct 15 from the escape digraph. The Committee makes no
claims that a program written using trigraphs looks attractive.
Yes, I can imagine the committee members laughed their heads off while
designing the trigraphs
Thank you very much
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
"t3d programming language" and the structure of t3d function prototype
are trademarks of Juuso Hukkanen. (Currently discussing the
transfer of those to a major charity organization).
