<< QUOTE
It is NOT a C compiler, because it doesn't conform to any commonly
accepted C specification (K&R, C89, C99). You have no right to call it
a C compiler until you get it to conform
quote >>
lcc-win32 provokes unexpected passions in some people using this
newsgroup. It is a H compiler then (H for heretical, non-orthodox)
<< QUOTE
It's been 12 years since I've used a binary tree the last time. In the
meantime, the most complex data structure I *needed* to use was an array
of structures. And I suspect that many programmers use linked lists
only in their homework assignments.
quote >>
The H compiler is not heretical by chance. I am heretical too. I have
to confess to you now that I do use hash tables, lists, and many other
structures in my day-to-day programming.
Worst, I am convinced that designing clever data structures is the best
of the programming activity.
You can get a copy of the H compiler from: http://www.cs.virginia.edu/~lcc-win32
Nov 14 '05
98 3807
Flash Gordon wrote: On Mon, 11 Oct 2004 17:59:14 +0200 jacob navia <ja***@jacob.remcomp.fr> wrote:
Thanks for your remark.
Aside from polemic, the objective in this discussion is to determine if C allows the programmer the use of simple data structures like lists, hash tables, etc.
So why did you start talking about operator overloading?
Operator overloading is just syntatic sugar.
For hash tables, for instance, or for lists, the normal call
syntax is perfectly OK.
Syntatic sugar is needed when you want to access data structures
like a length prefixed string using the normal syntax
String a;
....
a[2] = 'b';
instead of
setStringChar(a,2,'b');
what is more cumbersome.
Since the first message in this thread (admitted, polemic)
I wanted to take a critical look at remarks like "I never use any
data structures", and such, implying that C (or programming) can
be done without using containers like hash tables, lists,
queues, etc. I stress the need of a common library, accepted as widely as the string library, that would fill this gap, i.e. making a library where a common interface to hash tables, to lists, to automatically growing tables (vectors), etc is defined in the language.
I admit that this is quite new to C, but I do not see this as a big deal.
As has been stated repeatedly, discussing the implementations of such things in standard C is fine here.
OK. That is what I wanted. I think that the language is making too
difficult to do that. Each time I need a list, I have to rewrite
a new set of:
DATA_LIST *AddToList(DATA *item);
FindInList(DATA_LIST *list,DATA *item);
etc
I have done it countless times, and I think this is one of the
reasons C is perceived as a language unable to program anything serious.
The problem is you telling people to use your extensions to C such as operator overloading or telling people to use your implementation of such things if it is not written in standard C and freely available.
lcc has been always an experimental compiler where people can try
new ideas. The objective of my implementation of operator overloading
and other "extensions" is to *prove* that this can be done in a
simple way in a simple compiler. That was the objective. And I would
like that the community as a whole reflects on the possibility of
incoporating those extensions into the language, making my special
implementation unneeded.
But even without those extensions, a simple standard about lists,
would provide a much needed simplification of programs, increasing
portability and reliability. How many bugged implementations of those
lists primitives are there?
The polemic that I used (and that I regret now) arises from an
incredible feeling of frustration with a community that is slowly
drifting into obsolescence without noticing it.
I mentioned the reaction of the comitee confronted with the buffer
overflow bug written in the asctime() function in the standard.
I cited the answer to the first bug-correction proposal of Mr Cleaver
(memory overwrites are allowed) but nobody seemed to notice.
If you want to discus extending the C language or the standard C library then that belongs in another group. Others have stated the name of the group but I can't be bothered to look it up.
Maybe, but in comp.std.c there are more or less the same people.
I doubt it that the reaction would be different. I mentioned
(in a long thread) the fact that asctime() had a bug, but the
reaction was the same:
Nobody cares.
I have been told in this group that C++ was designed to do this
kind of stuff. This implies that C should stay in the same level
as 1989 forever, what fits nicely for people that think that only
C++ has any future.
I think that the agnostic nature of C gives the programmer a lot of
creative freedom, freedom of expression. There isn't a single,
language preferred way of doing things (OO programming) but you
can use any paradigm that fits the application best.
The complexity of C++ is so staggering, that most people, even
experts, do not understand the language in all the facets it
has. C++ has gone the "let's complxify things" until ridiculous
heights.
Confronted with that, I think that is normal that people react strongly
when presented with something that seems to go in the same
direction.
But this is not the case here.
jacob navia <ja***@jacob.remcomp.fr> writes: Aside from polemic, the objective in this discussion is to determine if C allows the programmer the use of simple data structures like lists, hash tables, etc.
If that was all you were asking, we could have saved a lot of time.
Of *course* a programmer can use lists, hash tables, etc. in C.
People do it all the time, when it's appropriate to the problem.
In response to some earlier posts, nobody has suggested that there's
anything wrong with using dynamic data structures when appropriate.
Nor is there anything wrong with *not* using dynamic data structures
when they aren't necessary to the problem being solved.
What you're really looking for, I think, is some kind of standard
container library for C that implements lists, hash tables, etc. Why
doesn't such a thing already exist? Part of the reason, I suspect, is
that the existence of C++ has reduced the pressure to implement such a
thing in C. But whatever the reason, nobody (as far as I know) has
implemented a C container library that has really caught on. If you
want to implement one yourself, or encourage someone else to do so, go
right ahead. But complaining in comp.lang.c about the lack of a
standard C container library is likely to accomplish exactly nothing.
--
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.
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41**********************@news.wanadoo.fr... Thanks for your remark.
Aside from polemic, the objective in this discussion is to determine if C allows the programmer the use of simple data structures like lists, hash tables, etc.
It certainly does and always has. Those types of structures as well as any
others (simple or complex) that one's imagination might conceive.
I stress the need of a common library, accepted as widely as the string library, that would fill this gap,
Many third party libraries are indeed as 'widely accepted'. I suspect
if a quick survey were taken here, we'd find many of us use some or many of
the same libraries for the same or similar tasks. Among developer teams, as
well as inter-company collaborations, many of these libraries are
'de-facto' standards for those parties. But there's no rational reason
to push these libraries down the throats of those who never need them
(i.e. all C users).
i.e. making a library where a common interface to hash tables, to lists, to automatically growing tables (vectors), etc is defined in the language.
I admit that this is quite new to C, but I do not see this as a big deal.
You seem to want to force everyone to eat the same amount of the
same thing, when the reality is that appetites (i.e. tool requirements)
vary extremely widely among developers. C is a 'lean' language by
design, intentionally.
This seems to offend you. Whatever.
-Mike
Mike Wahler wrote: You seem to want to force everyone to eat the same amount of the same thing, when the reality is that appetites (i.e. tool requirements) vary extremely widely among developers. C is a 'lean' language by design, intentionally.
A library standard doesn't have any impact in the language.
I mean, if I call
MyOwnAddTolist(DATALIST *list,DATA *item);
or if I write
StdlibcAddToList(... whatever)
the language is unchanged, but I do not have to code
a list handling code for 1000th time to cater a new
list.
And if the library function doesn't look good to me I can always
roll my own!
Library functions do not have any language impact. A standard
library makes the language just *easier to use*, that's all.
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41***********************@news.wanadoo.fr... Mike Wahler wrote: You seem to want to force everyone to eat the same amount of the same thing, when the reality is that appetites (i.e. tool requirements) vary extremely widely among developers. C is a 'lean' language by design, intentionally. A library standard doesn't have any impact in the language.
But it does impact an implementation, which does have
a practical impact: E.g. storage space required, gobbling
up more names, etc.
I mean, if I call MyOwnAddTolist(DATALIST *list,DATA *item);
or if I write
StdlibcAddToList(... whatever)
the language is unchanged, but I do not have to code a list handling code for 1000th time to cater a new list.
Use an existing library. Virtually everyone else does, rather
than re-re-re-inventing wheels. And if the library function doesn't look good to me I can always roll my own!
Library functions do not have any language impact. A standard library makes the language just *easier to use*, that's all.
Yes it does, as do third party libraries.
-Mike
Mike Wahler wrote: "jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:41***********************@news.wanadoo.fr...
Mike Wahler wrote: A library standard doesn't have any impact in the language.
But it does impact an implementation, which does have a practical impact: E.g. storage space required, gobbling up more names, etc.
No. You do not want it?
Do not include
#include <stdlist.h>
The language is written according to that principle.
I can write in C:
#include <mystdio.h>
and the whole input/output of my program can be completely different
IN C. The whole library is optional. If you do not use the floating
point library (math.h) you just do not write:
#include <math.h>
and all names are still available to you and it is a legal
program.
You can then write:
myfloat mysin(myfloat arg);
and you can code the sinus function using only integer operations
and table lookups. Library functions do not have any language impact. A standard library makes the language just *easier to use*, that's all.
Yes it does, as do third party libraries.
But what... You do not use third party libs?
I would like just a standard lib, i.e. that has the same
interface in all implementations. A first step would be to
review those libs and put the best in the FAQ.
The FAQ could be used as a repository of programs that give
a common interface, is well tested and proposed as a standard lib.
Programs could be more portable if we extend standard C.
Standards enhance the software by increasing portability.
On Mon, 11 Oct 2004 19:36:13 +0200
jacob navia <ja***@jacob.remcomp.fr> wrote: Flash Gordon wrote: On Mon, 11 Oct 2004 17:59:14 +0200 jacob navia <ja***@jacob.remcomp.fr> wrote:
Thanks for your remark.
Aside from polemic, the objective in this discussion is to determine if C allows the programmer the use of simple data structures like lists, hash tables, etc. So why did you start talking about operator overloading?
Operator overloading is just syntatic sugar. For hash tables, for instance, or for lists, the normal call syntax is perfectly OK.
Syntatic sugar is needed when you want to access data structures like a length prefixed string using the normal syntax String a; ... a[2] = 'b'; instead of setStringChar(a,2,'b'); what is more cumbersome.
Well, for that you know you need another language.
Since the first message in this thread (admitted, polemic) I wanted to take a critical look at remarks like "I never use any data structures", and such, implying that C (or programming) can be done without using containers like hash tables, lists, queues, etc.
Not only can a lot of programing be done without using hash tables,
list, queues etc, but as I said a lot of programming *is* done without
using such things. Also the natural solution for a lot of problems does
not use such things. I stress the need of a common library, accepted as widely as the string library, that would fill this gap, i.e. making a library where>a common interface to hash tables, to lists, to automatically growing>tables (vectors), etc is defined in the language. I admit that this is quite new to C, but I do not see this as a big deal.
As has been stated repeatedly, discussing the implementations of such things in standard C is fine here.
OK. That is what I wanted. I think that the language is making too difficult to do that. Each time I need a list, I have to rewrite a new set of: DATA_LIST *AddToList(DATA *item); FindInList(DATA_LIST *list,DATA *item); etc
I have done it countless times, and I think this is one of the reasons C is perceived as a language unable to program anything serious.
A colleague where I now work wrote a list library many years ago which
he has continued to use. I don't have it, but one possible interface
would include
data_list *AddToList(void *data, size_t len);
data_list *FindInList(data_list *list,void *item, comp_function_t
comp_function); > The problem is you telling people to use your extensions to C such as operator overloading or telling people to use your implementation of such things if it is not written in standard C and freely available.
lcc has been always an experimental compiler where people can try new ideas. The objective of my implementation of operator overloading and other "extensions" is to *prove* that this can be done in a simple way in a simple compiler. That was the objective. And I would like that the community as a whole reflects on the possibility of incoporating those extensions into the language, making my special implementation unneeded.
Well, discus that in appropriate groups.
But even without those extensions, a simple standard about lists, would provide a much needed simplification of programs, increasing portability and reliability. How many bugged implementations of those lists primitives are there?
Probably as many as there are buggy implementations of the standard C
library.
The polemic that I used (and that I regret now) arises from an incredible feeling of frustration with a community that is slowly drifting into obsolescence without noticing it.
Languages stop being used for some problem domains as other languages
better designed for those domains come along. That is the way of life in
computing and has been since the first assembler was written so that
people did not have to code directly in machine code (I have had to read
and enter machine code within the last 15 years). OO languages are
better for developing GUIs so C is used less for that now, but C is
better for other tasks.
I mentioned the reaction of the comitee confronted with the buffer overflow bug written in the asctime() function in the standard. I cited the answer to the first bug-correction proposal of Mr Cleaver (memory overwrites are allowed) but nobody seemed to notice.
I read that section of the standard as specifying the algorithm to be
implemented, not the buffer size. There is nothing in the standard that
says an implementation cannot use a buffer that is large enough or
validate the inputs. If you want to discus extending the C language or the standard C library then that belongs in another group. Others have stated the name of the group but I can't be bothered to look it up.
Maybe, but in comp.std.c there are more or less the same people.
I'm not there, so the population is not the same.
I doubt it that the reaction would be different.
Well, I doubt they would tell you that proposing changes to the standard
was OT especially if they have just told you in this group that it is
over their that you should discus them.
I mentioned (in a long thread) the fact that asctime() had a bug, but the reaction was the same:
Nobody cares.
I have been told in this group that C++ was designed to do this kind of stuff. This implies that C should stay in the same level as 1989 forever, what fits nicely for people that think that only C++ has any future.
Or people who think that C has it's niche and other languages are better
for other things.
I think that the agnostic nature of C gives the programmer a lot of creative freedom, freedom of expression. There isn't a single, language preferred way of doing things (OO programming) but you can use any paradigm that fits the application best.
C is not suitable for all paradigms of programming. OO programming
(and developing for GUIs) is easier in a language designed for it, list
processing is easier in a language designed for list processing (I've
played with Lisp) etc. C is just a straight forward simple procedural
language that can be used for any task that can easily be reduced to a
procedural task, and that includes most (but not all) of what I have
done in the last 19 years of programming.
The complexity of C++ is so staggering, that most people, even experts, do not understand the language in all the facets it has. C++ has gone the "let's complxify things" until ridiculous heights.
Confronted with that, I think that is normal that people react strongly when presented with something that seems to go in the same direction.
But this is not the case here.
My reaction about your extensions is that this is the wrong place to
discus them, not that they are wrong. I just have too many other things
to think about to worry about where the C language is going. However I
do think that if you want the language to be extended the first thing to
do is get C99 implemented widely, so IMHO you efforts would be better
spent getting your implementation fully C99 compliant and making it good
enough that it persuades others to follow suit.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
On Mon, 11 Oct 2004 17:59:14 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Thanks for your remark.
Aside from polemic, the objective in this discussion is to determine if C allows the programmer the use of simple data structures like lists, hash tables, etc.
It does. Trivially.
I stress the need of a common library, accepted as widely as the string library, that would fill this gap, i.e. making a library where a common interface to hash tables, to lists, to automatically growing tables (vectors), etc is defined in the language.
Fine, then go ask in comp.std.c
I admit that this is quite new to C, but I do not see this as a big deal.
Splendid. Bye then.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
On Mon, 11 Oct 2004 19:36:13 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Maybe, but in comp.std.c there are more or less the same people. I doubt it that the reaction would be different.
Then you're an idiot or being disingenuous. Many of the same people
doubtless post in rec.autos as post here, or sci.math. How they react to
offtopic mumblings in one group has no bearing on how they'll react to
ontopic posts in another.
I mentioned (in a long thread) the fact that asctime() had a bug, but the reaction was the same:
No, you mentioned the fact that an example implementation in the standard
has a bug under highly unusual circumstsances, and the Standards committee
took a reasonable view that reprinting the standard to correct trivia was
not worthwhile.
Nobody cares.
Not any more. You've seen to that.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
jacob navia wrote: Aside from polemic, the objective in this discussion is to determine if C allows the programmer the use of simple data structures like lists, hash tables, etc.
I stress the need of a common library, accepted as widely as the string library, that would fill this gap, i.e. making a library where a common interface to hash tables, to lists, to automatically growing tables (vectors), etc is defined in the language.
I admit that this is quite new to C, but I do not see this as a big deal.
All those things are _already_ available to C programmers, except
not as a standard. All those things can be built out of C code
which meets the standard, and thus is portable. Thus the only
purpose of making such animals standard would be to hamper future
creativity. If you want to talk about the _standard_ C code to
implement such things, go ahead here. If you want to talk about
putting such things in the standard (bad idea, IMO) go to
comp.std.c. In either case, talking about them here is trolling.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:41***********************@news.wanadoo.fr... Mike Wahler wrote:
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:41***********************@news.wanadoo.fr...
Mike Wahler wrote: A library standard doesn't have any impact in the language.
But it does impact an implementation, which does have a practical impact: E.g. storage space required, gobbling up more names, etc. No. You do not want it? Do not include #include <stdlist.h>
And that will magically delete the object code for
the list, huh? The language is written according to that principle. I can write in C: #include <mystdio.h>
and the whole input/output of my program can be completely different IN C.
Yup.
The whole library is optional. If you do not use the floating point library (math.h) you just do not write: #include <math.h>
And the actual code for those functions still resides on my
disk. and all names are still available to you
And if I *do* need the stuff declared by <math.h>?
and it is a legal program. You can then write: myfloat mysin(myfloat arg); and you can code the sinus function
'Scuse me while I blow my nose. :-)
using only integer operations and table lookups.
Library functions do not have any language impact. A standard library makes the language just *easier to use*, that's all.
Yes it does, as do third party libraries.
But what... You do not use third party libs?
I use them extensively, in virtually every nontrivial program.
These libraries are not standard. This bothers me not at all. I would like just a standard lib, i.e. that has the same interface in all implementations.
Then create one. If you want standardization, approach standards
bodies. This newsgroup is not such a body.
A first step would be to review those libs and put the best in the FAQ.
Doesn't the FAQ already have links to various tools and resources
such as libraries? The FAQ could be used as a repository of programs
Then it would cease to be a FAQ, it would be something else.
that give a common interface, is well tested and proposed as a standard lib.
Make all the proposals you like. But wouldn't it be more productive
to posit your ideas to those who write standards, instead of the
population of comp.lang.c, who are here to discuss the existing
C language? Programs could be more portable if we extend standard C.
Perhaps. Go to comp.std.c and make your proposals. At least
there, they'd be topical. Standards enhance the software by increasing portability.
That is one of many benefits of standardization.
-Mike
Flash Gordon <sp**@flash-gordon.me.uk> writes: On Mon, 11 Oct 2004 19:36:13 +0200 jacob navia <ja***@jacob.remcomp.fr> wrote:
[...] I mentioned the reaction of the comitee confronted with the buffer overflow bug written in the asctime() function in the standard. I cited the answer to the first bug-correction proposal of Mr Cleaver (memory overwrites are allowed) but nobody seemed to notice.
I read that section of the standard as specifying the algorithm to be implemented, not the buffer size. There is nothing in the standard that says an implementation cannot use a buffer that is large enough or validate the inputs.
Agreed, but an implementation is allowed to use the exact C code
presented in the standard to implement the asctime() function, which
means that a call to asctime() representing a year outside the range
-999 .. 9999 invokes undefined behavior. An implementation is
allowed, but not required, to use a larger buffer, causing the effect
of the undefined behavior to be friendlier.
As a programmer, it doesn't help me to know that an implementation
*may* implement asctime() so it doesn't blow up given an out-of-range
argument. I still need to avoid calling asctime() with values outside
the supported range. This is a burden, but a trivial one.
--
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.
jacob navia wrote: Mike Wahler wrote:
You seem to want to force everyone to eat the same amount of the same thing, when the reality is that appetites (i.e. tool requirements) vary extremely widely among developers. C is a 'lean' language by design, intentionally.
A library standard doesn't have any impact in the language. I mean, if I call MyOwnAddTolist(DATALIST *list,DATA *item);
or if I write
StdlibcAddToList(... whatever)
the language is unchanged, but I do not have to code a list handling code for 1000th time to cater a new list.
You seem to be implying the impossibility of creating a library
with your system, together with the impossibility of retaining
source code files. Maybe an examination of snippets.com (or is it
..org??) would help.
Maybe you should create singly linked lists around the definition:
typedef struct sllist {
struct sllist *next;
void *data;
} sllist, *sllistp;
Which will allow you to separate list handling from list use.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
On Tue, 12 Oct 2004 00:12:04 GMT
Keith Thompson <ks***@mib.org> wrote: Flash Gordon <sp**@flash-gordon.me.uk> writes: On Mon, 11 Oct 2004 19:36:13 +0200 jacob navia <ja***@jacob.remcomp.fr> wrote: [...] I mentioned the reaction of the comitee confronted with the buffer overflow bug written in the asctime() function in the standard. I cited the answer to the first bug-correction proposal of Mr Cleaver> (memory overwrites are allowed) but nobody seemed to notice.
I read that section of the standard as specifying the algorithm to be implemented, not the buffer size. There is nothing in the standard that says an implementation cannot use a buffer that is large enough or validate the inputs.
Agreed, but an implementation is allowed to use the exact C code presented in the standard to implement the asctime() function, which means that a call to asctime() representing a year outside the range -999 .. 9999 invokes undefined behavior. An implementation is allowed, but not required, to use a larger buffer, causing the effect of the undefined behavior to be friendlier.
As a programmer, it doesn't help me to know that an implementation *may* implement asctime() so it doesn't blow up given an out-of-range argument. I still need to avoid calling asctime() with values outside the supported range. This is a burden, but a trivial one.
Agreed. I was just pointing out that the standard does not impose a
buffer overrun vulnerability, it merely allows an implementation to have
one.
Personally I would use strftime (as someone else mentioned) and ignore
asctime, it's a much friendlier function. I would also ignore ctime.
strftime also has the advantage that (quoting from 7.23.3.5 in N869) "If
any of the specified values is outside the normal range, the characters
stored are unspecified." so even with invalid data you don't get
undefined behaviour. However, if there is any possibility of out of
range data my opinion is that this still needs to be handled by the
programmer, since the unspecified characters written may not be the ones
you want.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.
CBFalconer <cb********@yahoo.com> wrote: All those things are _already_ available to C programmers, except not as a standard. All those things can be built out of C code which meets the standard, and thus is portable. Thus the only purpose of making such animals standard would be to hamper future creativity. If you want to talk about the _standard_ C code to implement such things, go ahead here. If you want to talk about putting such things in the standard (bad idea, IMO) go to comp.std.c. In either case, talking about them here is trolling.
No, it ain't. It would be trolling if it were done to provoke us, but I
don't believe this is the case. It appears that Jacob really _does_
think that adding dead weight makes his implementation better than its
ancestor. It also appears that Jacob really does think that it's quite
alright to talk about his grab-box any place where it's even vaguely
related to the topic. This does make him a bit of a kook, and somewhat
sad, really, but a troll is a different kind of creature.
Richard
Mark McIntyre <ma**********@spamcop.net> spoke thus: much existing code becomes broken then compiler writers won't implement the new features, because their customers don't want to spend money rewriting everything. The new Standard is unimplemented, the language stagnates. And all because someone overzealously tried to update it too much.
I may be venturing into comp.std.c territory here, but I'd be
interested in seeing something like the HTML standards implemented -
user agents change gradually to match the W3C specifications, so the
language evolves while allowing old markup to be used for a long time.
It's just an idle (and probably unoriginal) thought...
--
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.
In <ck**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.org> writes: Mark McIntyre <ma**********@spamcop.net> spoke thus:
much existing code becomes broken then compiler writers won't implement the new features, because their customers don't want to spend money rewriting everything. The new Standard is unimplemented, the language stagnates. And all because someone overzealously tried to update it too much.
I may be venturing into comp.std.c territory here, but I'd be interested in seeing something like the HTML standards implemented - user agents change gradually to match the W3C specifications, so the language evolves while allowing old markup to be used for a long time. It's just an idle (and probably unoriginal) thought...
It is not realistically feasible to put everything useful in *one*
standard. The C standard should provide an infrastructure upon which
other standards could build on. One should complain (and actually do
something more constructive than that) about the lack of such standards
and not about the kitchen sink missing from the C standard.
Furthermore, such standards should provide multiple language interfaces
to the respective libraries, whenever possible.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
On Mon, 11 Oct 2004 21:56:37 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Mike Wahler wrote:
But it does impact an implementation, which does have a practical impact: E.g. storage space required, gobbling up more names, etc. No. You do not want it? Do not include #include <stdlist.h>
Sure, that'll remove the names, and with a badly optimised compiler it'll
reduce the link size. But the size of the implementation on disk isn't
affected. Yes it does, as do third party libraries.
But what... You do not use third party libs?
I would like just a standard lib, i.e. that has the same interface in all implementations.
Then propose one to comp.std.c, and see how you get on
A first step would be to review those libs and put the best in the FAQ.
This thread aside, this is not an FAQ so it has little or no place in the
FAQ.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote: On Sat, 09 Oct 2004 01:35:49 +0200, in comp.lang.c, jacob navia wrote: This, is reflected in the standards comitee too: I discovered a buffer overflow in the code of the asctime function, printed in the standard. Where's the error? I checked N869, and it looks fine to me; it supplies a buffer 'char result[26]' for holding a 25-character string plus null terminator. Unless Jacob is thinking that it'll stop working correctly in the year 10000; but that's not a reasonable complaint in my book. So, what's the deal here?
A local attacker could set the clock to the year 10000,
causing undefined behaviour (which could be a root exploit).
So there is a small amount of seriousness.
In <84*************************@posting.google.com> ol*****@inspire.net.nz (Old Wolf) writes: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote: > On Sat, 09 Oct 2004 01:35:49 +0200, in comp.lang.c, jacob navia wrote: >> This, is reflected in the standards comitee too: I discovered a buffer >> overflow in the code of the asctime function, printed in the standard. > Where's the error? I checked N869, and it looks fine to me; it supplies a buffer 'char result[26]' for holding a 25-character string plus null terminator. Unless Jacob is thinking that it'll stop working correctly in the year 10000; but that's not a reasonable complaint in my book. So, what's the deal here?
A local attacker could set the clock to the year 10000, causing undefined behaviour (which could be a root exploit).
You need to get root access in order to be able to set the clock to the
year 10000 (assuming that the system supports such dates in the first
place).
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Old Wolf wrote: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:
On Sat, 09 Oct 2004 01:35:49 +0200, in comp.lang.c, jacob navia wrote:
This, is reflected in the standards comitee too: I discovered a buffer overflow in the code of the asctime function, printed in the standard. Where's the error? I checked N869, and it looks fine to me; it supplies a buffer 'char result[26]' for holding a 25-character string plus null terminator. Unless Jacob is thinking that it'll stop working correctly in the year 10000; but that's not a reasonable complaint in my book. So, what's the deal here?
A local attacker could set the clock to the year 10000, causing undefined behaviour (which could be a root exploit). So there is a small amount of seriousness.
There is no need to set the clock.
Just call asctime with a year of 10000
You fill a structure tm, with say year 10000, month 665, etc, and call
asctime.
No need to set the clock.
In <41**********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes: Old Wolf wrote: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:
On Sat, 09 Oct 2004 01:35:49 +0200, in comp.lang.c, jacob navia wrote:
>This, is reflected in the standards comitee too: I discovered a buffer >overflow in the code of the asctime function, printed in the standard.
Where's the error? I checked N869, and it looks fine to me; it supplies a buffer 'char result[26]' for holding a 25-character string plus null terminator. Unless Jacob is thinking that it'll stop working correctly in the year 10000; but that's not a reasonable complaint in my book. So, what's the deal here?
A local attacker could set the clock to the year 10000, causing undefined behaviour (which could be a root exploit). So there is a small amount of seriousness.
There is no need to set the clock. Just call asctime with a year of 10000 You fill a structure tm, with say year 10000, month 665, etc, and call asctime.
No need to set the clock.
You missed the point. The idea is not to compromise *your* program, but
another program, running with root privileges, whose code you cannot
control. If that program uses the asctime function with the current date
as an argument, you can compromise it by setting the system date to
year 10k. If you have enough information about a lot of things,
you may be able to control the actual behaviour of the program to
your advantage. In theory, at least.
I have pointed out elsethread the flaw in the reasoning.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Dan Pop wrote: ol*****@inspire.net.nz (Old Wolf) writes: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote: jacob navia wrote: This, is reflected in the standards comitee too: I discovered > a buffer overflow in the code of the asctime function, printed > in the standard.
Where's the error? I checked N869, and it looks fine to me; it supplies a buffer 'char result[26]' for holding a 25-character string plus null terminator. Unless Jacob is thinking that it'll stop working correctly in the year 10000; but that's not a reasonable complaint in my book. So, what's the deal here?
A local attacker could set the clock to the year 10000, causing undefined behaviour (which could be a root exploit).
You need to get root access in order to be able to set the clock to the year 10000 (assuming that the system supports such dates in the first place).
Where is "root access" specified in any C standard?
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
On Wed, 13 Oct 2004 18:23:43 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Just call asctime with a year of 10000 You fill a structure tm, with say year 10000, month 665, etc, and call asctime.
But as you already know, this can be trivially defended against by the same
kind of technique that any competent programmer should be well versed in
with a host of other functions which you seem not to find offensive.
As far as I'm concerned, all you're showing is that you're obsessing about
a trivium because you think it makes you look 'clever' . Bzzzt. Wrong.
Next.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Cheerio,
CBFalconer wrote: Dan Pop wrote:
ol*****@inspire.net.nz (Old Wolf) writes:
"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote:
>jacob navia wrote:
>>This, is reflected in the standards comitee too: I discovered >>a buffer overflow in the code of the asctime function, printed >>in the standard. > Where's the error? I checked N869, and it looks fine to me; it supplies a buffer 'char result[26]' for holding a 25-character string plus null terminator. Unless Jacob is thinking that it'll stop working correctly in the year 10000; but that's not a reasonable complaint in my book. So, what's the deal here?
A local attacker could set the clock to the year 10000, causing undefined behaviour (which could be a root exploit).
You need to get root access in order to be able to set the clock to the year 10000 (assuming that the system supports such dates in the first place).
Where is "root access" specified in any C standard?
Ah, come on. You won't find the word "leak" in the standard
but we are often talking about memory leaks and you won't find
"overflow" but in the integer and floating point arithmetic
context and still we are talking about buffer overflows.
Of course an exploit is a system and implementation dependent
thing. Otherwise, certain M$ products should not have problems
with buffer overflows as they are not defined by the C standard.
And as root access is not defined, we all live in pink clouds
and are happy... ;-)
--Michael
Besides the security considerations, there is the
principle of library functions returning known values for
all possible inputs.
asctime should be correctly specified, setting ERANGE when
one of its inputs is out of range, that's all.
Recognizing this is beyond some people here, that
like polemic but not any discussion about the issues at hand.
jacob
jacob navia <ja***@jacob.remcomp.fr> writes: Besides the security considerations, there is the principle of library functions returning known values for all possible inputs.
The C standard library does not follow this principle. Making it do
so would require a major redesign, and would break existing code;
that's just not going to happen. A more robust replacement for the C
standard library might be an interesting idea; by all means, feel free
to implement it.
I've asked you before what you think strlen(NULL) should do; you never
answered.
asctime should be correctly specified, setting ERANGE when one of its inputs is out of range, that's all.
In a previous article, I listed a number of circumstances in which the
sample implementation of asctime() can invoke undefined behavior.
Should it detect all of them? What about asctime(NULL)? What about
asctime(random_pointer_value)?
The behavior of asctime with an argument denoting a value after the
year 9999 is merely one of many instances of undefined behavior in the
standard library. I actually agree that it should be fixed, but it's
not that big a deal. Programmers just need to be careful.
If you want a bulletproof language that cleanly handles all possible
errors, I submit that C is not the language for you.
Recognizing this is beyond some people here, that like polemic but not any discussion about the issues at hand.
None of this is "beyond" us. We understand what you're saying; we
just don't necessarily agree, and we wish you'd discuss it where it's
actually topical.
--
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.
Keith Thompson wrote: I've asked you before what you think strlen(NULL) should do; you never answered.
Should return zero and set errno to EDOM. Zero would make NULL
identical to the empty string, what is consistent with the
usage many applications make of NULL.
The domain of strlen is the set of non-empty strings. Hence, EDOM
is a correct indicator.
The behavior now (just undefined) allows for the above implementation,
Specifying this would make the library more consistent.
The same could be done for many other functions that do not expect
NULL:
fopen(NULL,NULL) --> NULL errno = EDOM
fopen(NULL,"wb") --> NULL errno = EDOM
etc. asctime should be correctly specified, setting ERANGE when one of its inputs is out of range, that's all.
In a previous article, I listed a number of circumstances in which the sample implementation of asctime() can invoke undefined behavior. Should it detect all of them? What about asctime(NULL)? What about asctime(random_pointer_value)?
The behavior of asctime with an argument denoting a value after the year 9999 is merely one of many instances of undefined behavior in the standard library. I actually agree that it should be fixed, but it's not that big a deal. Programmers just need to be careful.
The problem is made worst when the standard publishes code
like
char buffer[26];
Why did they specify asctime with all this detail?
There are many other functions where code would have been useful.
No, they had to publish code that overflows and crashes at
the slightest error.
If you want a bulletproof language that cleanly handles all possible errors, I submit that C is not the language for you.
I strive in my programs to write code as bulletproof as possible.
This can be done in C.
If C is to be understood as a language where "anything goes", we
have to reach the conclusion that C is to be avoided at all
costs in any serious application.
Defensive programming and error analysis are part of a system
design, and it has to be done. C is no exception: programs
should be robust and handle gracefully incorrect inputs
without blowing up. Recognizing this is beyond some people here, that like polemic but not any discussion about the issues at hand.
None of this is "beyond" us. We understand what you're saying; we just don't necessarily agree, and we wish you'd discuss it where it's actually topical.
The discussion in comp.std.c didn't lead to anything.
The gets function is still there, trigraphs are still there,
the general attitude is that C should avoid any change
and go into obsolescence.
Most of the people in comp.std.c and here think that
C++ is the way to go, hence, C should stay where it is
and disappear.
In <41***************@yahoo.com> CBFalconer <cb********@yahoo.com> writes: Dan Pop wrote: ol*****@inspire.net.nz (Old Wolf) writes: "Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote: > jacob navia wrote:
>> This, is reflected in the standards comitee too: I discovered >> a buffer overflow in the code of the asctime function, printed >> in the standard. > Where's the error? I checked N869, and it looks fine to me; it supplies a buffer 'char result[26]' for holding a 25-character string plus null terminator. Unless Jacob is thinking that it'll stop working correctly in the year 10000; but that's not a reasonable complaint in my book. So, what's the deal here?
A local attacker could set the clock to the year 10000, causing undefined behaviour (which could be a root exploit).
You need to get root access in order to be able to set the clock to the year 10000 (assuming that the system supports such dates in the first place).
Where is "root access" specified in any C standard?
Where is the setting the clock procedure described in the C standard?
Engage your brain, next time!
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In <41***********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes: Besides the security considerations, there is the principle of library functions returning known values for all possible inputs.
There is no such principle for the C standard library. strlen(NULL)
invokes undefined behaviour. Ditto for strlen((char *)123).
Calling a <time.h> function with a date that cannot be represented by
time_t invokes undefined behaviour.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
In <41***********************@news.wanadoo.fr> jacob navia <ja***@jacob.remcomp.fr> writes: The domain of strlen is the set of non-empty strings. Hence, EDOM is a correct indicator.
Since when is "" outside the domain of strlen?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
jacob navia <ja***@jacob.remcomp.fr> writes: Keith Thompson wrote: I've asked you before what you think strlen(NULL) should do; you never answered. Should return zero and set errno to EDOM. Zero would make NULL identical to the empty string, what is consistent with the usage many applications make of NULL.
Do you think that the standard should be changed to require
strlen(NULL) to return zero for all implementations?
A null pointer and a pointer to an empty string are two entirely
different things. You propose muddying the distinction. Given the
following:
char *x = "";
char *y = NULL;
x points to a string, and y does not. The fact that strlen(NULL)
invokes undefined behavior is entirely deliberate; the solution, for
any programmer, is Don't Do That.
The domain of strlen is the set of non-empty strings. Hence, EDOM is a correct indicator.
Does "non-empty strings" exclude ""? Do you want strlen("") to set
errno to EDOM? I doubt that you intended that, but it is implied by
what you wrote.
The behavior now (just undefined) allows for the above implementation, Specifying this would make the library more consistent.
No, it wouldn't. It would make its behavior more well-defined in some
cases, but it would make it less consistent, in my opinion.
And the problem of undefined behavior for some calls to library
functions is not solvable without a major redesign. You want
strlen(NULL) to be well-behaved. What about strlen((char*)0xdeadbeef)?
What about strlen(buf), given either
char buf[5] = "hello"; /* no '\0' character */
or
char buf[5]; /* uninitialized */
? And if you're going to require consistent behavior for these cases,
how do you expect it to be implemented? Keep in mind that it would
have to be implemented on *all* systems that support C.
Defining the behavior of strlen(NULL) plugs one minor hole in an
edifice composed of thinly sliced Swiss cheese.
[...] In a previous article, I listed a number of circumstances in which the sample implementation of asctime() can invoke undefined behavior. Should it detect all of them? What about asctime(NULL)? What about asctime(random_pointer_value)? The behavior of asctime with an argument denoting a value after the year 9999 is merely one of many instances of undefined behavior in the standard library. I actually agree that it should be fixed, but it's not that big a deal. Programmers just need to be careful.
Why do you quote my questions when you don't intend to answer them?
The problem is made worst when the standard publishes code like char buffer[26];
Why did they specify asctime with all this detail?
Probably because a C implementation is the easiest way to specify the
algorithm for asctime(). Its behavior is specified in 19 lines of C
code (including the empty line after the declaration of "result").
Try specifying the same algorithm in English. I suspect the resulting
description would be much longer and more ambiguous, and we'd now be
arguing about whether certain calls invoke undefined behavior or not
rather than about the fact that certain calls unambiguously do invoke
indefined behavior.
There are many other functions where code would have been useful.
Not really. Most other functions in the standard library either have
simple enough semantics that they can be described unambiguously in
English (like strlen()), or cannot be portable implemented in standard
C (like fopen()). (The standard provides sample implementations of
srand() and rand(); unfortunately, they're not very good, and too many
implementers have just copied them. The result is that you need to
use non-standard functions if you want decent random numbers.)
No, they had to publish code that overflows and crashes at the slightest error.
I don't consider calling asctime() (which I consider to be a legacy
function) an argument representing a year after 9999 to be "the
slightest error". Don't do that.
If you want a bulletproof language that cleanly handles all possible errors, I submit that C is not the language for you.
I strive in my programs to write code as bulletproof as possible. This can be done in C.
If C is to be understood as a language where "anything goes", we have to reach the conclusion that C is to be avoided at all costs in any serious application.
Defensive programming and error analysis are part of a system design, and it has to be done. C is no exception: programs should be robust and handle gracefully incorrect inputs without blowing up.
Sure, which means that it's each programmer's responsibility to avoid
calling library functions with invalid arguments. We all know that C
gives you enough rope to shoot yourself in the foot. It's a highly
successful language in spite of that.
[...] The discussion in comp.std.c didn't lead to anything.
We told you that comp.std.c, not comp.lang.c, is the place to discuss
proposed changes to the language, and that's still the case. Nobody
promised you that the folks in comp.std.c would be receptive to your
ideas. The fact that they didn't agree with you does *not* suddenly
make the discussion topical here.
The gets function is still there, trigraphs are still there, the general attitude is that C should avoid any change and go into obsolescence.
Most of the people in comp.std.c and here think that C++ is the way to go, hence, C should stay where it is and disappear.
Nonsense. Nobody here wants C to disappear.
--
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.
Dan Pop wrote: In <ff**************************@posting.google.com > ru**@webmail.co.za (goose) writes:
I (sorta) agree that UB is difficult to live with. Maybe UB should be done away with and replaced with "Will Crash The Program", or even have a global bool UB indicater, like errno, which will get set whenever UB occurs, so we can read it and shut down?
It can't be done. Far too many instances of UB are both harmless and undetectable. Others are too expensive to detect and trying to detect them would slow down correct programs for no redeeming benefits.
Purify provides a good example of the overheads incurred by the attempt to detect as many memory access related instances of UB as possible.
I'm happy enough with the Unix systems that unconditionally crash the program at any attempt of dereferencing a null pointer. And I hate the ones that make null pointers behave like empty strings (page zero mapped in the process address space and filled with zeroes).
Like I said, I'm perfectly happy with learning not to
cause UB. But, to the new C programmer (which I'm seeing
less these days), UB is a hard concept to *get through*
(sorta like explaining Chartered accountants to amoebas:
they're missing links all the way to the top[1]).
goose,
[1]Something Terry Pratchett once said, I think
goose wrote: Like I said, I'm perfectly happy with learning not to cause UB. But, to the new C programmer (which I'm seeing less these days),
Me too. There are less and less new programmers that learn C.
After all the negative publicity done by the C++ people (forget
C, C is primitive, etc) and after the buffer overflows fiascos
many companies and people are just getting away from it.
The atmosphere in this forum, the whole attitude towards data
processing concepts like using higher level data-structures,
etc. All this contributes to make C obsolete slowly but surely.
It will die a natural death when the programmers that now
know it retire.
We *could* fight against this, but I see it as very difficult here.
Concepts such as security, defensive programming, avoiding
buffer overflows, etc, is shunned from the discussion.
And in the standard itself, we have the reference code for
asctime that will crash with very bad consequences at the
slightest malformed input.
UB is a hard concept to *get through*
Yes. And avoiding it always is impossible if the
language doesn't cooperate, if the standards comitee
doesn't cooperate, etc.
The answers I get are significative:
"There is so much UB in the library that is hopeless to even start
trying to fix it"
Great. Let's go on then. Da*****@cern.ch (Dan Pop) writes:
[...] Calling a <time.h> function with a date that cannot be represented by time_t invokes undefined behaviour.
That's not true for asctime(). The algorithm, which is presented in
the standard (and is admittedly flawed) makes no reference to time_t.
On a system where time_t overflows in, say, 2038, actime() must still
work properly for a date in the year 2100. On a system where time_t
can represent years after 9999, asctime still invokes undefined
behavior given an argument representing a time in the year 11000.
There are other examples.
--
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.
Dan Pop wrote: ru**@webmail.co.za (goose) writes:
I (sorta) agree that UB is difficult to live with. Maybe UB should be done away with and replaced with "Will Crash The Program", or even have a global bool UB indicater, like errno, which will get set whenever UB occurs, so we can read it and shut down?
It can't be done. Far too many instances of UB are both harmless and undetectable. Others are too expensive to detect and trying to detect them would slow down correct programs for no redeeming benefits.
In addition, UB in a conforming program can be well defined in a
non-conforming program running in a known environment. Some areas
that almost certainly take advantage of this in your system are the
malloc implementation, any operations on FILEs, signals, longjumps,
and more.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
chris wrote:
.... snip ... While I do think this bug is stupid, I don't think it's that stupid.
Imagine code which accepts input from a user which it will pass to asctime. Now I would expect that I'd have to check for some things myself (like months<12, check the number of days is approriate) else bad things might happen. However I might not expect that I have to also check year<10000 (and there are applications where year>10000 is not entirely stupid).
And any time you increment a signed integer you have to check that
its original value did not exceed 32767 (for complete portability)
or INT_MAX for portability to the destination system. In the same
vein, I can conceive of applications where integers larger than
32767 are not entirely stupid. So we should fix the ++ operator.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
On Thu, 14 Oct 2004 10:45:23 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: Keith Thompson wrote:
None of this is "beyond" us. We understand what you're saying; we just don't necessarily agree, and we wish you'd discuss it where it's actually topical.
The discussion in comp.std.c didn't lead to anything.
I see. So, having failed to convince anyone when discussing it in the right
place (which implies that your argument was weak, or your powers of
persuasion small), you decided to come and annoy us instead?
Sensible.
Most of the people in comp.std.c and here think that C++ is the way to go, hence, C should stay where it is and disappear.
Your attitude seems to be "they didn't agree with me, they must all have an
evil ulterior motive".
Perhaps you need to consider another possible explanation.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
On Thu, 14 Oct 2004 10:45:23 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.fr> wrote: The gets function is still there, trigraphs are still there,
I'm sorry, did I just notice you arguing that trigraphs should be removed
from the standard? You really are strangely obsessive.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
jacob navia <ja***@jacob.remcomp.fr> wrote: The atmosphere in this forum, the whole attitude towards data processing concepts like using higher level data-structures, etc. All this contributes to make C obsolete slowly but surely. It will die a natural death when the programmers that now know it retire.
I think you cannot read. Can you reference one post where
somebody has expressed a negative attitude towards the use
of high-level data structures?
Most of the posts responding to yours have been "Why don't
you discuss this in the appropriate forum?" and you have
shown no sign of heeding that advice.
Concepts such as security, defensive programming, avoiding buffer overflows, etc, is shunned from the discussion.
Rubbish. What's shunned from the discussion is informal
proposals for updates to the C standard, in a forum whose
purpose is to discuss code which conforms to the existing
standards only.
For example, the advice "Don't use gets()" is regularly seen
here, and that is surely a discussion of avoiding buffer overflows.
The answers I get are significative:
"There is so much UB in the library that is hopeless to even start trying to fix it"
Actually the answers are "There is so much UB in the library
so that compilers can generate the most optimal code". For
example I don't go around calling strlen(NULL) so why should
_I_ pay the performance penalty of a library checking for it?
(Answer the question, don't waffle on about covering up
for other programmers' errors).
On Mon, 11 Oct 2004 21:56:37 +0200, jacob navia
<ja***@jacob.remcomp.fr> wrote: Mike Wahler wrote:
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message news:41***********************@news.wanadoo.fr...
Mike Wahler wrote: A library standard doesn't have any impact in the language.
But it does impact an implementation, which does have a practical impact: E.g. storage space required, gobbling up more names, etc. No. You do not want it? Do not include #include <stdlist.h> <snip> If you do not use the floating point library (math.h) you just do not write: #include <math.h> and all names are still available to you and it is a legal program.
Not really. All standard library function names are reserved with
external linkage whether or not you #include their declarations and/or
ever reference them. You can't legally write your own sin() or fopen()
or whatever. (At least on a hosted implementation.) Some (many?)
implementations do allow you to provide your own routines, which are
selected in preference to the standard one(s), as long as you don't
interfere with library internals. As a practical matter most of the
math routines stand pretty much alone, except for setting errno, and
overridng them has a fairly good chance of working but not standard.
You can then write: myfloat mysin(myfloat arg); and you can code the sinus function using only integer operations and table lookups.
That's true, since it uses a different name than the standard one. You
could do that even if you DID #include <math.h>.
- David.Thompson1 at worldnet.att.net
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes: [...] Calling a <time.h> function with a date that cannot be represented by time_t invokes undefined behaviour. That's not true for asctime(). The algorithm, which is presented in the standard (and is admittedly flawed) makes no reference to time_t.
It doesn't have to. If you're passing asctime() a value out of range
for the <time.h> implementation, you're invoking undefined behaviour.
Admittedly, the standard fails to say so, leaving the algorithm to
define when an asctime call invokes undefined behaviour.
The real flaw in the standard is not the algorithm, but specifying
asctime() using an implementation. The right thing would have been to
require asctime to take as input the result of converting a time_t
value or the output of the mktime() function and to describe the format
of its output.
On a system where time_t overflows in, say, 2038, actime() must still work properly for a date in the year 2100.
It is this requirement that I consider the real bug in the standard.
asctime() must be seen as part of a package, rather than as an
independently defined entity.
On a system where time_t can represent years after 9999, asctime still invokes undefined behavior given an argument representing a time in the year 11000.
It's the caller that invokes undefined behaviour, by passing asctime()
a value not allowed by the definition of asctime(). If you have a
voltmeter rated up to 9999V, whose fault is if you connect it to 10000V
and it breaks? Was the voltmeter design flawed?
From a realistic point of view, it makes no sense to fill a tm struct
with values by hand and then pass it to asctime. In real applications,
if asctime() is used at all, its argument is the result of converting
a time_t value or has been properly adjusted by an mktime call.
Note that a year above 9999 is only one way of abusing the algorithm
from the standard. ALL the other fields of a struct tm involved in the
algorithm can be filled with values that would either cause out of
bounds array accesses or the total length of the output exceed the
allocated space.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes: [...] Calling a <time.h> function with a date that cannot be represented by time_t invokes undefined behaviour. That's not true for asctime(). The algorithm, which is presented in the standard (and is admittedly flawed) makes no reference to time_t.
It doesn't have to. If you're passing asctime() a value out of range for the <time.h> implementation, you're invoking undefined behaviour. Admittedly, the standard fails to say so, leaving the algorithm to define when an asctime call invokes undefined behaviour.
So you're arguing that time_t is the fundamental type on which
everything in <time.h> is based, and that a struct tm value that
represents a time outside the range of time_t is invalid. As you
admit, the standard doesn't actually say this, so I don't understand
how you came to this conclusion.
The actual standard defines several types: clock_t, time_t, and
struct tm. There is no indication that any of them is any more
fundamental than the others. There is no indication that manually
constructing a struct tm value is invalid. There's even an example in
7.23.2.3 that does exactly that (to determine the day of the week for
July 4, 2001); that example does depend on time_t, but it's clear that
you *can* construct a valid struct tm value that's not derived from a
time_t value.
[...]
It is this requirement that I consider the real bug in the standard. asctime() must be seen as part of a package, rather than as an independently defined entity.
Why? It's not a "bug", it's just something that you don't like.
[...]
From a realistic point of view, it makes no sense to fill a tm struct with values by hand and then pass it to asctime.
Sure it does. The standard says that this is allowed (unless you can
point to explicit wording that says otherwise).
I agree that making time_t the fundamental time type, and defining
everything else in <time.h> in terms of it, would have made for a
cleaner design. Perhaps whatever interface eventually replaces
<time.h> will do something like that. But that's a topic for
comp.std.c; here in comp.lang.c, we discuss the language as it's
actually defined.
--
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.
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes: [...] Calling a <time.h> function with a date that cannot be represented by time_t invokes undefined behaviour.
That's not true for asctime(). The algorithm, which is presented in the standard (and is admittedly flawed) makes no reference to time_t. It doesn't have to. If you're passing asctime() a value out of range for the <time.h> implementation, you're invoking undefined behaviour. Admittedly, the standard fails to say so, leaving the algorithm to define when an asctime call invokes undefined behaviour.
So you're arguing that time_t is the fundamental type on which everything in <time.h> is based, and that a struct tm value that represents a time outside the range of time_t is invalid. As you admit, the standard doesn't actually say this, so I don't understand how you came to this conclusion.
I have discussed the issue at great length in comp.std.c, several months
ago. I see no point in rehashing it. It is this requirement that I consider the real bug in the standard. asctime() must be seen as part of a package, rather than as an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^ independently defined entity. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Why?
Reading impaired? The answer was just above your question, readily
available for your perusal.
I hope you didn't ask why asctime() must be seen as part of a package,
because the answer should be obvious.
It's not a "bug", it's just something that you don't like.
Reading impaired? I didn't say it's a bug, I said "I consider the real
bug" which strongly implies a personal judgment, i.e. it's just something
that I don't like. [...]
From a realistic point of view, it makes no sense to fill a tm struct with values by hand and then pass it to asctime.
Sure it does. The standard says that this is allowed (unless you can point to explicit wording that says otherwise).
Many things the standard allows make no sense from a realistic point of
view. I have plenty of examples available, if needed.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:Da*****@cern.ch (Dan Pop) writes:
[...] It is this requirement that I consider the real bug in the standard. asctime() must be seen as part of a package, rather than as an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^ independently defined entity. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Why?
Reading impaired? The answer was just above your question, readily available for your perusal.
I see only a blatant assertion which you've chosen not to justify.
I hope you didn't ask why asctime() must be seen as part of a package, because the answer should be obvious.
No, I'm not reading impaired, but thank you for your kind concern.
I'm reading the actual standard. I don't know what you're reading. It's not a "bug", it's just something that you don't like.
Reading impaired? I didn't say it's a bug, I said "I consider the real bug" which strongly implies a personal judgment, i.e. it's just something that I don't like.
Ok, so you don't like what the standard actually says. That's fine;
you might consider discussing it in comp.std.c.
What the standard actually *says* is internally consistent (if a bit
odd), and your interpretation of it is no more than wishful thinking.
Try this, Dan. Pretend that I've asserted that "Calling a <time.h>
function with a date that cannot be represented by time_t invokes
undefined behaviour." I'm sure you wouldn't have any trouble arguing
that I'm wrong.
--
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.
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:Da*****@cern.ch (Dan Pop) writes:[...] It is this requirement that I consider the real bug in the standard. asctime() must be seen as part of a package, rather than as an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^ independently defined entity. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Why?
Reading impaired? The answer was just above your question, readily available for your perusal.
I see only a blatant assertion which you've chosen not to justify.
As I wrote below, I thought that the justification is obvious, even to
you. I hope you didn't ask why asctime() must be seen as part of a package, because the answer should be obvious.
No, I'm not reading impaired, but thank you for your kind concern.
I'm reading the actual standard. I don't know what you're reading.
The same, but with an open mind, rather than anally clutching to the
strict wording which, quite often, fails to reflect the actual intent of
the authors. It's not a "bug", it's just something that you don't like.
Reading impaired? I didn't say it's a bug, I said "I consider the real bug" which strongly implies a personal judgment, i.e. it's just something that I don't like.
Ok, so you don't like what the standard actually says. That's fine; you might consider discussing it in comp.std.c.
Memory impaired? I have already done it, several months ago, as I have
already pointed out in my previous message.
What the standard actually *says* is internally consistent (if a bit odd), and your interpretation of it is no more than wishful thinking.
If expecting <time.h> to provide the specification of a package, rather
than the descriptions of a bunch of *unrelated* functions is wishful
thinking, then you're right, of course.
Try this, Dan. Pretend that I've asserted that "Calling a <time.h> function with a date that cannot be represented by time_t invokes undefined behaviour." I'm sure you wouldn't have any trouble arguing that I'm wrong.
I'd argue both sides and finally agree with you, because I do consider
<time.h> as a package (with the obvious exception of the clock() function
and its associated stuff, which was better placed in <stdlib.h>, the
catch-all for anything that didn't belong elsewhere). It may not be a
perfect package, but it's still a package and the current specification
of asctime() looks like a brain fart of the committee.
The only *sensible* requirement about the size of the asctime output is
that it accomodates the largest year supported by the <time.h>
implementation, usually the largest year representable by time_t.
If int is a 64-bit type, there is no point in making the buffer large
enough to accomodate year LLONG_MAX, an entity devoid of any meaning
for any reasonable C program.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
[...]I'm reading the actual standard. I don't know what you're reading.
The same, but with an open mind, rather than anally clutching to the strict wording which, quite often, fails to reflect the actual intent of the authors.
Perhaps you can provide some evidence that the actual intent of the
authors is consistent with your interpretation. I don't believe it
is.
[...] What the standard actually *says* is internally consistent (if a bit odd), and your interpretation of it is no more than wishful thinking.
If expecting <time.h> to provide the specification of a package, rather than the descriptions of a bunch of *unrelated* functions is wishful thinking, then you're right, of course.
I don't particularly expect <time.h> to provide the specification of a
"package". I don't know why you do. I understand that you wish it
did; so do I (see "wishful thinking", above) (I'm not 100% sure what
you mean by the word "package" anyway.)
Nor do I expect <stdlib.h> to provide the specification of a "package".
[...] The only *sensible* requirement about the size of the asctime output is that it accomodates the largest year supported by the <time.h> implementation, usually the largest year representable by time_t.
What a pity that the standard doesn't actually say that. In fact what
the standard actually *does* say directly contradicts your
interpretation.
And I know this won't do any good, but take your personal abuse
("reading impaired" et al) and shove it.
--
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.
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: Da*****@cern.ch (Dan Pop) writes: In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:[...]I'm reading the actual standard. I don't know what you're reading.
The same, but with an open mind, rather than anally clutching to the strict wording which, quite often, fails to reflect the actual intent of the authors.
Perhaps you can provide some evidence that the actual intent of the authors is consistent with your interpretation. I don't believe it is.
What do you believe the actual intent was? To provide a deliberately
broken specification for asctime()?
IMHO, they were looking for a simple way of specifying the actual format
of asctime's output and they made a less than optimal choice. They
didn't meant asctime to be seen as a standalone member of the package. If expecting <time.h> to provide the specification of a package, rather than the descriptions of a bunch of *unrelated* functions is wishful thinking, then you're right, of course.
I don't particularly expect <time.h> to provide the specification of a "package". I don't know why you do.
Why don't we have a single header covering the whole of the standard C
library, something like <stdc.h> ? Because the standard C library was
logically divided into packages and each package assigned its own header.
All the "orphans" have been gathered together in <stdlib.h>.
I understand that you wish it did; so do I (see "wishful thinking", above)
I would have been perfectly happy with <stdc.h>, no wishful thinking.
I was merely commenting on what the committee actually did. If you
disagree, ask in comp.std.c.
(I'm not 100% sure what you mean by the word "package" anyway.)
Then get yourself an English dictionary and peruse it. If still in doubt,
post the most likely candidate definitions and I'll tell you which it is.
Nor do I expect <stdlib.h> to provide the specification of a "package".
Neither do I, for reasons *already* explained in my previous post.
Reading impaired?
[...] The only *sensible* requirement about the size of the asctime output is that it accomodates the largest year supported by the <time.h> implementation, usually the largest year representable by time_t.
What a pity that the standard doesn't actually say that. In fact what the standard actually *does* say directly contradicts your interpretation.
Indeed, if you anally clutch at the actually wording, without even
trying to see the intent. Anyway, I never filled a struct tm by hand
and then passed it to asctime and I don't plan to do that in the future,
so the actual definition happens to be good enough *for me*, even if it's
broken in the general context of the <time.h>.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Dan, I'm not going to waste any more time on this.
I'm right, you're wrong, and I'm done here.
--
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. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Zeng Dinghao |
last post by:
could anybody explain the term "in memory compilation" to me ?
thanks
|
by: jacob navia |
last post by:
After a user asked for clarification about some warnings issued by
lcc-win, I have updated the compiler to reflect this discussion.
1) The buggy warning about
long l;
printf("%li", l * 10L);...
|
by: jacob navia |
last post by:
The lcc-win compiler has been ported to the Linux OS.
The package is available at:
http://www.q-software-solutions.de/products/lcc-linux32/index.shtml
There are some problems still with this...
|
by: Eddie |
last post by:
Hi
I am using lcc-win on Windows 98. I'm writing a simple c console app, and
I need to set the background color to blue. Here's the code I've got at
the moment:
_asm ( "movb $2, %ah\n"
"movb...
|
by: jacob navia |
last post by:
Preview:
lcc-win 64 bits has had a long development period, and is not
complete yet. But a preview of the software will be available
with the professional version of lcc-win.
It features:
o...
|
by: jacob navia |
last post by:
Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |