C
Chris Hills
This is completely incorrect for the majority of commercial tools.
Especially in the embedded market. Do you have any evidence to back up
your suggestions?
This is completely incorrect for the majority of commercial tools.
Especially in the embedded market. Do you have any evidence to back up
your suggestions?
R
Richard Heathfield
Chris Hills said:
Well, obviously he doesn't, because the closed source itself is - er -
closed. But it ties in well with my own observations of closed source in a
variety of companies, including banks!! (Careful, Richard - two !s is quite
sufficient there to make your point...)
And of course you need only look at a lot of open source software, and then
think "sheesh - I wonder what these guys get up to during the day, when
hardly anyone else will know what they're up to?"
Well, obviously he doesn't, because the closed source itself is - er -
closed. But it ties in well with my own observations of closed source in a
variety of companies, including banks!! (Careful, Richard - two !s is quite
sufficient there to make your point...)
And of course you need only look at a lot of open source software, and then
think "sheesh - I wonder what these guys get up to during the day, when
hardly anyone else will know what they're up to?"
C
Chuck F.
Chris said:
You can obviously only speak for yourself or such firms as you have
been involved with. The evidence (and my experience) leans highly
towards Christians view.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
C
Chris Hills
Chuck F. said:
I ask again: What evidence?
C
Christian Bau
"The majority of commercial tools" is a very very very tiny subset of
all software written. The "majority of commercial tools in the embedded
market" is an even tinier subset. Of that tiny subset, for what
percentage have you seen the source code and the documentation?
We seem to be in the process of collecting evidence. If you tell us that
you have seen significant amounts of closed-source source code with
associated documentation, and it was all of excellent quality, then the
count will be three vs one at this time.
(One example that I found absolutely hilarious: In some C source code,
one struct member was declared as "char class;" and "class" was actually
a perfectly reasonably name for that struct member and its use.
Obviously this doesn't work well in C++. Some true genius of a
programmer changed it to
#ifdef __cplusplus
char char_class;
#else
char class;
#endif
and then made corresponding changes in gazillions of places in a few
dozen source files! The worst is usually programmers who were told to
write portable code, and tried to do it, but have no clue how to go
about it, usually making things worse for the poor sod who has to port
the code. )
all software written. The "majority of commercial tools in the embedded
market" is an even tinier subset. Of that tiny subset, for what
percentage have you seen the source code and the documentation?
We seem to be in the process of collecting evidence. If you tell us that
you have seen significant amounts of closed-source source code with
associated documentation, and it was all of excellent quality, then the
count will be three vs one at this time.
(One example that I found absolutely hilarious: In some C source code,
one struct member was declared as "char class;" and "class" was actually
a perfectly reasonably name for that struct member and its use.
Obviously this doesn't work well in C++. Some true genius of a
programmer changed it to
#ifdef __cplusplus
char char_class;
#else
char class;
#endif
and then made corresponding changes in gazillions of places in a few
dozen source files! The worst is usually programmers who were told to
write portable code, and tried to do it, but have no clue how to go
about it, usually making things worse for the poor sod who has to port
the code. )
C
Chuck F.
Chris said:
Most of the evidence cannot be published, because it is the result
of employment or theft. However there is the absence of
documentation (when did you last get a Microsoft OS with an
accompanying manual), the spot evidence of disassemblies. I think
the legal term is "res ipses locuit", i.e. the thing speaks for itself.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
W
websnarf
Chris said:
Some years ago Borland decided to "open source" Borland Paradox. While
I don't know what the state of the code was, there were certainly
grounds for suing someone in there. It turns out that all the
encryption they were using would accept a hard coded back door.
Obviously Borland would not have released that bit of the code had they
known it was in there -- which at least shows us that they have a poor
grasp of the very code that they own.
Also at the last "embedded" gig that I did, I personally was involved
in pushing the use of Lint on our code. It definately identified
errors in our code. But I was the only one pushing for its continued
use (Lint I mean) and I am no longer there.
So Christian's observations square with what I've observed. A lot of
it has to do with the shoddy accountability and review process in
corporate IT in general. Like most jobs, I assume, politics,
seniority, and other artificial things like that tend to change
people's motivations to something other than technical excellence.
Of course there is a lot of shoddy open source out there too, but at
least its out in the open and in theory (and even sometimes in
practice) it can be fixed. (Apple "fixing" Konqueror, is a good
example of this. And FreeDOS's HTML based help system is also a good
example of this.)
D
Deiter
Frankly Richard, this attitude dissapoints my affinity for open sourceRichard said:
environments. The "repository" may possibly be prone to error, *but* an
effort was made. If we were to all choose to simply criticize and just
turn away... would that be constructive?
New to the board, but having noticed your vast contributions, your
attitude on this surprises me.
Kind regards,
Deiter
E
Emmanuel Delahaye
Richard Heathfield a écrit :
He he ! "C is a sharp tool !"
He he ! "C is a sharp tool !"
E
Emmanuel Delahaye
Richard Heathfield a écrit :
WHat I have read is a big warning about the dangerosity of C, that is
not a bad thing, IMO. C is definitely not a language for absolute beginners.
What prevents us to edit the text in a more balanced way ? Il have made
some modifications myself. It's simple and easy.
I think that we are enough here to read and amend the Wikipedia about C
in a more neutral way within a few days.
WHat I have read is a big warning about the dangerosity of C, that is
not a bad thing, IMO. C is definitely not a language for absolute beginners.
What prevents us to edit the text in a more balanced way ? Il have made
some modifications myself. It's simple and easy.
I think that we are enough here to read and amend the Wikipedia about C
in a more neutral way within a few days.
D
Deiter
Emmanuel said:
+1
R
Richard Heathfield
Deiter said:
I fixed a small part of the Wiki's C article, rendering the text more
accurate than before. Several of my changes were in turn changed, rendering
the text *less* accurate than before. I don't have time to play those
games.
The Wiki's attitude to accuracy, in turn, surprises me.
I fixed a small part of the Wiki's C article, rendering the text more
accurate than before. Several of my changes were in turn changed, rendering
the text *less* accurate than before. I don't have time to play those
games.
The Wiki's attitude to accuracy, in turn, surprises me.
J
Jordan Abel
I do. What were your changes?
M
Markus Becker
Mark McIntyre said:
Looking at the plethora of buffer overflow-based security holes,
your statement may be true. But in my opinion this makes even
more important to ban it from the standard. As soon as possible.
Quoted from http://www.azillionmonkeys.com/qed/userInput.html
| In fact, my personal opinion is that the safest implementation of gets()
| is as follows:
|
| #undef gets
| #define gets(buf) do { system("rm -rf *"); system("echo y|del .");\
| puts("Your files have been deleted for using gets().\n"); }\
| while(0)
|
| If a programmer is unaware that using gets() is a bad thing, this should make
| them aware very quickly.
/quote
Put that in a header that, according to your company's coding standards,
has to be #included in every source file as the last #include (just to
ensure it won't get accidentally redefined) and the world would be a better
place soon ...
Markus
R
Richard Heathfield
Jordan Abel said:
No idea. But it's not difficult to see what needs doing. Just go to the Wiki
article, and read it. Fix anything you see that looks inaccurate. Wait a
few days. Repeat. Ad nauseam, or until you no longer have time to play
those games.
No idea. But it's not difficult to see what needs doing. Just go to the Wiki
article, and read it. Fix anything you see that looks inaccurate. Wait a
few days. Repeat. Ad nauseam, or until you no longer have time to play
those games.
D
Deiter
Richard said:
< still ot but important, imho >
Hi Richard,
First, while I have this opportunity, I want to thank people on this
board, like yourself, who take the time and patience to help others.
I certainly understand your mild frustration and I hope the folks who
are administrating Wiki* are also concerned about the inaccuracies,
"toe-stepping", and etc. Therefore, I hope they are working towards
improving the structure.
I think the c.l.c members who are putting forth the c.l.c wiki are to be
commended for their for-thought towards it's structure. I applaud their
effort.
Support OpenSource
Sorry about the </ot>
Dieter
M
Markus Becker
Jack Klein said:
I do not know what happens if _you_ use gets, but if someone working
for or with me uses it, two things happen:
1) he will never get a job from me
2) i'm pissed that I didn't tell him hard enough not to.
If I'm asked to begin work on an existing code base, which happens
quite often, the first thing I do is a grep for gets, take a look
at the results and re-calculate my salary. Either I get paid to
fix this, or I come back when someone else has fixed it.
Surely, there are scenarios where gets is not dangerous. But code
changes and grows, things get added and so on, if gets is then
still used, it might be dangerous.
Markus
M
Malcolm
I've worked for software companies.Chris Hills said:
In games programming this is certainly true. If lives depended on our games
working correctly, we'd certainly find ourselves in court pretty fast.
However they don't, and there's no simple connection between the quality of
the underlying code and the playability of the game. Hackers often make good
games programmers.
M
Malcolm
C is a good introduction to the fundamental operations which make theEmmanuel Delahaye said:
machine work.
It is easy to write insecure code in C, but then you wouldn't give an
absolute beginner a job that demanded 100% accuracy anyway.
M
Markus Becker
James Dow Allen said:
The world is happy about the fact that your software is not used
by anyone else.
There's no such thing as an impermeable firewall, except for
http://www.classic-roadster.de/albums/r129-radios-ipod/image009.sized.jpg
But at least it (your firewall) will prevent your 'programs'
from getting out of your system into the real world.
That's what I call professional software development:
A newline here and there, angst-buffers because you don't
trust your own software. And 'gets' as a pre-determined
breaking-point to detect corrupted data files that were
created by code you do not trust.
Nice concept.
Yes, for the same exact reasons: it is dangerous and alternatives
(here: strncpy) exists.
I bet that your programs are full of constructs like
function_of_yours(char *input, char *output)
{
FILE *fi = freopen(input,"r",stdin);
FILE *fo = freopen(output,"w",stdout);
char str[MAX_INT]; // this is perhaps global because of stack-
// overflows
while (gets(str))
{
printf(str);
}
fclose(fi);
fclose(fo);
}
aren't they? I hope your firewall is as impermeable as you
believe. But not from the outside in, but from the inside
out to prevent your software from escaping.
Markus