Listing the most dangerous parts of C

[Juuso Hukkanen]

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

[jacob navia]

Juuso Hukkanen a écrit :

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

What is "t3d" first ???

From that wiki page it is completely imposssible to have an idea what
the hell is that.

jacob

[Arthur J. O'Dwyer]

On Wed, 10 May 2006, jacob navia wrote:

Juuso Hukkanen a écrit :

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )
Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

What is "t3d" first ???

From that wiki page it is completely imposssible to have an idea what the
hell is that.

It's vaporware. This guy's been pushing its "natural language, giant
built-in library of functions" model for at least a year or so, now.
(The problems are that the "natural" language isn't, and the "built-in"
functions aren't.)

FWIW, off the top of my head I'd say gets (obviously), strtok (not
thread-safe), atoi (no error-checking possible), and much of scanf
(again with the error-checking).
scanf("%*s") is fine, but scanf("%s") is evil, scanf("%99s") is
unmaintainable, and scanf("%d") chokes in unpredictable ways on input
like "3287482475".

my $.02,
-Arthur

[P.J. Plauger]

"Juuso Hukkanen" <ju***********@tele3d.net> wrote in message
news:bm********************************@4ax.com...

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

One very popular wish list is Misra C. (Actuall two, since there's a
revision out too.) It endeavors to tame C by outlawing all sorts of
usages that some people think *might* be misused.

Another is Microsoft's secure/safer/bounded C, a version of which is
now shipping with VC++ V8. It supplies alternatives to many functions
that can be better bounds checked to avoid storage overwrites. This
work is based on Microsoft's massive bug hunt stimulated by all the
viral attacks on Microsoft software largely written in C.

Neither is anywhere near perfect, nor universally accepted. Both are
places to start.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Richard Heathfield]

Juuso Hukkanen said:

I am looking for a wish list of things which should be removed from
the C (C99)
Absolutely. Just remove C99. Nobody will notice anyway.
- due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>
Okay, drop gets(), scanf(), and strncpy() - ironically, this is unsafe
chiefly because people think it's safe and so they feel free to use it in a
rather cavalier way!

strtok() isn't threadsafe, as someone already said, so I guess you would
want to drop that (I wouldn't, but you're not me).

That's about it, I think. Everything else is fine, if you're careful. (Mind
you, scanf, strncpy, and strtok are fine if you're careful, too!)
Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

No, it would be more like saying that if you give power tools to
kindergarten kids, you should expect tears before bedtime.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Rod Pemberton]

"Juuso Hukkanen" <ju***********@tele3d.net> wrote in message
news:bm********************************@4ax.com...

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d
Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

I read a security oriented pdf (sorry, don't know where anymore) which said:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()

2) 8 C functions suffer from format string vulnerabilities
printf() fprintf() sprintf() snprintf() vprintf() vfprintf() vsprintf()
vsnprintf()

Summary of pdf: Because many C implementations use the same stack for
string data and flow control information (like addresses), the above
functions can modify the flow control information on the stack thereby
allowing authorized code to execute.

If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
2) make pointers be associated with a variable before use, not with a data
type
3) eliminate malloc, add dynamic allocation and garbage collection
4) change C to pass by reference
5) require separation of string (and other) data and flow control
information
6) give up now, and try Walter Bright's D language...
Rod Pemberton

[jacob navia]

Rod Pemberton a écrit :

If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
????
2) make pointers be associated with a variable before use, not with a data
type
lcc-win32: done.
References are pointers associated with an object permanently.
3) eliminate malloc, add dynamic allocation and garbage collection
lcc-win32: done.
The gc is standard in the normal distribution.
4) change C to pass by reference
?????
Why?

5) require separation of string (and other) data and flow control
information
Stack allocation is ok if used correctly. Making all objects heap based
would slow done everything without a lot of gain in security.
6) give up now, and try Walter Bright's D language...

????

With the above improvements, C can be much easier and safer to program.

jacob

[Keith Thompson]

"Rod Pemberton" <do*********@bitfoad.cmm> writes:
[...]

I read a security oriented pdf (sorry, don't know where anymore) which said:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()

[snip]

Obviously this document wasn't concerned just with standard C. A
number of those functions are non-standard. (I haven't even heard of
all of them.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Juuso Hukkanen]

On Wed, 10 May 2006 16:25:42 +0000, Richard Heathfield wrote:

Okay, drop gets(), scanf(), and strncpy() - ironically, this is unsafe
chiefly because people think it's safe and so they feel free to use it in a
rather cavalier way!
Ok, strncpy gone. I too I was unsure about it after reading the
http://en.wikipedia.org/wiki/Strlcpy
, but I thought to keep the strncpy for the sake of respect of
standard libraries :)
I see strlcpy could be obtained from the kind donation public
domain by Chuck Falconer, but I am not sure if it is a good idea to
have non-standard C functions inserted. Possible strlcpy is soon part
of the standard.
strtok() isn't threadsafe, as someone already said, so I guess you would
want to drop that (I wouldn't, but you're not me).

Well also the strtok(), (and even gets()) problems see to have better
but still a non-standard solutions provided to public domain by Chuck
(hmmm. Do I see a pattern) .

toksplit()
http://groups.google.com/group/comp....2e03ab0f27f874
ggets()
http://cbfalconer.home.att.net/download/ggets.zip

Thanks for the suggestions
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

[Juuso Hukkanen]

On Wed, 10 May 2006 12:56:23 -0400, "Rod Pemberton"
<do*********@bitfoad.cmm> wrote:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()

2) 8 C functions suffer from format string vulnerabilities
printf() fprintf() sprintf() snprintf() vprintf() vfprintf() vsprintf()
vsnprintf()
It's probably this document
http://www.ida.liu.se/~johwi/researc...ate_thesis.pdf
Chapter 7.3.3 Functions which are for attracting buffer overflows
Chapter 7.3.5 Format string vulnerabilities

very good reading , and it gives references to another even better
says...

<snip>
Functions to avoid in most cases (or ensure protection) include the
functions, strcpy(3), strcat(3), sprintf(3) (with cousin vsprintf(3)),
and gets(3). These should be replaced with functions
such as strncpy(3), strncat(3), snprintf(3), and fgets(3)
respectively, but see the discussion below. The
function strlen(3) should be avoided unless you can ensure that there
will be a terminating NIL character to
find. The scanf() family (scanf(3), fscanf(3), sscanf(3), vscanf(3),
vsscanf(3), and vfscanf(3)) is often
dangerous to use; do not use it to send data to a string without
controlling the maximum length (the format %s
is a particularly common problem).
....
Unfortunately, snprintf()'s variants have additional problems.
Officially, snprintf() is not a standard C function
in the ISO 1990 (ANSI 1989) standard, though sprintf() is, so not all
systems include snprintf(). Even worse,
some systems' snprintf() do not actually protect against buffer
overflows; they just call sprintf directly.
</snip>
http://www.dwheeler.com/secure-progr...rams-HOWTO.pdf
If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
2) make pointers be associated with a variable before use, not with a data
type
3) eliminate malloc, add dynamic allocation and garbage collection Eliminated by including the Boehms garbage collector4) change C to pass by reference Done in a way that inputs go into functions with values and results
are taken out from the functions by pass by references (or its C
equivalent)5) require separation of string (and other) data and flow control
information The "safe strings" have the first 100 bytes header information about
and for each arrays life, the debug mode collects info from each
function entry - exit. All functions return long long negative values
meaning intelligent error codes.
6) give up now, and try Walter Bright's D language...

D is gainning ground,
http://www.tiobe.com/tiobe_index/index.htm

Because it has everything
http://www.digitalmars.com/d/comparison.html

Well I bet their language definition is bigger than two pages and it
can not be learned in 30 minutes :)
www.tele3d.com/t3d/language.pdf

Thank You
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

[Juuso Hukkanen]

On Wed, 10 May 2006 12:05:13 -0400 (EDT), "Arthur J. O'Dwyer"
<aj*******@andrew.cmu.edu> wrote:

... This guy's been pushing its "natural language, giant
built-in library of functions" model for at least a year or so, now.
(The problems are that the "natural" language isn't, and the "built-in"
functions aren't.)
Firstly thank for very the good scanf examples. But otherwise your
characterization was not too fair. Firstly the language was published
for the October 2005. Since then I have just been busy and apart from
this hobby.
Assumingly you already understood and learned the programming
language - because you could state it being "natural language
giant-built-in-library of functions". Now compare how long it took to
learn other languages. I don't believe you have anything to complain
about the language itself, but you rather want to insult me and the
newness of this thing.

So is it such a bad thing, if all the good functions get written
properly (only) once and then nobody again need to write that function
from the scratch again.

I am 100% sure that even Arthur J. O'Dwyer would prefer to call a
function,
t3d_convert_file_Rfile_WAV2OGG_BITRATEXXX
, than to try to write a similar doing function - Right?
(The problems are that the "natural" language isn't, and the "built-in"
functions aren't.)

Assumingly that you admit that you to have learned this "natural"
language. Well
PHP created by Rasmus Lerdorf in 1994; How popular was it 8 months
after its release - not very. In June 1995 he posted info about those
PHP modules to UseNET for others who might be interested in them.
http://groups.google.com/group/comp....7d43454d64d133

Appears to be kind of similar project as this language project - And
probably Rasmus had not at that stage written the currently thousand
of functions in the PHP source library.

What did we learn, I don't know …and I can not say whether the thing
will succeed also because defining the success is not that simple (see
my reply to Jacob).

Want to see sources - help yourself:
Initial codes to pre-preprocessor & library routines:
http://www.tele3d.com/t3d/subversion.htm
http://www.tele3d.com/t3d/DEVEL/
Greetings
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

[Juuso Hukkanen]

On Wed, 10 May 2006 17:47:47 +0200, jacob navia wrote:

What is "t3d" first ???

Short question - long semi OT answer

It is a super-simple (documentation two pages) C based programming
language, with safe strings, (boehm) garbage collection, networking,
exact datatypes, GUI, multi-threading, environment etc.

Ok, key thing is that all the function calls are formulated as being
logical sentences.

You have 15 verbs: add, remove, convert, open,write…
You also have 20 objects (datatypes): byte, double, file, filepath,
url…

Then you just combine a:
verb --- > to which object the verb action is to be done ---> to which
object the results are to be written ---> and at the end you tell how
the verb action is to be done

t3d_calculate_iarray_Rdouble_STD_DEVIATION
t3d_convert_file_Rfile_GSM2WAV
t3d_measure_barray_LENGTH
t3d_convert_Rfile_READ_ONLY

The flexibility and the logicality of the t3d function prototypes
allows you to easily create or use all kinds routines. Even using
routines you didn't know to exist. Bonus is that the function
prototype works using any of the words written languages (try for
example in France).

t3d_calcule_fichier_Rdécimal_DEVIATION_STANDARD
Ok, the idea is to use C99 as much as possible but when it's not
possible then use the platform specific C extensions.
Ok, Internet is full of weird programming languages and the
competition is tough - However sometimes new programming languages do
succeed - like PHP did. I believe t3d has lots of unique qualities due
to its easiness, raw power and multi-language support.
I have a dream, I don't know if it is realizable but I try donate
the t3d language to one of the major charity organization, under a
license owned by a bunch of charity organizations. --> Therefore all
the programs that would be made e.g. by using those "ultimate t3d
libraries" or any other "under the license" staff would require a
license from some of the listed charity organizations. The charity
license would be like a dual - GPL allowing individuals to use the
software freely, while the rich country companies would require a
license.

This way the coders (anywhere) could decide to donate their opensource
works to charity organizations instead as currently donating them to
Free Software Foundation using the GPL2. The reason why I keep the
hobby of promoting the language and the (even more important) license
idea is that I sense that if this thing would succeed it could make a
big impact. Currently the Amnesty International, Red Cross and the
Greenpeace International are evaluating the license - who knows they
might like it or decide to write their own version.

Naturally it is impossible for me to write a whole language and I am
not that good coder either, but who knows what happens if for example
Slashdot would one day announce that
"Amnesty has a programming language & new OS license"

I bet there would be few programmers who would consider supporting the
initiative of building the t3d programming language ready.

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. (As said currently discussing the
transfer of those to a major charity organization).

[Kenneth Brody]

Juuso Hukkanen wrote:

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or

[...]

I've always thought that "the most dangerous part of C" was the programmer.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[jacob navia]

Kenneth Brody wrote:

Juuso Hukkanen wrote:

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or

[...]

I've always thought that "the most dangerous part of C" was the programmer.

Yeah you are right!

ELIMINATE THEM!!!!!

[pete]

Juuso Hukkanen wrote:

http://www.ida.liu.se/~johwi/researc...ate_thesis.pdf

Chapter 7.3.3 Functions which are for attracting buffer overflows
Chapter 7.3.5 Format string vulnerabilities

very good reading , and it gives references to another even better
says...

<snip>
Functions to avoid in most cases (or ensure protection) include the
functions, strcpy(3), strcat(3), sprintf(3) (with cousin vsprintf(3)),
and gets(3). These should be replaced with functions
such as strncpy(3), strncat(3), snprintf(3), and fgets(3)
respectively, but see the discussion below. The
function strlen(3) should be avoided unless you can ensure that there
will be a terminating NIL character to find.

That looks like good advice for programmers
who don't know that string functions are for using with strings,
but who want to use string functions anyway.

--
pete

[Andrew Poelstra]

On 2006-05-10, Rod Pemberton <do*********@bitfoad.cmm> wrote:

If you really want to get crazy with C, do some of these:
1) eliminate pointers in main Seems like any problems associated with that would be poor programming practice.
2) make pointers be associated with a variable before use, not with a data
type Ditto.
3) eliminate malloc, add dynamic allocation and garbage collection Now you've got a Java-like beast, only to solve programmers who can't keep
track of memory.
4) change C to pass by reference Make that C++... for the same reason.
5) require separation of string (and other) data and flow control
information I believe that is implementation-defined right now, and in some situations, such
as embedded systems, it could be problematic.
6) give up now, and try Walter Bright's D language...

I think I'll check that out...

Basically, as has been said, C's most dangerous aspect is the programmer, and
any functions that might seem worth ditching /do/ have a purpose. Except for
gets(), which has no safe usage.

[qed]

Juuso Hukkanen wrote:

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

You are recommending strncpy and strncat. These are slow functions that
occasionally leave off the terminating '\0'. I would argue that they
are therefore *WORSE* than that functions they replace. Others would
recommend strlcpy/strlcat as superior alternatives. (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.)

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)

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
I don't think people generally abuse them to that degree of detriment in
the real world. Again, if you had a *substitute*, that would be fine.
The problem is that I am not aware of any good portable PRNGs -- are you
(hence supporting the idea that C is not a portable language)? As for
non-portable ones, there are plenty (such as Mersenne Twister, or any of
the Marsaglia generators.) So as long as we are stuck with *something*
-- they still can serve a role as a quick and dirty PRNG. (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.)

Ok, as for other things that should obviously be removed: ftell() and
fseek(). Use fgetpos() and fsetpos() as the alternatives. (ftell and
fseek are simply not defined to have any useful functionality beyond
fgetpos/fsetpos and are incredibly deceptive in how they *appear* to work.)

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.)

The complex number type from C99 is in clear namespace conflict with
C++. This isn't a minor issue, since accomidating for it would
drastically reduce C++'s functionality/usefulness (C++ implements
complex numbers as a template, so that you can implement things like
Guassian Integers for example). As such, I would recommending removing
that whole set of such operations.

Ok, as to core language things -- there is also the strange issue of
function pointers. If you say:

void (* qs) (void*,size_t,size_t,int (*)(const void*,const void*));
qs = qsort;
qs = &qsort;

there is no syntax error or conflict between the last two lines (in fact
they do and mean the same thing). This means if you want to express a
pointer to a function pointer, matters are not obvious. So one or the
other should be removed.

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.)

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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Skarmander]

Kenneth Brody wrote:

Juuso Hukkanen wrote:

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or

[...]

I've always thought that "the most dangerous part of C" was the programmer.

Actually, those sharp hooks at the end of the letter is what will hurt you
every time.

Of course, C++ is even more dangerous in that regard, since it adds barbed
wire. D should be safe, though.

S.

[Ben Pfaff]

qed <us********@azillionmonkeys.com> writes:

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.)

I am unaware of a limitation on calling ungetc() at the beginning
of a file. I scanned the definition of ungetc() in C99 and
didn't see such a limitation--did I miss something?
--
"In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt." -- Blair P. Houghton

[Skarmander]

Andrew Poelstra wrote:

On 2006-05-10, Rod Pemberton <do*********@bitfoad.cmm> wrote:

If you really want to get crazy with C, do some of these:
1) eliminate pointers in main

Seems like any problems associated with that would be poor programming practice.

2) make pointers be associated with a variable before use, not with a data
type

Ditto.

3) eliminate malloc, add dynamic allocation and garbage collection

Now you've got a Java-like beast, only to solve programmers who can't keep
track of memory.

Exactly. Garbage collection is for people who are stupid or lazy or both.
Everyone knows that keeping track of memory yourself is better and cleaner.
Keeps the mind in shape and your programs fast.

Or something like that, at least.

S.

[Keith Thompson]

Skarmander <in*****@dontmailme.com> writes:

Andrew Poelstra wrote:

On 2006-05-10, Rod Pemberton <do*********@bitfoad.cmm> wrote:

If you really want to get crazy with C, do some of these:
1) eliminate pointers in main

Seems like any problems associated with that would be poor
programming practice.

2) make pointers be associated with a variable before use, not with a data
type

Ditto.

3) eliminate malloc, add dynamic allocation and garbage collection

Now you've got a Java-like beast, only to solve programmers who can't keep
track of memory.

Exactly. Garbage collection is for people who are stupid or lazy or
both. Everyone knows that keeping track of memory yourself is better
and cleaner. Keeps the mind in shape and your programs fast.

Or something like that, at least.

Right. Mnemonic identifiers are also a crutch for the weak-minded.
Objects should be identified by serial numbers, preferably in
hexadecimal. I mean, we can't very well trust computers to keep track
of things like this; most of them are prorammed by lazy people.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dave Vandervies]

In article <bm********************************@4ax.com>,
Juuso Hukkanen <ju***********@tele3d.net> wrote:

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record

Side effects.

If you don't allow anything that can have side effects, then nothing
can cause problems.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
If we assume that the programmer is unfamiliar with the language he is
using, then order of evaluation is the least of our worries.
--Joe Marshall in comp.lang.scheme

[Keith Thompson]

Keith Thompson <ks***@mib.org> writes:
[...]

Right. Mnemonic identifiers are also a crutch for the weak-minded.
Objects should be identified by serial numbers, preferably in
hexadecimal. I mean, we can't very well trust computers to keep track
of things like this; most of them are prorammed by lazy people.

In particular, some of them are "prorammed" by people who are too lazy
to proofread before posting.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[qed]

Ben Pfaff wrote:

qed <us********@azillionmonkeys.com> writes:

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.)

I am unaware of a limitation on calling ungetc() at the beginning
of a file. I scanned the definition of ungetc() in C99 and
didn't see such a limitation--did I miss something?

"For a binary stream, its file position indicator is decremented by each
successful acll to the ungetc function; if its value was zero before a
call, its indeterminate after the call".

Whatever, if you are thinking about it from an implementators point of
view, its obvious what's wrong with this whole idea. Its stupid in
exactly the same way that fgets ignoring '\0' in its input stream is
stupid. Its the only function that behaves like that in a nest of other
functions that want things to behave differently.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[CBFalconer]

qed wrote:

.... snip ...
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
I don't think people generally abuse them to that degree of detriment in
the real world. Again, if you had a *substitute*, that would be fine.
The problem is that I am not aware of any good portable PRNGs -- are you
(hence supporting the idea that C is not a portable language)? As for
non-portable ones, there are plenty (such as Mersenne Twister, or any of
the Marsaglia generators.) So as long as we are stuck with *something*
-- they still can serve a role as a quick and dirty PRNG. (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.)

Why do you consider the MT non-portable? I took one implementation
and removed the portability problems, by and large, except that I
was not sure that it would function correctly when a long was
larger that 32 bits. So my source creates an error for that
situation, leaving it up to someone else to decipher.

You can find my modification of it within the hashlib package,
where it is used to control regression testing.

<http://cbfalconer.home.att.net/download/hashlib.zip>

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[CBFalconer]

Ben Pfaff wrote:

qed <us********@azillionmonkeys.com> writes:

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.)

I am unaware of a limitation on calling ungetc() at the beginning
of a file. I scanned the definition of ungetc() in C99 and
didn't see such a limitation--did I miss something?

ungetc is absolutely essential to provide one char look ahead
operation. Without it it is impossible to properly connect
divergent parsing modules. The only case known to me where the one
char limitation creates a problem is in parsing floats with an
invalid exponential part.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Christopher Benson-Manica]

Rod Pemberton <do*********@bitfoad.cmm> wrote:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()
However, of those functions that are standard C functions, only one,
gets(), is *intrinsically* vulnerable to buffer overruns. Using the
other functions correctly is part of what separates a programmer from
a monkey banging on a keyboard.
If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
Why not just eliminate pointers altogether? There's a language that
does that for you, it's called Java. Otherwise, eliminating pointers
in some arbitrary function (be it main() or anything else) only
deprives you of a tool C gives you to write good, effective code for
no good reason.
3) eliminate malloc, add dynamic allocation and garbage collection
Again, Java does this for you. Perhaps a different language is
desired?
4) change C to pass by reference
Why, so you can have special tricks for passing by value?
6) give up now, and try Walter Bright's D language...

Or Java :-)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Christopher Benson-Manica]

Richard Heathfield <in*****@invalid.invalid> wrote:

Okay, drop gets(), scanf(), and strncpy() - ironically, this is unsafe
chiefly because people think it's safe and so they feel free to use it in a
rather cavalier way!

Alternatively, strncpy() could just work in the way we expect :-) I
always have to resort to a reference to remind myself that strncpy is,
in fact, a bit of a charlatan.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Ben Hinkle]

> 6) give up now, and try Walter Bright's D language...

D is no silver bullet. It has as many quirks as anything else. I wrote
several libraries for it over the past few years
http://home.comcast.net/~benhinkle/mintl/
http://home.comcast.net/~benhinkle/minwin/
http://home.comcast.net/~benhinkle/gmp-d/
and decided to give a shot at making something closer to C:
http://www.tinycx.org
If you read more than 1 paragraph then thanks in advance! :-)

-Ben

[qed]

Rod Pemberton wrote:

I read a security oriented pdf (sorry, don't know where anymore) which said:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()

2) 8 C functions suffer from format string vulnerabilities
printf() fprintf() sprintf() snprintf() vprintf() vfprintf() vsprintf()
vsnprintf()

Summary of pdf: Because many C implementations use the same stack for
string data and flow control information (like addresses), the above
functions can modify the flow control information on the stack thereby
allowing authorized code to execute.
That's only one kind of catastrophic failure. Personally, I would be
more focused on the fact that the failures happen in the first place.
If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
Huh? I probably need some elaboration here. Do you literally mean that
you shouldn't have local variables in main that are passed by reference
to other functions? Or ... what *do* you mean?
2) make pointers be associated with a variable before use, not with a data
type
Huh? You mean that building linked lists and similar data structures
should take an additional operation (first assign the new node malloc to
a variable) or do you mean that making such things should be impossible?
3) eliminate malloc, add dynamic allocation and garbage collection
Ok, but then you are no longer programming in C. C is a language that
allows you to understand the *performance* of your application very
clearly. Java is a language allows you to understand what it *does*
very clearly. The two languages are differentiated by this difference
in philosophy. Making C more like Java is just as easily achieved by
throwing it out and starting with Java.

However, I understand the motivation. Why not instead ask for *more*
from the C universe? There are many ways of *extending* the whole
malloc/etc paradigm to make it safer, *faster* and more powerful.
4) change C to pass by reference
Ok, no. Adding refs (the & thingy from C++) I agree with, because
passing pointers tends to more dangerous in general (more likely to pass
in NULL, or garbage/uninitialized pointers) for some cases. However to
be general, you must support *both* semantics, and C does this by
allowing you to pass a pointer in lieu of references. But don't take
away call by value from the language.
5) require separation of string (and other) data and flow control
information
You mean don't throw growable data types into non-growable arrays on a
stack? I agree. Bstrlib makes exactly this distinction (there is no
sane way to put a non-constant bstring on the stack). Perhaps only
allowing bounds protected enforced types into auto variables.
6) give up now, and try Walter Bright's D language...

Because "C++++" would have been too tacky. You could instead look at
languages like Python, Lua, and Java and ask yourself, what would it
take to design a language that was as easy to use as Python/Lua, and
safe and predictable as Java, with the speed of C?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Jordan Abel]

On 2006-05-11, CBFalconer <cb********@yahoo.com> wrote:

Ben Pfaff wrote:

qed <us********@azillionmonkeys.com> writes:

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.)

I am unaware of a limitation on calling ungetc() at the beginning
of a file. I scanned the definition of ungetc() in C99 and
didn't see such a limitation--did I miss something?

ungetc is absolutely essential to provide one char look ahead
operation. Without it it is impossible to properly connect
divergent parsing modules. The only case known to me where the one
char limitation creates a problem is in parsing floats with an
invalid exponential part.

Which is why C does the "preprocessor numbers" thing

(0xE+5 parses to a single token which is an invalid number, rather than
0xE + 5)

[Jordan Abel]

On 2006-05-11, Christopher Benson-Manica <at***@otaku.freeshell.org> wrote:

Richard Heathfield <in*****@invalid.invalid> wrote:

Okay, drop gets(), scanf(), and strncpy() - ironically, this is unsafe
chiefly because people think it's safe and so they feel free to use it in a
rather cavalier way!

Alternatively, strncpy() could just work in the way we expect :-) I
always have to resort to a reference to remind myself that strncpy is,
in fact, a bit of a charlatan.

Changing it will create problems for code that _does_ use it for what
it's intended to do.

[qed]

CBFalconer wrote:

Ben Pfaff wrote:

qed <us********@azillionmonkeys.com> writes:

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.)
I am unaware of a limitation on calling ungetc() at the beginning
of a file. I scanned the definition of ungetc() in C99 and
didn't see such a limitation--did I miss something?

ungetc is absolutely essential to provide one char look ahead
operation. Without it it is impossible to properly connect
divergent parsing modules.

This makes no sense. If you need ungetc semantics, you can create your
own file stream wrapper. Chances are you will allow more than a single
character of unreading, and you will not support things like fgetpos()
(or fseek, though I don't recommend the use of that function in general)
in your wrapper.

Because it only supports one character, it becomes stupid semantically,
much like strtok() is. You cannot call it twice in a row, mean that
once again, nestable parsing that uses this technique becomes ill
defined (just like strtok.)

There is nothing *essential* about it. And its a stupid wart you don't
want to pay for anyways.
[...] The only case known to me where the one
char limitation creates a problem is in parsing floats with an
invalid exponential part.

I don't even know what you are talking about. Parsing of files should
not rely on the ability to scan backwards and forwards through a file,
but if you really wanted to do that, why wouldn't you use
fgetpos/fsetpos instead?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Richard Heathfield]

Christopher Benson-Manica said:

Why not just eliminate pointers altogether? There's a language that
does that for you, it's called Java.

Ha, ha, ha.

Oh, yeah - ha.

(For those who don't know - in Java, *everything* is a pointer.)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Bos]

"Rod Pemberton" <do*********@bitfoad.cmm> wrote:

"Juuso Hukkanen" <ju***********@tele3d.net> wrote in message
news:bm********************************@4ax.com...

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language,
You might want to read the JF entry on Turing Tar Pit.
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>
Snigger. Yah, right. See before buying.
Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.

Stupid analogy.
I read a security oriented pdf (sorry, don't know where anymore) which said:

1) 15 C functions suffer buffer overflow problems:
gets() cuserid() scanf() fscanf() sscanf() vscanf() vsscanf() vfscanf()
sprintf() strcat() strcpy() streadd() strecpy() vsprintf() strtrns()
That list should tell you all you need to know about this document.
If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
2) make pointers be associated with a variable before use, not with a data
type
3) eliminate malloc, add dynamic allocation and garbage collection
4) change C to pass by reference
5) require separation of string (and other) data and flow control
information
6) give up now, and try Walter Bright's D language...

Alternatively, if you want C++ (or MS Sheesh!) you know where to find
it.

Richard

[Robert Latest]

On Wed, 10 May 2006 16:25:42 +0000,
Richard Heathfield <in*****@invalid.invalid> wrote
in Msg. <Se********************@bt.com>

Okay, drop gets()

I know that C99 had to be designed in such a way that all C89 code would
still compile without error, but gets() really should have been banned.
That would have nugded code maintainers towards removing gets() from
existing code, a trivial task.

OTOH all the "should haves" with respect to compatibility with old code
are moot anyway. Since every compiler in existence (and even new ones)
will have a "C89" compatibility mode, people maintaining pre-C99 code
will continue to use it (and I will continue to use it whenever I can
because I think much of C99 stinks).

robert

[Richard Heathfield]

Robert Latest said:

Since every compiler in existence (and even new ones)
will have a "C89" compatibility mode, people maintaining pre-C99 code
will continue to use it (and I will continue to use it whenever I can
because I think much of C99 stinks).

The reason that some bits of C99 don't stink is simply that they haven't yet
been implemented.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Robert Latest]

On 11 May 2006 03:58:29 GMT,
Jordan Abel <ra*******@gmail.com> wrote
in Msg. <sl**********************@random.yi.org>

Alternatively, strncpy() could just work in the way we expect :-) I
always have to resort to a reference to remind myself that strncpy is,
in fact, a bit of a charlatan.

Changing it will create problems for code that _does_ use it for what
it's intended to do.

Can you think of a meaningful piece of code that would break if
strncpy() were made safe, and where strncpy could not trivially be
replaced by memcpy? I think it is a design flaw that a str* function can
return illegal data upon being passed valid parameters ("illegal"
meaning an array of char that is not a valid C string)

robert

[Robert Latest]

On Wed, 10 May 2006 23:13:45 +0300,
Juuso Hukkanen <ju***********@tele3d.net> wrote
in Msg. <2a********************************@4ax.com>

I have a dream, I don't know if it is realizable but I try donate
the t3d language to one of the major charity organization

I'm sure they'll appreciate that.

robert

[Flash Gordon]

Robert Latest wrote:

On Wed, 10 May 2006 16:25:42 +0000,
Richard Heathfield <in*****@invalid.invalid> wrote
in Msg. <Se********************@bt.com>

Okay, drop gets()
I know that C99 had to be designed in such a way that all C89 code would
still compile without error,

No it wasn't. They got rid of implicit int which breaks any code that
uses it.
but gets() really should have been banned.
That would have nugded code maintainers towards removing gets() from
existing code, a trivial task.
Here I agree with you. They should have removed gets from the standard.
Or even made a diagnostic required for calling an external function
named gets ;-)
OTOH all the "should haves" with respect to compatibility with old code
are moot anyway. Since every compiler in existence (and even new ones)
will have a "C89" compatibility mode, people maintaining pre-C99 code
will continue to use it (and I will continue to use it whenever I can
because I think much of C99 stinks).

Yes, compilers will continue to have a C89 mode for a long time after
they implement C99 (if they ever do since some are not even trying). In
my case I need to maintain C89 compatibility because there is a high
likelihood of having to port everything (including the non-portable
code) to an implementation that has a stated intention of *never*
implementing C99. It's a shame because there are a few things from C99
that I might otherwise like to use.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[CBFalconer]

Keith Thompson wrote:

Keith Thompson <ks***@mib.org> writes:
[...]

Right. Mnemonic identifiers are also a crutch for the weak-minded.
Objects should be identified by serial numbers, preferably in
hexadecimal. I mean, we can't very well trust computers to keep track
of things like this; most of them are prorammed by lazy people.

In particular, some of them are "prorammed" by people who are too lazy
to proofread before posting.

I wonder. Some rammers are consumate professionals. Or billy goats.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Jordan Abel]

On 2006-05-11, Robert Latest <bo*******@yahoo.com> wrote:

On 11 May 2006 03:58:29 GMT,
Jordan Abel <ra*******@gmail.com> wrote
in Msg. <sl**********************@random.yi.org>

Alternatively, strncpy() could just work in the way we expect :-) I
always have to resort to a reference to remind myself that strncpy is,
in fact, a bit of a charlatan.
Changing it will create problems for code that _does_ use it for what
it's intended to do.

Can you think of a meaningful piece of code that would break if
strncpy() were made safe, and where strncpy could not trivially be
replaced by memcpy?

Doesn't matter if it can be replaced by memcpy - it's still a silent
change.
I think it is a design flaw that a str* function can
return illegal data upon being passed valid parameters ("illegal"
meaning an array of char that is not a valid C string)

robert

[Christopher Benson-Manica]

Richard Heathfield <in*****@invalid.invalid> wrote:

(For those who don't know - in Java, *everything* is a pointer.)

I was obviously included in the "those who don't know" category :-)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Richard Bos]

qed <us********@azillionmonkeys.com> wrote:

You are recommending strncpy and strncat. These are slow functions that
occasionally leave off the terminating '\0'.

Once again you demonstrate your exquisite detailed knowledge of C string
handling.

strncpy() behaves as you say; strncat() does not, and is a very useful
function.

Richard

[Robert Latest]

On Thu, 11 May 2006 00:04:15 GMT,
qed <us********@azillionmonkeys.com> wrote
in Msg. <3c*******************@newssvr11.news.prodigy.co m>

You are recommending strncpy and strncat. These are slow functions that
occasionally leave off the terminating '\0'.
Apart from the fact that strncat never leaves off the trailing zero,
what do you know about the execution speed of these functions?
fgets is not an ideal substitute for gets as explained here:
http://www.pobox.com/~qed/userInput.html
That "explanation" lumps together several pathological cases of
fgets()'s shortcomings that never occur simultaneously.
The complex number type from C99

is bullshit, like many C99 "features".

robert

[Robert Latest]

On Thu, 11 May 2006 10:09:38 +0100,
Flash Gordon <sp**@flash-gordon.me.uk> wrote
in Msg. <dj************@news.flash-gordon.me.uk>

It's a shame because there are a few things from C99
that I might otherwise like to use.

Like what? I'm genuinely interested. So far I haven't met anybody who
found much of C99 useful.

robert

[Robert Latest]

On 11 May 2006 10:38:24 GMT,
Jordan Abel <ra*******@gmail.com> wrote
in Msg. <sl**********************@random.yi.org>

Doesn't matter if it can be replaced by memcpy - it's still a silent
change.

True.

[Flash Gordon]

Robert Latest wrote:

On Thu, 11 May 2006 10:09:38 +0100,
Flash Gordon <sp**@flash-gordon.me.uk> wrote
in Msg. <dj************@news.flash-gordon.me.uk>

It's a shame because there are a few things from C99
that I might otherwise like to use.

Like what? I'm genuinely interested. So far I haven't met anybody who
found much of C99 useful.

Off the top of my head:

compound literals -
passing a constant to a function expecting a struct

stdint.h -
I'm doing database stuff with an old fashioned database where the
data has to be compatible across multiple machines. So defined
width integer types would be useful, as would the fast types.
Still have to handle endianness, of course.

snprintf -
The MS implementation of _snprintf is *not* the same

Increase in the mimimum number of significant characters in
identifiers (I rely on more than the C89 minimum anyway)

long long (a 64 bit or wider integer type would be of use)
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Juuso Hukkanen]

On Wed, 10 May 2006 12:14:56 -0400, "P.J. Plauger"
<pj*@dinkumware.com> wrote:

"Juuso Hukkanen" <ju***********@tele3d.net> wrote in message
news:bm********************************@4ax.com.. .

I am looking for a wish list of things which should be removed from
the C (C99) - due to feature's bad security track record <OT>or
Multithreading unsafety. I need this list for a project intending to
build another (easiest & most powerful) programming language, which
has a two page definition document stating: "... includes C
programming language (C99), except its famous
"avoid-using-this-functions". </OT>

If you would not want to remove a whole function but only the use of
it with certain arguments / parameters, what would those combinations
be like? (Like scanf with %s or %[ arguments )

Probably there are official not to use recommendation lists.
( million times better than this)
http://tele3d.com/wiki/index.php/Par...ncluded_in_t3d

Please, do not circumvent the question by saying all functions except
gets() are safe if used properly. That would be like teaching that
"the ideology of Soviet Union was right, it was the Soviet peoples
fault that the system didn't work.
One very popular wish list is Misra C. (Actuall two, since there's a
revision out too.) It endeavors to tame C by outlawing all sorts of
usages that some people think *might* be misused.

70 pages full of recommndations - That does not leave programmes much
room for making disasterous error - booring. Besides they charge 50$
for their can't-touch-this list.
Another is Microsoft's secure/safer/bounded C, a version of which is
now shipping with VC++ V8. It supplies alternatives to many functions
that can be better bounds checked to avoid storage overwrites. This
work is based on Microsoft's massive bug hunt stimulated by all the
viral attacks on Microsoft software largely written in C.
Good stuff summarizing: MS is advancing the C. They identify C's null
terminated strings as the biggest source of problems and suggest a
whole pattern of safer string functions. Noteworthly MS is also
suggesting a successor for strlen - which has not been suggested in
this thread earlier. MS has (in 9/2005) made a draft to C working
group about these _s safer functions
http://www.open-std.org/jtc1/sc22/wg...docs/n1135.pdf
Quick scanning tells the amount of suggested 'safer functions' appears
to be atleast 68.

The list of suggested safer functions is below. Basically that list
then gives a list of C's problem functions /defines /macros:

asctime_s
bsearch_s
ctime_s
fopen_s
fprintf_s
freopen_s
fscanf_s
fwprintf_s
fwscanf_s
getenv_s
gets_s
gmtime_s
L_tmpnam_s
localtime_s
mbsrtowcs_s
mbstowcs_s
memcpy_s
memmove_s
printf_s
qsort_s
scanf_s
snprintf_s
snwprintf_s
sprintf_s
sscanf_s
strcat_s
strcpy_s
strerror_s
strerrorlen_s
strncat_s
strncpy_s
strnlen_s
strtok_s
swprintf_s
swscanf_s
TMP_MAX_S
tmpfile_s
tmpnam_s
wcrtomb_s
wcrtoms_s
wcscat_s
wcscpy_s
wcsncat_s
wcsncpy_s
wcsnlen_s
wcsrtombs
wcsrtombs_s
wcstok_s
wcstombs_s
wctomb_s
vfprintf_s
vfscanf_s
vfwprintf_s
vfwscanf_s
wmemcpy_s
wmemmove_s
vprintf_s
wprintf_s
vscanf_s
wscanf_s
vsnprintf_s
vsnwprintf_s
vsprintf_s
vsscanf_s
vswprintf_s
vswscanf_s
vwprintf_s
vwscanf_s
Neither is anywhere near perfect, nor universally accepted. Both are
places to start.

hmm, I'll try to spot the worst ones
Thank you
Juuso Hukkanen
(to reply by e-mail set addresses month and year to correct)
www.tele3d.com

[Rod Pemberton]

"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:44***********************@news.wanadoo.fr...

Rod Pemberton a écrit :

If you really want to get crazy with C, do some of these:
1) eliminate pointers in main
????

Think about 1) and 3). If pointers in main are eliminated, then all memory
allocations would need to static or dynamic.

2) make pointers be associated with a variable before use, not with a data type

lcc-win32: done.
References are pointers associated with an object permanently.

3) eliminate malloc, add dynamic allocation and garbage collection

lcc-win32: done.
The gc is standard in the normal distribution.

4) change C to pass by reference

?????
Why?

Much easier to program. Sorry, this comes from my PL/1 experience. Many C
compilers convert the code to pass by reference for assembly anyway...

5) require separation of string (and other) data and flow control
information

Stack allocation is ok if used correctly. Making all objects heap based
would slow done everything without a lot of gain in security.

That depends on how it is implemented. Dual stacks, ala FORTH, have minimal
overhead on certain systems, including IA-32.

6) give up now, and try Walter Bright's D language...

????

With the above improvements, C can be much easier and safer to program.

Go for it!
Rod Pemberton