By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,389 Members | 1,847 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,389 IT Pros & Developers. It's quick & easy.

Safe subset of C?

P: n/a
I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes
* Recovery from invalid and NULL pointers other than crash
* Possibility to isolate piece of code by not giving it key pointers

Library used to support such safe subset must not introduce its own flaws.
For example, it is not a good idea to use int proxies for pointers like
Unix API does, because this allows pointer guessing and consequently
prevents isolation.

Nov 13 '05 #1
Share this Question
Share on Google+
36 Replies


P: n/a
Robert Vazan wrote:
I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes
* Recovery from invalid and NULL pointers other than crash
* Possibility to isolate piece of code by not giving it key pointers

Library used to support such safe subset must not introduce its own flaws.
For example, it is not a good idea to use int proxies for pointers like
Unix API does, because this allows pointer guessing and consequently
prevents isolation.


Robert...

Search in Google groups (comp.lang.c). There have already been a
number of threads discussing this topic.

--
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

Nov 13 '05 #2

P: n/a
Robert Vazan wrote:
I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes
* Recovery from invalid and NULL pointers other than crash
* Possibility to isolate piece of code by not giving it key pointers

Library used to support such safe subset must not introduce its own flaws.
For example, it is not a good idea to use int proxies for pointers like
Unix API does, because this allows pointer guessing and consequently
prevents isolation.


Look at MISRA C guidelines, at www.misra.org.uk, which is enforcable
with commercial lint-like tools. You must order a hardcopy. I did and
found it to be an interesting read.

However, if you're really interested in high-integrity coding, perhaps
something like SPARK (Ada subset) may interest you as well.

If you insist on something C-based, MISRA-C with something like VxWorks
for Safety Critical Systems (www.windriver.com) may be a candidate,
depending on what you're looking for.
Mark F. Haigh
mf*****@sbcglobal.net

Nov 13 '05 #3

P: n/a
On Fri, 21 Nov 2003 13:47:49 +0100, Robert Vazan wrote:
I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes


It occurs to me that this requirement alone pretty much removes your
quest from anything remotely related to C.
Nov 13 '05 #4

P: n/a
"Kelsey Bjarnason" <ke*****@lightspeed.bc.ca> wrote:
On Fri, 21 Nov 2003 13:47:49 +0100, Robert Vazan wrote:
By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of
bytes


It occurs to me that this requirement alone pretty much removes
your quest from anything remotely related to C.


It depends how you define "remotely related to C". You would essentially
have to disallow pointer arithmetic and therefore change the way that
arrays work. It starts to look quite like Java, and indeed Java has many
features for limited 'sandbox' operation inbuilt, for running unauthorised
code on client machines. I'd say Java is still related to C.

--
Simon.
Nov 13 '05 #5

P: n/a
On 2003-11-22, Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
On Fri, 21 Nov 2003 13:47:49 +0100, Robert Vazan wrote:
I am looking for other people's attempts to create safe subset of C and
enforce it with scripts. Does anybody know about anything like this?

By "safe", I mean the following:
* Strongly typed memory. No way to reinterpret it as bunch of bytes


It occurs to me that this requirement alone pretty much removes your
quest from anything remotely related to C.


It is a "safe subset". You could define a subset that:

* does not allow the use of unions;
* does not allow declarations of void pointers;
* does not allow defining functions that return void pointers; and
* does not allow casts.

You could write a lint like tool to help enforce the subset. Also, any
diagnostic emitted by the compiler would have to be addressed.

-- James
Nov 13 '05 #6

P: n/a
On Sat, 22 Nov 2003 00:08:59 -0600, James Hu wrote:
* does not allow the use of unions;
* does not allow declarations of void pointers;
* does not allow defining functions that return void pointers; and
* does not allow casts.


Add arrays, ellipsis arguments, and memory deallocation and I can start
considering it safe. Some replacement must be provided for arrays and
memory management. Your rules also prohibit interfaces.

Nov 13 '05 #7

P: n/a
On 2003-11-22, Robert Vazan <ro*********@privateweb.sk> wrote:
On Sat, 22 Nov 2003 00:08:59 -0600, James Hu wrote:
* does not allow the use of unions;
* does not allow declarations of void pointers;
* does not allow defining functions that return void pointers; and
* does not allow casts.
Add arrays,


Why? I was questioning myself about disallowing unions. Since acquiring
the value of a member union other than the last one stored into invokes
unspecified behavior, a "good enough" lint should be able to flag this.

Similarly for arrays, bounds checking should be enforced.

I guess the safe subset should explicitly state:

* does not allow unspecified or undefined behaviors.
ellipsis arguments,
Yes, I suppose definining your own varable argument functions should be
disallowed. Using printf and friends should be allowed, though.
and memory deallocation and I can start
considering it safe.
Hmm? If you disallow memory deallocation, you have to disallow memory
allocation as well.

If unspecified and undefined behaviors are not allowed, memory
deallocation should be safe.

I guess one could require an interface for each type to be allocated and
deallocated:

int * malloc_int_array(int number_of_ints);
void free_int_array(int *int_array);

And have the free wrapper do whatever it needed to do to make sure it
was freeing something its corresponding wrapper allocated. But a good
memory error debugging tool can already help enforce that.
Some replacement must be provided for arrays and
memory management.
I think I took care of that.
Your rules also prohibit interfaces.


How so?

-- James
Nov 13 '05 #8

P: n/a
>It is a "safe subset". You could define a subset that:

* does not allow the use of unions;
* does not allow declarations of void pointers;
* does not allow defining functions that return void pointers; and
* does not allow casts.

You could write a lint like tool to help enforce the subset. Also, any
diagnostic emitted by the compiler would have to be addressed.


A really "safe" subset of C needs to disallow:

- Pointers or pointer-valued expressions, including (library or
otherwise) functions that accept or return them.
- Variables.
- Side effects, particularly including assignment, op= operators,
I/O, and memory allocation/deallocation.
- Casts.

I think it is possible to have the compiler compile this to "safe"
assembly language with one of three opcodes: halt EXIT_SUCCESS,
halt EXIT_FAILURE, or branch-to-self.

Gordon L. Burditt
Nov 13 '05 #9

P: n/a
On Sat, 22 Nov 2003 12:45:39 -0600, James Hu wrote:
On 2003-11-22, Robert Vazan <ro*********@privateweb.sk> wrote:
Add arrays,
Why?


Bounds of simple C arrays can be looked up, but it is computationally
costly. It is better to store item count next to the array, which
implies custom array type, so no raw C arrays.
I was questioning myself about disallowing unions. Since acquiring
the value of a member union other than the last one stored into invokes
unspecified behavior, a "good enough" lint should be able to flag this.
That's heuristics. It catches such behavior sometimes, but not always.
Heuristic tools increase in complexity without bounds and they never quite
make it.
If unspecified and undefined behaviors are not allowed, memory
deallocation should be safe.
Deallocation invalidates all variables that pointed into freed area. I
need working verifier, not just 1000 pages of rules. Undefined behaviors
that appear during memory deallocation cannot be catched without aiding
verifier with extra syntax.
I guess one could require an interface for each type to be allocated and
deallocated:

int * malloc_int_array(int number_of_ints);
void free_int_array(int *int_array);

And have the free wrapper do whatever it needed to do to make sure it
was freeing something its corresponding wrapper allocated.


Standard malloc and free can do this already.
Your rules also prohibit interfaces.


How so?


I should have said virtual functions. Virtual functions need to downcast
pointer passed to them. C++ will do it invisibly and safely, but C
requires cast from void pointer to structure pointer.

Nov 13 '05 #10

P: n/a
On Sun, 23 Nov 2003 01:21:18 +0000, Gordon Burditt wrote:
A really "safe" subset of C needs to disallow:
Here I assume that you claim that this is best (least restrictive) safe
subset that can be made.
- Pointers or pointer-valued expressions, including (library or
otherwise) functions that accept or return them.
Too restrictive. You cannot show that it is necessary.
- Variables.
Why?
- Side effects, particularly including assignment, op= operators,
Why?
I/O,
Standard I/O maybe, but why all I/O?
and memory allocation/deallocation.
Unnecessarily restrictive, once again.
I think it is possible to have the compiler compile this to "safe"
assembly language with one of three opcodes: halt EXIT_SUCCESS,
halt EXIT_FAILURE, or branch-to-self.


Sure, but I am uncertain whether your subset is really the only option.

Nov 13 '05 #11

P: n/a
"Robert Vazan" <ro*********@privateweb.sk> wrote:
On Sun, 23 Nov 2003 01:21:18 +0000, Gordon Burditt wrote:
I think it is possible to have the compiler compile this to "safe"
assembly language with one of three opcodes: halt EXIT_SUCCESS,
halt EXIT_FAILURE, or branch-to-self.


Sure, but I am uncertain whether your subset is really the only option.


I am reasonably certain that Gordon was joking!

However, it does bear some wisdom -- a completely 'safe subset' is
a pipe dream.

A static compile-time lint checker is quite limited; you can do a lot
more with run-time checking for array bounds, format specifiers,
generally regulating access to memory.

--
Simon.
Nov 13 '05 #12

P: n/a
On 2003-11-23, Robert Vazan <ro*********@privateweb.sk> wrote:
On Sat, 22 Nov 2003 12:45:39 -0600, James Hu wrote:
On 2003-11-22, Robert Vazan <ro*********@privateweb.sk> wrote:
Add arrays,


Why?


Bounds of simple C arrays can be looked up, but it is computationally
costly. It is better to store item count next to the array, which
implies custom array type, so no raw C arrays.


You want a safe C subset with built-in runtime protection? Just use
a safer language.

In C, I would say your best option is to use tests to achieve code
coverage and boundary conditions on code that is instrumented
specifically to catch such errors, and this instrumentation should be
compile time removable once verification is complete.

Some of waht you want to do can be achieved through static analysis,
but requires extra hints provided in the form of stylized comments
that the preprocessor can understand.
I was questioning myself about disallowing unions. Since acquiring
the value of a member union other than the last one stored into
invokes unspecified behavior, a "good enough" lint should be able to
flag this.


That's heuristics. It catches such behavior sometimes, but not always.
Heuristic tools increase in complexity without bounds and they never
quite make it.


Of course they are complex. But writing provably correct code can also
increase in complexity without bounds (the complexity of writing the
code increases with the complexity of the software specification), and
some would argue they never quite make it either.
If unspecified and undefined behaviors are not allowed, memory
deallocation should be safe.


Deallocation invalidates all variables that pointed into freed area. I
need working verifier, not just 1000 pages of rules. Undefined
behaviors that appear during memory deallocation cannot be catched
without aiding verifier with extra syntax.


A runtime diagnostic tool, such as purify, can verify the correctness
of your program with proper test coverage.
I guess one could require an interface for each type to be allocated and
deallocated:

int * malloc_int_array(int number_of_ints);
void free_int_array(int *int_array);

And have the free wrapper do whatever it needed to do to make sure it
was freeing something its corresponding wrapper allocated.


Standard malloc and free can do this already.


My suggestion prevents allocating a structure and assigning it to some
other pointer type.
Your rules also prohibit interfaces.


How so?


I should have said virtual functions. Virtual functions need to
downcast pointer passed to them. C++ will do it invisibly and safely,
but C requires cast from void pointer to structure pointer.


Downcasting can be performed safely with the proper instrumentation.
The objects that is the context of the interface should be opaque,
and the function that creates such objects can set a special
field with a signature value that the other routines can check
against before attempting the downcast.

If my rules are relaxed to remove the union restriction (but still
prohibit unspecified and undefined behavior), as I had suggested
earlier, then the downcasting can be safely achieved via accessing union
members at the cost of explicitly enumerating the types that are safe to
downcast to.

-- James
Nov 13 '05 #13

P: n/a
On Mon, 24 Nov 2003 01:37:17 +1100, Simon Biber wrote:
I am reasonably certain that Gordon was joking!
I understood it too. Jokes are often used to make a claims that nobody can
argue with (it was joke, so what), but that still make it into minds of
people. I wanted to show that I don't share his pessimistic view.
However, it does bear some wisdom -- a completely 'safe subset' is
a pipe dream.
What, Java sandbox doesn't work? I must disable it in my browser...
Processes don't work? Poor ISPs granting shell access to customers. I know
that both Java and Unix have security holes, but the concept is good.
A static compile-time lint checker is quite limited; you can do a lot
more with run-time checking for array bounds, format specifiers,
generally regulating access to memory.


Supporting library can do run-time checking instead of language. Verifier
can then enforce use of the library. The art is to design it so that the
result still looks like C.

Nov 13 '05 #14

P: n/a
On Sun, 23 Nov 2003 10:41:40 -0600, James Hu wrote:
You want a safe C subset with built-in runtime protection? Just use
a safer language.
C has certain advantages like tool support, simplicity, and large share of
smart programmers. The only debugger for Java is in Microsoft's J++, AFAIK.
Some of waht you want to do can be achieved through static analysis,
but requires extra hints provided in the form of stylized comments
that the preprocessor can understand.
Stylized comments are acceptable.
But writing provably correct code can also
increase in complexity without bounds (the complexity of writing the
code increases with the complexity of the software specification), and
some would argue they never quite make it either.


Proof for certain aspects can be easy to inline into code and easy to
verify. Complexity grows up only if you try to prove everything. Allowing
small library to protect itself is just about enough for me.

Nov 13 '05 #15

P: n/a
On Sun, 23 Nov 2003 18:40:21 +0100, Robert Vazan wrote:
On Mon, 24 Nov 2003 01:37:17 +1100, Simon Biber wrote:
A static compile-time lint checker is quite limited; you can do a lot
more with run-time checking for array bounds, format specifiers,
generally regulating access to memory.


Supporting library can do run-time checking instead of language. Verifier
can then enforce use of the library. The art is to design it so that the
result still looks like C.


Why? If you don't like how C works, why not just use a different language?

Nov 13 '05 #16

P: n/a
Robert Vazan wrote:

<snip>
[...] C requires cast from void pointer to structure pointer.


No, it doesn't.

#include <time.h>
void foo(void *p)
{
struct tm *ptm = p; /* no cast required */
}

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #17

P: n/a
On 2003-11-23, Robert Vazan <ro*********@privateweb.sk> wrote:
On Sun, 23 Nov 2003 10:41:40 -0600, James Hu wrote:
Some of waht you want to do can be achieved through static analysis,
but requires extra hints provided in the form of stylized comments
that the preprocessor can understand.
Stylized comments are acceptable.


http://www.google.com/search?q=splint&btnI=I'm+Feeling+Lucky
But writing provably correct code can also increase in complexity
without bounds (the complexity of writing the code increases with the
complexity of the software specification), and some would argue they
never quite make it either.


Proof for certain aspects can be easy to inline into code and
easy to verify.


That is rather simplistic view, and it is a naive application that
leaves such verification code enabled all the time (e.g., verifying
qsort really sorted the array after each invocation).
Complexity grows up only if you try to prove everything.
Allowing small library to protect itself is just about
enough for me.


Complexity grows whenever the system you are verifying becomes more
complex. Suppose you are just verifying a small library. Whenever
you add a new interface, you have increased the complexity and the
proof burden. This is true both of interfaces you expose to clients
of the library, but also of interfaces to other sub-systems that
the small library is dependent upon.

Program correctness is getting to be off-topic for this newsgroup.
If you want to pursue the issue further, I would suggest following
up in comp.software-eng.

Anyway, most C programmers will use assert() (or implement their own
variation of it) to verify assumptions.

-- James
Nov 13 '05 #18

P: n/a
On Sun, 23 Nov 2003 18:55:58 +0100, Robert Vazan wrote:
On Sun, 23 Nov 2003 10:41:40 -0600, James Hu wrote:
You want a safe C subset with built-in runtime protection? Just use
a safer language.
C has certain advantages like tool support, simplicity, and large share of
smart programmers.


I guess you figure that all those "smart programmers" are incapable of
using any other language. I can't speak for anyone else, but I wouldn't be
interested in working in crippled C. However, I have no problem learning a
new language if that's what the project requires.
The only debugger for Java is in Microsoft's J++, AFAIK.


There are many debuggers for Java, usually integrated in one of the very
many IDEs for Java. There is also a command line debugger that comes with
the standard java distribution.
Nov 13 '05 #19

P: n/a

"Robert Vazan" <ro*********@privateweb.sk> wrote in message
news:pa****************************@privateweb.sk. ..
On Mon, 24 Nov 2003 01:37:17 +1100, Simon Biber wrote:
I am reasonably certain that Gordon was joking!
I understood it too. Jokes are often used to make a claims that nobody can
argue with (it was joke, so what), but that still make it into minds of
people. I wanted to show that I don't share his pessimistic view.
However, it does bear some wisdom -- a completely 'safe subset' is
a pipe dream.


What, Java sandbox doesn't work? I must disable it in my browser...


It has the potential for misuse, such as spamming lots of windows or
unkillable dialog boxes... see even the javascript (yes I know it's
not Java, but it's still an example of a sandboxed language):
while(1) alert("Please Click OK");
which on many (older) browsers required a forced kill of the program.
Processes don't work? Poor ISPs granting shell access to customers. I know
that both Java and Unix have security holes, but the concept is good.


Fewer and fewer ISPs do grant shell access in my experience. The costs
associated with system admin and general policing of customers are high.
A static compile-time lint checker is quite limited; you can do a lot
more with run-time checking for array bounds, format specifiers,
generally regulating access to memory.


Supporting library can do run-time checking instead of language. Verifier
can then enforce use of the library. The art is to design it so that the
result still looks like C.


So you need to regulate array access; how? Your supporting library must
hook into every single array access:

int int_item( const int *array, size_t index);
long long_item( const long *array, size_t index);
short short_item( const short *array, size_t index);
double double_item(const double *array, size_t index);
float float_item( const float *array, size_t index);
char char_item( const char *array, size_t index);
etc.

Then you must redefine every single library function so it accesses arrays in
terms of these accessor functions?!

--
Simon.
Nov 13 '05 #20

P: n/a
On Mon, 24 Nov 2003 11:34:28 +1100, Simon Biber wrote:
"Robert Vazan" <ro*********@privateweb.sk> wrote in message
news:pa****************************@privateweb.sk. ..
What, Java sandbox doesn't work? I must disable it in my browser...
It has the potential for misuse, such as spamming lots of windows or
unkillable dialog boxes... see even the javascript (yes I know it's
not Java, but it's still an example of a sandboxed language):
while(1) alert("Please Click OK");
which on many (older) browsers required a forced kill of the program.


That's acceptable. It's not fault of language. It's fault of library that
provides windows. I care about language for now. Let's keep the goal
finite.
So you need to regulate array access; how? Your supporting library must
hook into every single array access:

int int_item( const int *array, size_t index);
I think that the array would have to be structure of some sort, so that
item count can be stored somewhere. Another option is to make it easy to
automatically find out which variable holds item count. Verifier can then
look whether all branches leading to array access performed bounds
checking on index.
Then you must redefine every single library function so it accesses
arrays in terms of these accessor functions?!


There is no hope to support legacy code. Unchecked libraries can be, of
course, linked with to maintain compatibility.

Nov 13 '05 #21

P: n/a
On Sun, 23 Nov 2003 15:00:37 -0600, James Hu wrote:
http://www.google.com/search?q=splint&btnI=I'm+Feeling+Lucky
Thanks. It's heuristics, so I cannot take too many ideas from it. It might
be useful on other projects.
That is rather simplistic view, and it is a naive application that
leaves such verification code enabled all the time (e.g., verifying
qsort really sorted the array after each invocation).


I don't want to verify that qsort actually sorts the array. I just want to
verify that it doesn't write to memory to which it never got pointer and
that it doesn't crash. I cannot do this with standard qsort, of course,
but I should be able to do this with code that I have written.

Nov 13 '05 #22

P: n/a
On Sun, 23 Nov 2003 19:17:27 -0500, Sheldon Simms wrote:
I guess you figure that all those "smart programmers" are incapable of
using any other language.
I didn't want to offend you. I am also capable of using other languages,
but I have got very sensitive to quality of tools and I am consequently
very sceptical about any new language.
I can't speak for anyone else, but I wouldn't be
interested in working in crippled C.
So you compile with warnings turned off?
However, I have no problem learning a
new language if that's what the project requires.


That's how I learned most of languages that I know. However I am now
making the choice myself. Nobody requires me to use anything.

It's more of a hobby project and my priority is simplicity. I thought that
C is the right choice in this direction. I think that the safe subset will
simplify it further. It's true that the supporting library is going to
make it more complex, but I don't see how choice of language could affect
it.
The only debugger for Java is in Microsoft's J++, AFAIK.


There are many debuggers for Java, usually integrated in one of the very
many IDEs for Java. There is also a command line debugger that comes with
the standard java distribution.


Sorry, I shouldn't pick up whatever rumors pass by, no matter who
distributes them.

Nov 13 '05 #23

P: n/a
On Mon, 24 Nov 2003 19:06:16 +0100, Robert Vazan wrote:
On Sun, 23 Nov 2003 19:17:27 -0500, Sheldon Simms wrote:
I can't speak for anyone else, but I wouldn't be
interested in working in crippled C.


So you compile with warnings turned off?


Warnings don't prevent me from doing anything, and lots of things
that you want to disallow, such as treating any object as an array
of bytes, can be done perfectly safely and portably.
Nov 13 '05 #24

P: n/a
On Mon, 24 Nov 2003 19:06:16 +0100, Robert Vazan wrote:
On Sun, 23 Nov 2003 19:17:27 -0500, Sheldon Simms wrote:
I guess you figure that all those "smart programmers" are incapable of
using any other language.


I didn't want to offend you. I am also capable of using other languages,
but I have got very sensitive to quality of tools and I am consequently
very sceptical about any new language.
I can't speak for anyone else, but I wouldn't be
interested in working in crippled C.


So you compile with warnings turned off?


Having warnings enabled doesn't cripple C; it just lets you know when
you've done something that probably isn't actually C at all. :)
Nov 13 '05 #25

P: n/a
On 2003-11-24, Robert Vazan <ro*********@privateweb.sk> wrote:
On Sun, 23 Nov 2003 15:00:37 -0600, James Hu wrote:
That is rather simplistic view, and it is a naive application that
leaves such verification code enabled all the time (e.g., verifying
qsort really sorted the array after each invocation).


I don't want to verify that qsort actually sorts the array. I just
want to verify that it doesn't write to memory to which it never got
pointer and that it doesn't crash. I cannot do this with standard
qsort, of course, but I should be able to do this with code that I
have written.


There are already tools that do this. A web search for memory
debugging tools will provide many hits.

-- James
Nov 13 '05 #26

P: n/a
In article <pa****************************@lightspeed.bc.ca >,
Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
On Mon, 24 Nov 2003 19:06:16 +0100, Robert Vazan wrote:
On Sun, 23 Nov 2003 19:17:27 -0500, Sheldon Simms wrote:
I guess you figure that all those "smart programmers" are incapable of
using any other language.


I didn't want to offend you. I am also capable of using other languages,
but I have got very sensitive to quality of tools and I am consequently
very sceptical about any new language.
I can't speak for anyone else, but I wouldn't be
interested in working in crippled C.


So you compile with warnings turned off?


Having warnings enabled doesn't cripple C; it just lets you know when
you've done something that probably isn't actually C at all. :)


If it isn't C at all you would get an error. If you get a warning, it's
most likely perfectly legal C that in some non-obvious way does
something entirely different from what you intended.
Nov 13 '05 #27

P: n/a
In <ch*********************************@slb-newsm1.svr.pol.co.uk> Christian Bau <ch***********@cbau.freeserve.co.uk> writes:
In article <pa****************************@lightspeed.bc.ca >,
Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
On Mon, 24 Nov 2003 19:06:16 +0100, Robert Vazan wrote:
> On Sun, 23 Nov 2003 19:17:27 -0500, Sheldon Simms wrote:
>
>> I guess you figure that all those "smart programmers" are incapable of
>> using any other language.
>
> I didn't want to offend you. I am also capable of using other languages,
> but I have got very sensitive to quality of tools and I am consequently
> very sceptical about any new language.
>
>> I can't speak for anyone else, but I wouldn't be
>> interested in working in crippled C.
>
> So you compile with warnings turned off?


Having warnings enabled doesn't cripple C; it just lets you know when
you've done something that probably isn't actually C at all. :)


If it isn't C at all you would get an error. If you get a warning, it's
most likely perfectly legal C that in some non-obvious way does
something entirely different from what you intended.


Many compilers generate mandatory diagnostics as warnings. The following
hardly qualifies as a perfectly legal C program:

fangorn:~/tmp 214> cat test.c
int main()
{
char *p = 1;
return sizeof(void);
}
fangorn:~/tmp 215> gcc -ansi -pedantic test.c
test.c: In function `main':
test.c:3: warning: initialization makes pointer from integer without a cast
test.c:4: warning: sizeof applied to a void type
fangorn:~/tmp 216>

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #28

P: n/a
On Tue, 25 Nov 2003 01:01:10 -0600, James Hu wrote:
There are already tools that do this. A web search for memory
debugging tools will provide many hits.


They aren't suitable for release code. And even in debug code, they crash
the program. It's just that they crash it near to point of error.

Nov 13 '05 #29

P: n/a
On Mon, 24 Nov 2003 15:29:41 -0500, Sheldon Simms wrote:
Warnings don't prevent me from doing anything, and lots of things
You can get warning that not all members of enum are enumerated in switch
statement. You can get warning about missing return statement even if you
know that end of function is unreachable.
that you want to disallow, such as treating any object as an array of
bytes, can be done perfectly safely and portably.


The only thing that you can do portably is copying those bytes to new
location. Reflection and metadata can do much more and they are type-safe.

Nov 13 '05 #30

P: n/a
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <pa****************************@lightspeed.bc.ca >,
Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
On Mon, 24 Nov 2003 19:06:16 +0100, Robert Vazan wrote:
> On Sun, 23 Nov 2003 19:17:27 -0500, Sheldon Simms wrote:
>
>> I guess you figure that all those "smart programmers" are incapable of
>> using any other language.
>
> I didn't want to offend you. I am also capable of using other languages,
> but I have got very sensitive to quality of tools and I am consequently
> very sceptical about any new language.
>
>> I can't speak for anyone else, but I wouldn't be
>> interested in working in crippled C.
>
> So you compile with warnings turned off?


Having warnings enabled doesn't cripple C; it just lets you know when
you've done something that probably isn't actually C at all. :)

If it isn't C at all you would get an error. If you get a warning, it's
most likely perfectly legal C that in some non-obvious way does
something entirely different from what you intended.


AFAIK "diagnostics" need only be output from the compiler,
not specifically as "errors" or "warnings".

Alex
Nov 13 '05 #31

P: n/a
On Tue, 25 Nov 2003 18:14:22 +0100, Robert Vazan wrote:
On Mon, 24 Nov 2003 15:29:41 -0500, Sheldon Simms wrote:
Warnings don't prevent me from doing anything, and lots of things


You can get warning that not all members of enum are enumerated in switch
statement. You can get warning about missing return statement even if you
know that end of function is unreachable.


Indeed. How is C crippled by such warnings?
that you want to disallow, such as treating any object as an array of
bytes, can be done perfectly safely and portably.


The only thing that you can do portably is copying those bytes to new
location. Reflection and metadata can do much more and they are type-safe.


What does that have to do with C?

Nov 13 '05 #32

P: n/a
[snips]

On Tue, 25 Nov 2003 07:58:14 +0000, Christian Bau wrote:
Having warnings enabled doesn't cripple C; it just lets you know when
you've done something that probably isn't actually C at all. :)


If it isn't C at all you would get an error.


Really? Hmm.

[kelseyb@baldur]$ gcc test.c
test.c: In function `main':
test.c:3: warning: `return' with a value, in function returning void
test.c:2: warning: return type of `main' is not `int'

The code:

void main()
{
return 0;
}
Seems I get a warning, not an error with warnings enabled. So, you're
suggesting that void main() is, in fact, C? As I recall, the standards
explicitly state that main returns int, not void, not double, not pointer
to char, but int, and anything else ain't C.
Nov 13 '05 #33

P: n/a
On 2003-11-25, Robert Vazan <ro*********@privateweb.sk> wrote:
On Tue, 25 Nov 2003 01:01:10 -0600, James Hu wrote:
There are already tools that do this. A web search for memory
debugging tools will provide many hits.


They aren't suitable for release code. And even in debug code, they crash
the program. It's just that they crash it near to point of error.


Not all of them behave as you describe. I am offering you the
suggestion to encourage you to not re-invent the wheel.

-- James
Nov 13 '05 #34

P: n/a
Alex <al*******@hotmail.com> scribbled the following:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <pa****************************@lightspeed.bc.ca >,
Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
Having warnings enabled doesn't cripple C; it just lets you know when
you've done something that probably isn't actually C at all. :)
If it isn't C at all you would get an error. If you get a warning, it's
most likely perfectly legal C that in some non-obvious way does
something entirely different from what you intended.
AFAIK "diagnostics" need only be output from the compiler,
not specifically as "errors" or "warnings".


So does this:

"ISO says I have to issue a diagnostic here. So to keep them happy I'll
do so."

qualify as a mandatory diagnostic for a case for which the ISO C
standard mandates one?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"To err is human. To really louse things up takes a computer."
- Anon
Nov 14 '05 #35

P: n/a
In article <br**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:
Alex <al*******@hotmail.com> scribbled the following:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
If it isn't C at all you would get an error. If you get a warning, it's
most likely perfectly legal C that in some non-obvious way does
something entirely different from what you intended.

AFAIK "diagnostics" need only be output from the compiler,
not specifically as "errors" or "warnings".


So does this:

"ISO says I have to issue a diagnostic here. So to keep them happy I'll
do so."

qualify as a mandatory diagnostic for a case for which the ISO C
standard mandates one?


Wouldn't that depend on whether it's documented by the compiler as
a diagnostic?

Perhaps a better wording would be "...So to keep them happy I'm doing
so.". That way it's clear from the message that it is in fact the
required diagnostic.
dave
(In a pedantic mood today, it seems. Not that that's a Bad Thing.)

--
Dave Vandervies dj******@csclub.uwaterloo.ca
[W]hen I am among non-physician Ph.D.s who go by "Doctor" then I like
to be called "Bachelor Petrofsky" in honor of my B.S..
--Al Petrofsky in comp.lang.scheme
Nov 14 '05 #36

P: n/a
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:
Alex <al*******@hotmail.com> scribbled the following:
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
In article <pa****************************@lightspeed.bc.ca >,
Kelsey Bjarnason <ke*****@lightspeed.bc.ca> wrote:
Having warnings enabled doesn't cripple C; it just lets you know when
you've done something that probably isn't actually C at all. :) If it isn't C at all you would get an error. If you get a warning, it's
most likely perfectly legal C that in some non-obvious way does
something entirely different from what you intended.
AFAIK "diagnostics" need only be output from the compiler,
not specifically as "errors" or "warnings".
So does this: "ISO says I have to issue a diagnostic here. So to keep them happy I'll
do so." qualify as a mandatory diagnostic for a case for which the ISO C
standard mandates one?


Sure. The extent of the diagnostic is not defined. It is a QoI
issue.

Alex
Nov 14 '05 #37

This discussion thread is closed

Replies have been disabled for this discussion.