git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: git@vger.kernel.org
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String   Library.
Date: Fri, 07 Sep 2007 11:31:07 +0200	[thread overview]
Message-ID: <85wsv26cv8.fsf@lola.goethe.zz> (raw)
In-Reply-To: <fbr4oi$5ko$1@sea.gmane.org>

Walter Bright <boost@digitalmars.com> writes:

> David Kastrup wrote:
>> Walter Bright <boost@digitalmars.com> writes:
>>
>>> A canonical example is that of a loop. Consider a simple C loop over
>>> an array:
>>>
>>> void foo(int array[10])
>>> {
>>>     for (int i = 0; i < 10; i++)
>>>     {   int value = array[i];
>>>         ... do something ...
>>>     }
>>> }
>>>
>>> It's simple, but it has a lot of problems:
>>>
>>> 1) i should be size_t, not int
>>
>> Wrong.  size_t is for holding the size of memory objects in bytes, not
>> in terms of indices.  For indices, the best variable is of the same
>> type as the declared index maximum size, so here it is typeof(10),
>> namely int.
>
> The easiest way to show the error is consider the code being ported to
> a typical 64 bit C compiler. int's are still 32 bits, yet the array
> can be larger than 32 bits.

Not if it is an array declared of size 10.  And if it isn't, you have
no business stating so in the function prototype.

Willfully obfuscate programming does not prove anything.

>>> 2) array is not checked for overflow
>>
>> Why should it?
>
> Because the 10 array dimension is not statically checked in C. I
> could pass it a pointer to 3 ints without the compiler
> complaining. This makes it a potential maintenance problem.

Nonsense.  Again, C won't keep you from shooting yourself in the foot.

>>> 3) 10 may not be the actual array dimension
>>
>> Your point is?
>
> Array buffer overflow errors are commonplace in C, because array
> dimensions are not automatically checked at either compile or run
> time.

No, because programmers get things wrong.  You can tell C compilers to
check all array accesses, but that is a performance issue.  For gcc,
we have

`-fmudflap -fmudflapth -fmudflapir'
     For front-ends that support it (C and C++), instrument all risky
     pointer/array dereferencing operations, some standard library
     string/heap functions, and some other associated constructs with
     range/validity tests.  Modules so instrumented should be immune to
     buffer overflows, invalid heap use, and some other classes of C/C++
     programming errors.  The instrumentation relies on a separate
     runtime library (`libmudflap'), which will be linked into a
     program if `-fmudflap' is given at link time.  Run-time behavior
     of the instrumented program is controlled by the `MUDFLAP_OPTIONS'
     environment variable.  See `env MUDFLAP_OPTIONS=-help a.out' for
     its options.

Why isn't it the default?  Because it is a performance issue.

>>> 5) type of array may change, but the type of value may not get
>>> updated
>>
>> Huh?
>
> Let's say our fearless maintenance programmer decides to make it an
> array of longs, not an array of ints. He overlooks changing the type
> of value in the loop.

Again: C does not prevent you from shooting yourself in the foot.

>>> 6) crashes if array is NULL
>>
>> Certainly.  Your point being?
>
> I consider an array that is NULL to have no members,

Nobody else does that.

> so instead of crashing the loop should execute 0 times.

If the loop count is zero, this is what will happen.

>>> 7) only works with arrays and pointers
>>
>> Since there are only arrays and pointers in C, not really a
>> restriction.
>
> C has structs, too, as well as more complicated user defined
> collections. Essentially, you cannot (simply) write generic
> algorithms in C, because you cannot (simply) generically express
> iteration.

Of course you can.  Macros exist.

>> Most of those are toy concerns.  They prevent problems that don't
>> actually occur much in practice.
>
> I beg to differ - buffer overflow bugs are common and expensive.

Then compile your program with appropriate options.  The key word is
"option".  You don't have to take the performance hit if you don't
want or need it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

  reply	other threads:[~2007-09-07  9:31 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-04 20:50 Lukas Sandström
2007-09-04 21:38 ` Alex Riesen
2007-09-04 23:01   ` Pierre Habouzit
2007-09-05 14:54 ` Kristian Høgsberg
2007-09-05 17:29   ` Matthieu Moy
2007-09-06  2:30     ` Miles Bader
2007-09-06  4:48     ` Dmitry Kakurin
2007-09-06  4:59       ` Shawn O. Pearce
2007-09-06  9:12         ` Andreas Ericsson
2007-09-06  9:35           ` Junio C Hamano
2007-09-06 10:21             ` Andreas Ericsson
2007-09-06  9:52           ` David Kastrup
2007-09-06  5:03       ` Miles Bader
2007-09-06 12:08         ` Johannes Schindelin
2007-09-06 17:50       ` Linus Torvalds
2007-09-07  0:21         ` Dmitry Kakurin
2007-09-07  0:38           ` Linus Torvalds
2007-09-07  1:08             ` Dmitry Kakurin
2007-09-07  1:27               ` Linus Torvalds
2007-09-07  3:09                 ` Dmitry Kakurin
2007-09-07  5:48                   ` David Symonds
2007-09-07  6:15                   ` Theodore Tso
2007-09-20 14:06                     ` Steven Burns
2007-09-20 14:56                       ` Andreas Ericsson
2007-09-07  6:31                   ` Andreas Ericsson
2007-09-07 22:17                     ` Dmitry Kakurin
2007-09-07 22:28                       ` David Kastrup
2007-09-08  0:37                         ` Dmitry Kakurin
2007-09-08  6:25                           ` David Kastrup
2007-09-09  0:29                       ` Andreas Ericsson
2007-09-07  6:52                   ` David Kastrup
2007-09-07 10:28                   ` Johannes Schindelin
2007-09-07 10:26                 ` Johannes Schindelin
2007-09-07  6:50               ` David Kastrup
2007-09-07  1:12             ` Linus Torvalds
2007-09-07  1:40               ` alan
2007-09-07  5:09               ` Walter Bright
2007-09-07  7:40                 ` David Kastrup
2007-09-07  8:15                   ` Walter Bright
2007-09-07  8:26                     ` David Kastrup
2007-09-07  9:14                       ` Walter Bright
2007-09-07  9:31                         ` David Kastrup [this message]
2007-09-07 20:22                           ` Walter Bright
2007-09-07 20:27                             ` David Kastrup
2007-09-07 23:16                               ` Walter Bright
2007-09-08 23:50                             ` Andreas Ericsson
2007-09-09  0:37                               ` Pierre Habouzit
2007-09-09  1:36                                 ` Andreas Ericsson
2007-09-07 11:36                   ` Wincent Colaiuta
2007-09-07  9:41                 ` Pierre Habouzit
2007-09-07 19:03                   ` Walter Bright
2007-09-07 19:31                     ` David Kastrup
2007-09-07 20:49                       ` Walter Bright
2007-09-07 19:41                     ` Pierre Habouzit
2007-09-07 19:51                       ` David Kastrup
2007-09-07 19:59                         ` Pierre Habouzit
2007-09-07 20:40                       ` Walter Bright
2007-09-07 20:56                         ` Pierre Habouzit
2007-09-07 22:54                           ` Walter Bright
2007-09-08  0:56               ` John 'Z-Bo' Zabroski
2007-09-08  6:36                 ` David Kastrup
2007-09-19 19:56               ` Steven Burns
2007-09-07  3:06           ` Wincent Colaiuta
2007-09-07  4:06             ` Paul Wankadia
2007-09-07  4:30               ` Nicolas Pitre
2007-09-07  9:19               ` Wincent Colaiuta
2007-09-07  6:25             ` Andreas Ericsson
2007-09-07 10:56               ` Johannes Schindelin
2007-09-07 11:54                 ` Andreas Ericsson
2007-09-07 12:33                   ` Wincent Colaiuta
2007-09-07 12:55                     ` Karl Hasselström
2007-09-07 13:58                     ` Andreas Ericsson
2007-09-07 14:13                       ` Wincent Colaiuta
2007-09-09  0:09                         ` Andreas Ericsson
2007-09-07 16:09                 ` David Kastrup
2007-09-07 11:30               ` Wincent Colaiuta
2007-09-07  8:36             ` Walter Bright
2007-09-07  9:41               ` Andreas Ericsson
2007-09-07 19:23                 ` Walter Bright
2007-09-07 19:40                   ` David Kastrup
2007-09-09  0:25                   ` Andreas Ericsson
2009-09-17 16:23                   ` Bernd Jendrissek
2007-09-07 11:52               ` Wincent Colaiuta
2007-09-07 19:25                 ` Walter Bright
2007-09-22 16:52               ` Steven Burns
2007-09-07  6:47           ` David Kastrup
2007-09-07  7:41             ` Andy Parkins
2007-09-07  8:08               ` David Kastrup
2007-09-07 10:21           ` Johannes Schindelin
2007-09-08  0:32             ` Dmitry Kakurin
2007-09-08  6:24               ` David Kastrup
2007-09-08 23:25               ` Alex Riesen
2007-09-24 13:41         ` figo
2007-09-24 13:57           ` David Kastrup
2007-09-25 19:19             ` Steven Burns
2007-09-25 19:55               ` David Kastrup
2012-05-22 18:30         ` Syed M Raihan
2010-06-10 19:12       ` Ian Molton
2010-06-11 12:23         ` Jakub Narebski
2010-06-11 13:33           ` Dario Rodriguez
2007-09-05 15:27 ` Kristian Høgsberg
2007-09-07 10:47 ` Lukas Sandström

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=85wsv26cv8.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=git@vger.kernel.org \
    --subject='Re: [RFC] Convert builin-mailinfo.c to use The Better String   Library.' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git