Bounds checking and safety in C

[jacob navia]

We hear very often in this discussion group that
bounds checking, or safety tests are too expensive
to be used in C.

Several researchers of UCSD have published an interesting
paper about this problem.

http://www.jilp.org/vol9/v9paper10.pdf

Specifically, they measured the overhead of a bounds
checking implementation compared to a normal one, and
found that in some cases the overhead can be reduced
to a mere 8.3% in some cases...

I quote from that paper

< quote >
To summarize, our meta-data layout coupled with meta-check instruction
reduce the average overhead of bounds checking to 21% slowdown which is
a significant reduction when compared to 81% incurred by current
software implementations when providing complete bounds checking.
< end quote>

This 21% slowdown is the overhead of checking EACH POINTER
access, and each (possible) dangling pointer dereference.

If we extrapolate to the alleged overhead of using some extra
arguments to strcpy to allow for safer functions (the "evil
empire" proposal) the overhead should be practically ZERO.

Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.

I quote again from that paper:

< quote >
As high GHZ processors become prevalent, adding hardware support to
ensure the correctness and security of programs will be just as
important, for the average user, as further increases in processor
performance. The goal of our research is to focus on developing
compiler and hardware support for efficiently performing software checks
that can be left on all of the time, even in production code releases,
to provide a signicant increase in the correctness and security of
software.

< end quote >

The C language, as it is perceived by many people here, seems
frozen in the past without any desire to incorporate the changing
hardware/software relationship into the language itself.

When this issues are raised, the "argument" most often presented is
"Efficiency" or just "it is like that".

This has lead to the language being perceived as a backward and error
prone, only good for outdated software or "legacy" systems.

This pleases again the C++ people, that insist in seeing their language
as the "better C", and obviously, C++ is much better in some ways as
C, specially what string handling/common algorithms in the STL/ and
many other advances.

What strikes me is that this need not be, since C could with minimal
improvements be a much safer and general purpose language than it is
now.

Discussion about this possibility is nearly impossible, since a widely
read forum about C (besides this newsgroup) is non existing.

Hence this message.

To summarize:

o Bounds checking and safer, language supported constructs are NOT
impossible because too much overhead
o Constructs like a better run time library could be implemented in a
much safer manner if we would redesign the library from scratch,
without any effective run time cost.
jacob

P.S. If you think this article is off topic, please just ignore it.
I am tired of this stupid polemics.

[¬a\\/b]

On 30 Jul 2007 20:43:46 GMT, (Richard Tobin) wrote:

>I believe the Americans have a phrase "put up or shut up" which seems
to fit.

here in Italy have some 'meaningfull' phrase too; for example
"C'è chi può c'è chi non può, io può" M.

>-- Richard

this is not a valid signature

[websnarf]

On Jul 30, 1:25 pm, Keith Thompson <[e-mail]:

jacob navia <[e-mail]:

[...]

I never said that I wanted to make zero terminated strings illegal.

Good.

I just propose that OTHER types of strings could be as well
supported by the language, nothing else.

Other types of strings can already be well supported by the language.
The only current limitation is that some operations require a bit
more syntax than you might like. For example, if you have a type
String that's really a structure, you can't use a cast to 'char*' to
convert a String to a classic C string -- but if one of the members
is a char* pointing to a C string, you can just use something like
"obj.str". You can't use string literals for String values, but you
can use a function call.

For example:

...
String s = Str("hello");
s = append(s, Str(", world"));

How do you implement Str as something that supports that above that 1)
works in C89 compilers, 2) does not leak memory and 3) works on a
multi-threaded system?

As a macro you can't pass a naked structure as parameter in C89
compilers, and as a return to a function its presumably going to
allocate resources that you are not keeping track of externally in the
second line. If you keep track of them in some hidden structure
somewhere then, besides being weird, you lose multi-threading
capabilities.

In Bstrlib the above is solved:

struct tagbstring s = bfromcstr ("hello");

printf("%s\n", s.str);
...

If you want the convenience of using string literals and so forth, I
think that only a few minor changes to the language would be required.
I haven't thought this through, but I suspect that most or all of
these changes could be implemented as conforming extensions (i.e.,
extensions that don't alter the behavior of any strictly conforming
code; see C99 4p6). Any programs that depend on such extensions would
of course be restricted to implementations that support them, but it
could be the first step in establishing existing practice and possibly
getting the extensions adopted in a future C standard.

Incidentally, depending on how this hypothetical String type is
implemented, aliasing could be an issue. For example;

String s1, s2;
s1 = "hello";
s2 = s1;
s2.str[0] = 'j';

s2 is now equal to str("jello"). Is s1 equal to str("jello"), or to
str("hello")? In other words, does assignment of Strings copy the
entire string value, or does it just create a new reference to the
same string value?

Certainly classic C strings have the same issue, but there's bound to
be considerable work to be done in deciding how a new (standard?)
String type will deal with it.

--
Keith Thompson (The_Other_Keith) [e-mail] <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[websnarf]

Google Groups is a piece of crap, BTW. As I was saying:

On Aug 1, 10:16 am, [e-mail] wrote:

On Jul 30, 1:25 pm, Keith Thompson <[e-mail]:

For example:

...
String s = Str("hello");
s = append(s, Str(", world"));

How do you implement Str as something that supports that above that
1) works in C89 compilers, 2) does not leak memory and 3) works on a
multi-threaded system?

As a macro you can't pass a naked structure as parameter in C89
compilers, and as a return to a function its presumably going to
allocate resources that you are not keeping track of externally in
the second line. If you keep track of them in some hidden structure
somewhere then, besides being weird, you lose multi-threading
capabilities.

In Bstrlib the above is solved as:

struct tagbstring s = bfromcstr ("hello");
bcatblk (s, bsStaticBlkParms (", world"));

The bfromcstr function allocates resources. The bsStaticBlkParms
macro just plays a simplistic trick which makes a pair of parameters
(the char * string and its length) that can be fed straight to
bcatblk's last two parameters.

printf("%s\n", s.str);

printf ("%s\n", bdatae (s, "<Out of memory>"));

...
If you want the convenience of using string literals and so forth,
I think that only a few minor changes to the language would be
required.

I have found that the alternatives supported in Bstrlib take mostly
horizontal source code space. So you could create something like:

S"This is a tagbstring"

but its not a big enough deal to care too much about it.

I haven't thought this through, but I suspect that most or all of
these changes could be implemented as conforming extensions (i.e.,
extensions that don't alter the behavior of any strictly conforming
code; see C99 4p6). Any programs that depend on such extensions
would of course be restricted to implementations that support them,

Which is the main reason why its a *BAD* idea.

but it could be the first step in establishing existing practice
and possibly getting the extensions adopted in a future C standard.

Irrelevant. For what are now plainly obvious reasons. (Future C
standards clearly no longer have any influence on real world
programming practice.)

Incidentally, depending on how this hypothetical String type is
implemented, aliasing could be an issue. For example;

String s1, s2;
s1 = "hello";
s2 = s1;
s2.str[0] = 'j';

s2 is now equal to str("jello"). Is s1 equal to str("jello"), or
to str("hello")? In other words, does assignment of Strings copy
the entire string value, or does it just create a new reference to
the same string value?

C is a language that supports pointers. I don't know what your
question is. Bstrlib is very aliasing sensitive and always does
things as correctly as possible (which almost always is "just make it
work").

Certainly classic C strings have the same issue, but there's bound
to be considerable work to be done in deciding how a new
(standard?) String type will deal with it.

You have a complete model and tested implementation that is used in
the real world that you can peruse at your leisure. Certainly nobody
has bugged me about how I deal with aliasing in Bstrlib.

--
Paul Hsieh
http://bstring.sf.net/

[CBFalconer]

jacob navia wrote:

>

.... snip much about addition of bounds checking ...

>
The second is the "spirit of C". C is for macho programmers
that do not need bounds checking because they never make mistakes.

And there are others.

I wanted with my post address the first one. Those researchers
prove that a FAST implementation of bounds checking is
feasible even without language support.

I would say that with language support, the task would be much
easier AND much faster, so fast that it could be done at run time
without any crushing overhead.

I suggest you go back and read about the tests on complete bounds
checking in Pascal, performed roughly 30 years ago. The conclusion
was that routine enabling of such would slow most code down by
something like 2 or 3 percent. No more. The compiler can detect
which cases require checking. All that is required from the
programmer is proper typing.

Of course, Pascal is a sanely designed language, without violent
bandying of pointers, with convenient sub-ranges, etc. The net
effective result is that C cannot be thoroughly checked at compile
or run time.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

jacob navia wrote:

dan wrote:

>>
Is it reasonable to suggest that if you don't think C is safe, or
needs bounds checking, then develop or use another language that is
safer?

Excuse me but I do not see why I would need another computer
language to write:

int Strcmp(String s1,String s2);

Where String could be defined as:

typedef struct tagString {
size_t len;
char *chars;
};

Why can't we use this in C instead of being stuck with zero
terminated strings forever?

But you can. That thing is then of type String, which is quite
different from the type string. What's the problem?

Of course you may have problems with users, who don't know what a
String is, and can't just go to their reference books and look it
up.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

[jacob navia]

CBFalconer wrote:

jacob navia wrote:
... snip much about addition of bounds checking ...

>The second is the "spirit of C". C is for macho programmers
that do not need bounds checking because they never make mistakes.

And there are others.

I wanted with my post address the first one. Those researchers
prove that a FAST implementation of bounds checking is
feasible even without language support.

I would say that with language support, the task would be much
easier AND much faster, so fast that it could be done at run time
without any crushing overhead.

I suggest you go back and read about the tests on complete bounds
checking in Pascal, performed roughly 30 years ago. The conclusion
was that routine enabling of such would slow most code down by
something like 2 or 3 percent. No more. The compiler can detect
which cases require checking. All that is required from the
programmer is proper typing.

Of course, Pascal is a sanely designed language, without violent
bandying of pointers, with convenient sub-ranges, etc. The net
effective result is that C cannot be thoroughly checked at compile
or run time.

I agree with that. 2-3% would be feasible now with optimizing
compilers that would take the bounds check out of a loop, for instance

But C is much harder than pascal in this area

[Kelsey Bjarnason]

On Mon, 30 Jul 2007 17:09:35 +0000, JT wrote:

On Jul 30, 4:53 pm, jacob navia <[e-mail]:

>The most obvious example is the development of
length delimited strings [strlen] [strcat]
I have been promoting this change [..] for several years.

First of all, it was thought of long ago [by OTHER people]
Second of all, its overall efficiency is still debated[*]
Third of all, companies such as Microsoft already REQUIRE it
internally

You're taking recommendations from a company with one of the worst
security/safety records in computing history?

[Ben Pfaff]

JT <ja******@gmail.comwrites:

* I'll leave the literature search and other
examples for others to cite. One quick example is
the tokenization and manipulation of an input text block.
With NUL-terminated string, you can tokenize
the input buffer in-place (by replacing whitespace
with \0), but with length-denoted strings you need
to always malloc a new space since there's no room
for the length field.

It depends. I can define a string as a structure that contains a
length and a pointer. I can then point into the middle of an
existing string with no need to do any copying. This approach
has its own downsides, of course.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Peter J. Holzer]

On 2007-07-31 22:12, santosh <sa*********@gmail.comwrote:

Peter J. Holzer wrote:

>On 2007-07-29 23:21, Guillaume <"grsNOSPAM at NOTTHATmail dot com"wrote:

>>1. No bounds checking. You read or write data outside bounds. It
generates an exception.

This IS bounds checking.

This is the case where the operating system traps access to addresses not
owned by the process.

This is probably what he meant, but not what he wrote. He wrote:

"You read or write data outside bounds. It generates an exception." That
is the very definition of bounds checking (indeed he uses exactly the
same words for defining "bounds checking" below). The bounds are
checked, and if you try to access data outside, you get an exception.
(Actually, you might get an exception just by computing an out-of-bounds
pointer, but lets not be too picky. The memory maps maintained by the OS
usually don't achieve that: An OS "segment" usually contains a lot of
objects as well as unused space around them (e.g., memory which has been
freed, or unused stack space), so you can very often read or write data
outside of the bounds of your objects without getting an exception.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Richard Bos]

"Peter J. Holzer" <hj*********@hjp.atwrote:

What is unclear about "This slowdown is still too large for the checks
to be used in released software"? The authors are clearly of the opinion
that the speedup from using OMD instead of PMD is not enough. (I don't
share that opinion: For most software an overhead of 63.9% won't matter
at all).

I must disagree with that. For most software, an overhead of 63.9% will
matter a lot, except in the bits where the computer is waiting for user
or disk input. One could argue that most programs are bounded by those
anyway, but that's not really true. Or rather, it's only true if you
look at it from the computer's POV, not from the user's POV.
To the user, time spent typing is not the same as time spent waiting for
the computer to do its job; and of the time spent waiting, the part
where the computer just sits there and appears to do nothing is much
more irritating than the part where it's clearly doing some hard work in
the background because the disk light is flickering like nobody's
business.
Therefore, _to the user_, who is the most important person in a computer
program's life, 63.9% added to the time he spends looking at a seemingly
frozen screen is a big deal; a much bigger deal than, for example, a
63.9% addition to the time between keystrokes.

Richard

[Peter J. Holzer]

On 2007-08-03 09:32, Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:

"Peter J. Holzer" <hj*********@hjp.atwrote:

>What is unclear about "This slowdown is still too large for the checks
to be used in released software"? The authors are clearly of the opinion
that the speedup from using OMD instead of PMD is not enough. (I don't
share that opinion: For most software an overhead of 63.9% won't matter
at all).

I must disagree with that. For most software, an overhead of 63.9% will
matter a lot, except in the bits where the computer is waiting for user
or disk input.

Your "except" is "most software" in my experience. Interactive software
waits for the user most of the time (and for the disk most of the rest
of the time), and non-interactive software waits for disk (or network
connections) most of the time.

CPU usage only accounts for a small time of the run time of a program,
so increasing the CPU usage by 63.9% (or conversely, reducing it by 39%)
doesn't change the overall runtime much. (As an example, look at all
those programs written in scripting languages: They typically have a lot
more overhead than 60%. Yet the performance is adequate. As another
example, look at different computers: My old 800 MHz PIII is a lot
slower (much more than 60%) than my new 1.8 GHz Core2. But in everyday
work I don't notice much difference).

Of course there are programs (or libraries) where CPU usage does
matter and where 60% more CPU use is unacceptable. For these you may
want to turn off bounds checking. Or you may want to switch to Fortran.
Or find a better algorithm, which is 100 times faster, so your 60% are
completely insignificant.

One could argue that most programs are bounded by those anyway, but
that's not really true. Or rather, it's only true if you look at it
from the computer's POV, not from the user's POV.

Actually, I do look at it from the user's POV. If the response time
doesn't change by a noticeable amount, the user simply doesn't care how
much work the computer is doing (well, a howling fan might be a bit
distracting). Only when the program gets noticable faster or slower does
the user care.

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Antoninus Twink]

I'd recommend using GTK+ 2. It is highly portable and has safe types as
alternatives to C types. Eg. gchar * is a string type that can be used
safely without worrying about overwriting memory etc. But if you need to
use APIs with non-bounds-checked strings, you can directly typecast, eg.

gchar *s="hello";
gint i=strlen((char *) s);
On 29 Jul 2007 at 23:17, Ian Collins wrote:

jacob navia wrote:

>>
Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.

As Richard H. pointed out, this is a QoI issue. For may years I have
been using a development environment that supports run time bounds and
leak checking and I probably wouldn't use one that didn't.

There are alternatives to C if you want performance and better memory
safety.

--

[santosh]

Antoninus Twink wrote:

[ Please don't top-post. Fixed. ]

On 29 Jul 2007 at 23:17, Ian Collins wrote:

>jacob navia wrote:

>>>
Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.

As Richard H. pointed out, this is a QoI issue. For may years I have
been using a development environment that supports run time bounds and
leak checking and I probably wouldn't use one that didn't.

There are alternatives to C if you want performance and better memory
safety.

I'd recommend using GTK+ 2. It is highly portable and has safe types as
alternatives to C types. Eg. gchar * is a string type that can be used
safely without worrying about overwriting memory etc. But if you need to
use APIs with non-bounds-checked strings, you can directly typecast, eg.

gchar *s="hello";
gint i=strlen((char *) s);

C is used in a huge variety of situations where using GTK would not be an
option.

[Ian Collins]

Antoninus Twink wrote:

Please don't top post.

>
On 29 Jul 2007 at 23:17, Ian Collins wrote:

>jacob navia wrote:

>>Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.

As Richard H. pointed out, this is a QoI issue. For may years I have
been using a development environment that supports run time bounds and
leak checking and I probably wouldn't use one that didn't.

There are alternatives to C if you want performance and better memory
safety.

I'd recommend using GTK+ 2. It is highly portable and has safe types as
alternatives to C types. Eg. gchar * is a string type that can be used
safely without worrying about overwriting memory etc. But if you need to
use APIs with non-bounds-checked strings, you can directly typecast, eg.

gchar *s="hello";
gint i=strlen((char *) s);

While helpful on some platforms, there are places where C is used where
GTK isn't appropriate.

<OT>I think your example is wrong, GTK+ 2 uses GString as its string
type</OT>

--
Ian Collins.

[William Hughes]

On Aug 5, 5:11 pm, Antoninus Twink <[e-mail]:

I'd recommend using GTK+ 2. It is highly portable and has safe types as
alternatives to C types. Eg. gchar * is a string type that can be used
safely without worrying about overwriting memory etc. But if you need to
use APIs with non-bounds-checked strings, you can directly typecast, eg.

gchar *s="hello";
gint i=strlen((char *) s);

This seems similar to the suggested extension by
Jacob Navia. It has the same limitations.
While the "cast" (possibly overloading of the cast operator)
is more convenient than

old_string=get_old_string_from_new_string(new_stri ng)

we still have the same problems. We can play pointer games
with old_string which are not possible with new_string.
If the storage for the strings overlaps, then modifying old_string
may corrupt new_string. If not, then there is the problem
of memory allocation and cleanup (can we "free" old_string,
should we?)

- William Hughes

[Ben Pfaff]

Antoninus Twink <sp*****@invalid.comwrites:

I'd recommend using GTK+ 2. It is highly portable and has safe types as
alternatives to C types. Eg. gchar * is a string type that can be used
safely without worrying about overwriting memory etc. But if you need to
use APIs with non-bounds-checked strings, you can directly typecast, eg.

gchar *s="hello";
gint i=strlen((char *) s);

In the header files I have here for GTK+ 2.0, gchar and char are
identical types:
typedef char gchar;
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Antoninus Twink]

I believe you are mistaken. We have
typedef struct {
gchar *str;
gsize len;
gsize allocated_len;
} GString;

So if s is a GString then I believe the typecast (char *)s can fail in
the case that a GString struct has padding before its first member.
On 5 Aug 2007 at 21:24, Ian Collins wrote:

Antoninus Twink wrote:

Please don't top post.

>>
On 29 Jul 2007 at 23:17, Ian Collins wrote:

>>jacob navia wrote:
Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.

As Richard H. pointed out, this is a QoI issue. For may years I have
been using a development environment that supports run time bounds and
leak checking and I probably wouldn't use one that didn't.

There are alternatives to C if you want performance and better memory
safety.

I'd recommend using GTK+ 2. It is highly portable and has safe types as
alternatives to C types. Eg. gchar * is a string type that can be used
safely without worrying about overwriting memory etc. But if you need to
use APIs with non-bounds-checked strings, you can directly typecast, eg.

gchar *s="hello";
gint i=strlen((char *) s);

While helpful on some platforms, there are places where C is used where
GTK isn't appropriate.

<OT>I think your example is wrong, GTK+ 2 uses GString as its string
type</OT>

--

[santosh]

Antoninus Twink wrote:

Please don't top post.

On 5 Aug 2007 at 21:24, Ian Collins wrote:

>Antoninus Twink wrote:

Please don't top post.

>>>
On 29 Jul 2007 at 23:17, Ian Collins wrote:
jacob navia wrote:
Somehow, we are not realizing that with the extreme power of the
CPUs now at our disposal, it is a very good idea to try to
minimize the time we stay behind the debugger when developing
software. A balance should be sought for improving the safety
of the language without overly compromising the speed of the
generated code.
>
As Richard H. pointed out, this is a QoI issue. For may years I have
been using a development environment that supports run time bounds and
leak checking and I probably wouldn't use one that didn't.

There are alternatives to C if you want performance and better memory
safety.

I'd recommend using GTK+ 2. It is highly portable and has safe types as
alternatives to C types. Eg. gchar * is a string type that can be used
safely without worrying about overwriting memory etc. But if you need to
use APIs with non-bounds-checked strings, you can directly typecast, eg.

gchar *s="hello";
gint i=strlen((char *) s);

While helpful on some platforms, there are places where C is used where
GTK isn't appropriate.

<OT>I think your example is wrong, GTK+ 2 uses GString as its string
type</OT>

I believe you are mistaken. We have
typedef struct {
gchar *str;
gsize len;
gsize allocated_len;
} GString;

So if s is a GString then I believe the typecast (char *)s can fail in
the case that a GString struct has padding before its first member.

Look up 6.7.2.1(13) in n1124.pdf.

There shall be no padding at the begginning of a struct object.

[Default User]

Antoninus Twink wrote:

I believe you are mistaken.

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>

[Flash Gordon]

Antoninus Twink wrote, On 06/08/07 19:59:

Re: top-posting - the ancients understood that it's OK when they said,
"De Gustibus non est disputandum".

<snip>

The ancients did not have Usenet access. If you ignore the conventions
then you will find that although you have access you will not get much
help on a lot of groups because many people will decide you are not
worth the effort. So your choice, but you risk talking to only yourself.
--
Flash Gordon

[santosh]

Antoninus Twink wrote:

Re: top-posting - the ancients understood that it's OK when they said,
"De Gustibus non est disputandum".

Indeed, nor is there any accounting for perverted tastes.

Top posting is fundamentally illogical and annoying, for an Usenet post,
since one has to scroll all the way to the bottom to find out the context
of the poster's words, when, in a proper post, all he'd have had to do,
would've been to glance at the text immediately above the poster'.

[snip]

[Default User]

Antoninus Twink wrote:

Re: top-posting - the ancients understood that it's OK when they said,
"De Gustibus non est disputandum".

*plonk*

Brian

[CBFalconer]

Antoninus Twink wrote:

>
I believe you are mistaken. We have
typedef struct {
gchar *str;
gsize len;
gsize allocated_len;
} GString;

So if s is a GString then I believe the typecast (char *)s can fail in
the case that a GString struct has padding before its first member.

Which is specifically forbidden by the C standard.

Please do not top-post. Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material. See the following links:

--
<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/ (taming google)
<http://members.fortunecity.com/nnqweb/ (newusers)
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

Antoninus Twink <sp*****@invalid.comwrites:

Re: top-posting - the ancients understood that it's OK when they said,
"De Gustibus non est disputandum".

[...]

<http://www.caliburn.nl/topposting.html>
<http://www.cpax.org.uk/prg/writings/topposting.php>

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Antoninus Twink wrote:

>
Re: top-posting - the ancients understood that it's OK when they
said, "De Gustibus non est disputandum".

If what you say were true, then I believe you wouldn't need a
typecast at all - if gchar is a typedef for char, then couldn't
a gchar * be converted implicitly to a char *?

If you continue to top-post in this news group you will just be
PLONKED. Your choice.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Kelsey Bjarnason]

[snips]

On Fri, 03 Aug 2007 18:53:07 +0200, Peter J. Holzer wrote:

CPU usage only accounts for a small time of the run time of a program,
so increasing the CPU usage by 63.9% (or conversely, reducing it by 39%)
doesn't change the overall runtime much. (As an example, look at all
those programs written in scripting languages: They typically have a lot
more overhead than 60%. Yet the performance is adequate.

For some things, sure. Not for others.

I've worked on several small apps written in things such as PHP where
language features made the scripting approach more appealing than using C
or C++, but when doing testing the actual performance was so poor that I
tossed 'em entirely and went back to C.

If code exists in an already latency laden environment, such as a web
page, a little extra overhead doesn't matter, particularly when the code
doesn't actually do all that much; even with a lot of overhead compared to
C, the net result isn't that much in absolute terms. Now try the same
thing with, oh, a chess-playing program - the overhead is quite sufficient
to render the app essentially useless.