git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: Walter Bright <boost@digitalmars.com>
To: git@vger.kernel.org
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String   Library.
Date: Fri, 07 Sep 2007 02:14:01 -0700	[thread overview]
Message-ID: <fbr4oi$5ko$1@sea.gmane.org> (raw)
In-Reply-To: <851wda7ufz.fsf@lola.goethe.zz>

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. You're right in that what we want to be able to do 
is typeof(array dimension), but there is no way to do that automatically 
in C, which is my point. If the array dimension changes, you have to 
carefully check to make sure every loop dependency on the type is 
updated, too.

size_t will always work, however, making it a better choice than int, at 
least for C.

>> 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. Also, the maintenance programmer may 
change the array dimension in the function signature, but overlook 
changing it in the for loop. Again, a maintenance problem.


>> 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. 
This is an expensive problem. Some C APIs try to deal with this by 
passing a second argument for arrays giving the dimension (snprintf, for 
example), but this tends to be sporadic, not conventional. It being 
extra work for the programmer inevitably means it doesn't get done.


>> 4) may be more efficient to step through the array with pointers,
>> rather than indices
> 
> No.  It is a beginners' and advanced users' mistake to think using
> pointers for access is a good idea.  Trivial optimizations are what a
> compiler is best at, not the user.  Using pointer manipulation will
> more often than not break loop unrolling, loop reversal, strength
> reduction and other things.

C compilers vary widely in the optimizations they'll do for simple 
loops. I see often enough attempts by programmers to take such matters 
into their own hands. I agree with you on that - and suggest the 
language should not tempt the user to do such optimizations.

>> 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. Suddenly, things subtly break because of overflows. 
Or maybe he changed the int to an unsigned, now the divides in the loop 
give different answers. Etc. There really isn't any compiler/language 
help in finding these kinds of problems.


>> 6) crashes if array is NULL
> 
> Certainly.  Your point being?

I consider an array that is NULL to have no members, so instead of 
crashing the loop should execute 0 times.


>> 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 still express anything in C if you're willing to work 
hard enough to get it. Me, I'm too lazy <g>. It's like why I can't play 
chess - everytime I try to play it instead I think about writing a 
program to do the hard work for me.


>> As a programmer, I'm specifying exactly what I want to happen without
>> much extra puffery. It's less typing, simpler, and more resistant to
>> bugs.
>>
>> 1) correct loop index type is selected based on the type of array
>> 2) arrays carry with them their dimension, so foreach is guaranteed to
>> step through the loop the correct number of times
>> 3) implementation decides if pointers will do a better job than
>> indices, based on the compilation target
>> 4) type of value is inferred automatically from the type of array, so
>> no worries if the type changes
>> 5) Null arrays have 0 length, so no crashing
>> 6) works with any collection type
> 
> 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. The 
nice thing about the D loop is it is LESS typing than the C one - you 
get the extra robustness for free.

Let's look at the code gen for the inner loop for C:

L8:             push    [EBX*4][ESI]
                 call    near ptr _bar
                 inc     EBX
                 add     ESP,4
                 cmp     EBX,0Ah
                 jb      L8

and for D:

LE:            mov     EAX,[EBX]
                call    near ptr _D4test3barFiZv
                add     EBX,4
                cmp     EBX,ESI
                jb      LE

I think you can see that performance isn't an impediment.

  reply	other threads:[~2007-09-07  9:14 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 [this message]
2007-09-07  9:31                         ` David Kastrup
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='fbr4oi$5ko$1@sea.gmane.org' \
    --to=boost@digitalmars.com \
    --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