Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #56536 > unrolled thread
| Started by | krishna.myneni@ccreweb.org |
|---|---|
| First post | 2017-04-01 06:36 -0700 |
| Last post | 2017-04-06 10:53 -0700 |
| Articles | 20 on this page of 127 — 22 participants |
Back to article view | Back to comp.lang.forth
LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 06:36 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-01 14:57 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:55 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 15:24 +0000
Re: LLVM and Forth rickman <gnuarm@gmail.com> - 2017-04-01 11:21 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-01 11:57 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-02 04:02 -0500
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-02 06:35 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-02 14:41 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 01:09 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:32 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 13:52 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 07:59 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 16:08 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 12:22 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-03 20:10 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 22:19 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:12 +0200
Re: LLVM and Forth Walter Banks <walter@bytecraft.com> - 2017-04-05 17:27 -0400
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 14:29 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 03:17 -0500
Re: LLVM and Forth minforth@arcor.de - 2017-04-03 05:04 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 12:55 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-03 10:08 -0500
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-03 17:05 +0000
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-04 11:29 -0500
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 19:11 +0200
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-04 21:29 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-05 15:01 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-05 18:42 +0100
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:01 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 18:48 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 18:42 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-07 04:02 -0500
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 21:18 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:43 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 20:54 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:53 +0000
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 00:38 +0000
Re: LLVM and Forth James Kuyper <jameskuyper@verizon.net> - 2017-04-09 22:46 -0400
Re: LLVM and Forth Robert Wessel <robertwessel2@yahoo.com> - 2017-04-09 22:27 -0500
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 12:36 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 14:09 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-10 13:07 +0000
Re: LLVM and Forth Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-10 16:18 +0100
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-10 11:51 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-12 21:32 +0000
Re: LLVM and Forth "James R. Kuyper" <jameskuyper@verizon.net> - 2017-04-12 18:29 -0400
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-12 15:29 -0700
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-13 02:55 +0200
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-10 18:38 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-10 11:54 -0500
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-10 10:17 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:02 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 10:03 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 03:25 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 11:24 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 04:55 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-04 12:28 +0000
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-04 16:16 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 15:38 +0200
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-04 16:06 +0200
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-04 17:57 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-05 00:44 -0400
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 00:00 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 08:47 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-05 11:04 -0500
Re: LLVM and Forth john <anon@example.com> - 2017-04-05 18:04 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-05 13:04 -0700
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-05 18:20 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:14 -0700
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 12:33 +0000
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:49 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 18:55 +0100
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 20:41 +0000
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:47 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 21:56 +0100
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 23:59 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-06 17:10 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-07 03:33 -0400
Re: LLVM and Forth Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 22:48 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 15:06 -0400
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-08 22:45 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-09 14:27 +0000
Re: LLVM and Forth Joel Rees <joel.rees@gmail.com> - 2017-04-09 21:26 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-09 13:35 -0400
Re: LLVM and Forth Paul Rubin <no.email@nospam.invalid> - 2017-04-09 14:07 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 12:16 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-05 20:27 -0700
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:24 -0400
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 03:26 -0700
Re: LLVM and Forth minforth@arcor.de - 2017-04-06 04:05 -0700
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 06:50 -0500
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-06 05:23 -0400
Re: LLVM and Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-04-06 04:44 -0500
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 10:57 +0100
Re: LLVM and Forth peter.m.falth@gmail.com - 2017-04-05 05:29 -0700
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-14 02:04 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-15 14:03 +0200
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 00:44 +0000
Re: LLVM and Forth alex@rivadpm.com - 2017-04-16 05:53 -0700
Re: LLVM and Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 15:43 +0000
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 22:27 +0000
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-18 02:45 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-18 18:26 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 19:51 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 19:08 +0100
Re: LLVM and Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 20:42 +0200
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:29 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-20 20:48 +0100
Re: LLVM and Forth "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 11:49 +0000
Re: LLVM and Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-04-03 20:39 -0400
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-02 21:15 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-02 15:18 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 13:07 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 09:45 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 22:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-03 15:25 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:35 +0100
Re: LLVM and Forth antispam@math.uni.wroc.pl - 2017-04-06 01:36 +0000
Re: LLVM and Forth minforth@arcor.de - 2017-04-05 22:00 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 09:52 +0100
Re: LLVM and Forth hughaguilar96@gmail.com - 2017-04-06 20:15 -0700
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-03 05:20 -0700
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-03 17:11 +0100
Re: LLVM and Forth Alex <alex@rivadpm.com> - 2017-04-06 17:43 +0100
Re: LLVM and Forth krishna.myneni@ccreweb.org - 2017-04-06 10:53 -0700
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Spiros Bousbouras <spibou@gmail.com> |
|---|---|
| Date | 2017-04-08 22:48 +0000 |
| Message-ID | <qNdGA.352278$UY3.101949@fx11.am4> |
| In reply to | #56804 |
On Fri, 7 Apr 2017 03:33:09 -0400 Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote: > This post was intended for c.l.f. since the issues dealt with > comparison of Forth and C functionality. I've re-posted it here since > it made it to c.l.c. instead of c.l.f. Spiros redirected which was not > expected as I took note of the topic from a reply to him on c.l.f. ... I did say I set follow-up to comp.lang.c . > Hopefully, those on c.l.c. will not redirect their crap here. I'm not > even interested in seeing what type of shit those idiots posted in > response. It's a pity you're not interested because they corrected your numerous mistakes.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-04-09 15:06 -0400 |
| Message-ID | <20170409150652.1664ede5@_> |
| In reply to | #56881 |
On Sat, 08 Apr 2017 22:48:54 GMT Spiros Bousbouras <spibou@gmail.com> wrote: > On Fri, 7 Apr 2017 03:33:09 -0400 > Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote: > > Hopefully, those on c.l.c. will not redirect their crap here. I'm > > not even interested in seeing what type of shit those idiots posted > > in response. > > It's a pity you're not interested because they corrected your > numerous mistakes. No, it's a pity that you've attempted to discredit me or anger me, instead of learning something. I used to post comp.lang.c a decade ago. Weren't you there then? I seem to recall your name. What I posted is either directly from the C specifications, the C Rationale, Harbison and Steele's "C: A Reference Manual" or P.J. Plauger's "The Standard C Library", or papers by D.M. Ritchie et.al., or historical behavior. I also know that my understanding of C corresponds with that of one of the original ANSI C committee members (not P.J. Plauger), as I've had conversations with this other fellow. I've been programming since 1981, about 1992 for C. So, yeah, since I posted to c.l.c. in the past, I know how c.l.c. works or did. A few self-proclaimed C experts, like Richard Heathfield or Keith Thompson and their clique, e.g., CBFalconer RIP **PLONK**, beat up other people in an attempt to prove themselves correct by harassing innocent newbs. At that time, Keith knew the C specification well, but didn't understand C itself or how it was compiled. The authors of the failed c.l.c. book "C Unleashed" attempted to prove themselves correct too on occasion. No one there was familiar with the Bell Laboratories papers on C by D.M. Ritchie, B.W. Kernighan, and S.C. Johnson which explained low-level details of how C works. None of them had read ANSI's or ISO's "The C Rationale" and everyone dismissed it. No one there understood that a nul character can be larger in size that a char even though DMR wrote about it in his papers as to why the C specification required it. No one there was familiar with the ANSI C committee's TC's that obsoleted implicit ints due to conflicts with typedef's or that C was no longer an LALR(1) grammar because of typedef's and the implicit int conflict. Many of them would site Steve Summit's C FAQ which had some major errors at the time which have since been corrected. Everyone there complains about some unknown C author by the name of Schildt. People harass Heathfield by asking the same questions over and over because he can't remember anything for more than a few months. AIR, there were only two people there besides me who truly understood C, but they were infrequent posters. One of them might have been Chris Torek ... Perhaps, the other was David Tribble? Or, Eric Sosman? Sorry, I don't recall the other person's name anymore. I'd have to re-read a bunch of posts from the era. Of course, I'm not really interested in rereading the posts from all the assholes, CBFalconer, Flash Gordon, Martin Ambuhl, Mark McIntyre, Keith Thompson, Richard Heathfield, ... Nor am I interested in reading any posts from the current batch of them. There was only one person there who was funny from time to time, Kenny McCormack. Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-04-08 22:45 -0700 |
| Message-ID | <b8b4e62a-6b68-4149-9178-4ab42eda105c@googlegroups.com> |
| In reply to | #56804 |
On Friday, April 7, 2017 at 4:32:11 PM UTC+9, Rod Pemberton wrote:
> On Thu, 06 Apr 2017 12:33:44 GMT
> Spiros Bousbouras <spibou@(something).(something)> wrote:
>
>
> [...]
> > Example : the expression array[i] where i is beyond the end of the
> > array.
>
> FYI, C explicitly allows you to access one element past the end of the
> array. This is to allow you to access the nul character when comparing
> strings to check for string termination.
Now we know who has been writing all that vulnerable code. (Just kidding. Sort of.)
I have heard teachers say that setting a pointer to NULL and then dereferencing it is safe.
(There are, in fact, some embedded environments where it is safe, but those are special cases. Still not what I call clean coding practice.)
C array syntax allows you to access whatever a point points at, and pointer parameters can be named as if they were indefinitely allocated arrays. Moreover, the grammar specifically allows arbitrary array references even when the l-value is an array with a specific declared size.
In the past, certain compiler vendors allocated extra space around arrays to "help protect" the end users from programmers who did not understand that C does not bounds check arrays, and therefore assumed that no breakage this time meant their loops or other array processing was correct. This would give the appearance of allowing dereferencing one past the end of an array.
It also allowed programmers to get thoroughly confused when they started working with multi-dimension arrays, because the compiler and libraries can't cheat like that for you on multi-dimension arrays.
If you read, for instance, the library documentation for string processing functions in the standard library (fgets(), for instance), you will note that the buffer size passed in must include room for a trailing NUL if you want to be sure the trailing NUL gets stored.
This kind of thing should help you understand that something doesn't match what you just said.
The standard does specify that the run-time has to allow a pointer to point one past the end of an allocated area, as long as the pointer is not dereferenced in that state. This allows a loop that has a post-increment in the test to complete safely.
But that means, no, you must not actually access one beyond. That way lies one-off pointer errors which become vulnerabilities which allow servers and workstations to be pwned by malicious access.
> If you go beyond that though,
> it's undefined ... However, many C implementations use the ability to
> access outside a C object behind the scenes without any issues, e.g.,
> to access a memory header prior to malloc'd memory blocks.
When you talk about memory allocation headers, you imply two levels (at least) of allocation -- a mass block allocation, and a fine-grain allocation.
If you try to access beyond either end of a mass block allocation, you should expect segment faults.
Within a mass block, the library maintains an allocation list of some sort, and that list might use headers that sit either edge of the fine-grained allocation block. The grammar and syntax do allow you to take a look at those headers, but you really should not, because other library architects don't want to risk allocation headers being overwritten by stray pointers. So the allocation lists are elsewhere in those runt-times.
The grammar and syntax allow the accesses, and it is not just one past. A million past is also allowed by the grammar and syntax. The run-time, however, is only required to complete an operation safely if it is within the declared bounds.
> > Thinking in terms of assembly : "array[i] will be translated into an
> > assembly instruction which calculates an address of the form base +
> > i * constant .
>
> This is a requirement of the subscript operator [] for K&R, ANSI, and
> ISO C.
Not really required, just the most natural interpretation of a one-dimensional array reference.
> It's in all the standards. They define "E1[E2]" to be
> equivalent to "*((E1)+(E2))". The subscript operator takes a pointer
> to a type and also an index. The index is scaled by the size of the
> data type pointed to. The pointer which cannot be a pointer-to-void
> 'void *' since 'void' has no data type, i.e., no size, pointer only.
> The pointer used in the subscript operator can be any pointer to any
> valid type, not just pointer for array types.
Up to here you are just talking about arbitrary math.
> The arguments to the
> subscript operator can be either order, e.g., "0123456789"[i] is
> equivalent to i["0123456789"] .
This does not make sense. I know what "string"[index] means, but I and the compiler are both extremely puzzled by index["string"]. This is not perl. "string" may resolve to a pointer, but pointers and indexes have two different sorts of existence, which you refer to when you mention void pointers. You can't use a pointer as an index very meaningfully.
> Technically, you should think of the
> subscript operator as just the left-brace, then you'll understand it's
> like any other operator in C, e.g., arithmetic +, -> component
> selection, or whatever.
Syntactically similar, semantically significantly different.
> BTW, the other required equivalence is "E1->MOS" is equivalent to
> "(*E1).MOS". This is the equivalence between the two component
> selection operators . and ->
>
> > This will always point into some address in memory so
> > I should get some value or at least a segmentation fault ; so not a
> > totally unpredictable result."
>
> C's objects don't have bounds checks built in. It's not an
> object-oriented language. So, it's up to the programmer to make sure
> that they're within range.
>
> > Note first that not thinking in terms of C is more complicated and
> > requires more knowledge than thinking in terms of C. Second , if one
> > wants to think in terms of assembly then , from a practical point of
> > view , it makes sense to program in assembly , not C.
>
> Non sequitur.
>
> IMO, the key reasons to use C instead of assembly are the ability to
> use variables and the portability of the code. Even so, you need to
> understand how your code is converted to assembly or at least check the
> compiler output.
>
> > How are you going to implement for example
> > the Unix sort utility without using realloc() (depending on the
> > size of the input) ?
>
> I don't follow. I've never had to use realloc() for anything, ever.
> If you're manipulating large data sets in C, it's better to use files
> instead of memory.
>
> > Your second reference has
> > char *index;
> > ....
> > *index++ = toupper(*index);
> >
> > .He doesn't explain why he decided to write code like this as opposed
> > to *index = toupper(*index);
> > index++ ;
>
> I'm guessing that this is most likely just pre-ANSI C. Most C style
> guides etc are older and are for K&R C. E.g., most will recommend
> that you use #defines and mask with logical-and instead of using
> bit-fields, since many earlier C compilers were broken.
The implementation of toupper() is not really relevant to the semantics of
*index = toupper( *index++ );
demonstrates the need of sequence points. The assignment is a sequence point there is the assignment operator, "=".
++index is equivalent to index = index + 1 in several ways, but the increment does not contain a sequence point.
> They also
> recommend avoiding enums for similar reasons. They also recommend
> placing numbers in comparisons as "if(0==value)" instead of
> "if(value==0)" to detect incorrect assignments such as "if(value=0)".
> etc. They'll also say not to use the address of a struct by itself,
> i.e., as a pointer, since an early, widespread C compiler, PCC, didn't
> keep track of the struct's name or somesuch issue ... ANSI C added
> other problems, e.g., obsoleted implicit int's since they caused a
> syntax conflict with typedef's, messed up pre- and post- increment and
> decrement operators, etc. Of course, C has some required behavior,
> which is not part of some of the standards, such as the C struct hack
> and Duff's device, which must work correctly.
I'm finding the above too hard to parse. Try again?
> Rod Pemberton
> --
> All it takes for humanity to conquer the world's toughest problems
> is to hope, to believe, to share, and to do, in cooperation.
--
Joel Rees
http://reiisi.blogspot.jp/p/novels-i-am-writing.html
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2017-04-09 14:27 +0000 |
| Message-ID | <2017Apr9.162712@mips.complang.tuwien.ac.at> |
| In reply to | #56897 |
Joel Rees <joel.rees@gmail.com> writes:
>I have heard teachers say that setting a pointer to NULL and then dereferen=
>cing it is safe.=20
>
>(There are, in fact, some embedded environments where it is safe, but those=
> are special cases. Still not what I call clean coding practice.)
The problem is that nasal-demon-C compilers "optimize" this
irrespective of the environment for which the program is compiled.
BTW, looking at point 1 of
<http://catb.org/jargon/html/V/vaxocentrism.html>, environments were
this was safe used to be very common once upon a time. Of course,
most user-level programs probably have been compiled and (tried to)
run on systems where dereferencing a null pointer causes a SIGSEGV, so
that practice is probably pretty uncommon these days. However, the
Linux kernel is an environment where it does not cause an exception,
and where it is used for good purposes, and which is miscompiled by
gcc unless you tell it not to (at least in this case there is a flag
for telling it not to).
>> The arguments to the
>> subscript operator can be either order, e.g., "0123456789"[i] is
>> equivalent to i["0123456789"] .
>
>This does not make sense. I know what "string"[index] means, but I and the =
>compiler are both extremely puzzled by index["string"].
Obviously you. But not the compiler:
[/tmp:93578] cat xxx.c
#include <stdio.h>
int main()
{
printf("%c\n",5["abcdefghijk"]);
return 0;
}
[/tmp:93579] gcc -Wall -O xxx.c
[/tmp:93580] a.out
f
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Joel Rees <joel.rees@gmail.com> |
|---|---|
| Date | 2017-04-09 21:26 -0700 |
| Message-ID | <15cda640-f439-42c0-9b66-6c35ddf500ea@googlegroups.com> |
| In reply to | #56931 |
On Sunday, April 9, 2017 at 11:43:35 PM UTC+9, Anton Ertl wrote:
> Joel Rees <joel.rees@gmail.com> writes:
> >I have heard teachers say that setting a pointer to NULL and then dereferen=
> >cing it is safe.=20
> >
> >(There are, in fact, some embedded environments where it is safe, but those=
> > are special cases. Still not what I call clean coding practice.)
>
> The problem is that nasal-demon-C compilers "optimize" this
> irrespective of the environment for which the program is compiled.
I think I'd say that the problem is that gcc has been taken over by engineers who seem to define their self-worth by the number of winged monkeys they can breath through their noses.
Engineers being paid to work on open source stuff and having to justify their pay, I suppose.
I think we wouldn't mind if they would fork the thing first, and keep the projects separate. That would not be a problem, because some of the new work would be useful if it could be separated out.
(At least there was something new the compiler did that was related to this stuff, that I thought was useful a couple of days ago. Don't remember what it was, though.)
Considering how the systemd thing was pushed into all the major distros without a fork, the problem is not just with compilers.
> Of course,
> most user-level programs probably have been compiled and (tried to)
> run on systems where dereferencing a null pointer causes a SIGSEGV, so
> that practice is probably pretty uncommon these days. However, the
> Linux kernel is an environment where it does not cause an exception,
> and where it is used for good purposes,
Good purposes?
Integers in general I can understand. It's important to be able to access real hardware ports by actual addresses. But NULL?
I'm all ears.
(I've always leaned towards wanting the bottom of memory to segfault to help catch dereferenced small integers, even in embedded. Except, yeah, programming something like the 6800 in C, if the bottom 256 bytes were mapped to interrupt the CPU, we'd lose a significant part of the instruction set.)
> and which is miscompiled by
> gcc unless you tell it not to (at least in this case there is a flag
> for telling it not to).
>
> >> The arguments to the
> >> subscript operator can be either order, e.g., "0123456789"[i] is
> >> equivalent to i["0123456789"] .
> >
> >This does not make sense. I know what "string"[index] means, but I and the =
> >compiler are both extremely puzzled by index["string"].
>
> Obviously you. But not the compiler:
>
> [/tmp:93578] cat xxx.c
> #include <stdio.h>
> int main()
> {
> printf("%c\n",5["abcdefghijk"]);
> return 0;
> }
> [/tmp:93579] gcc -Wall -O xxx.c
> [/tmp:93580] a.out
> f
Yes, I'd forgotten that is one of those archetypical ways to demonstrate how pointers are integers in C.
Considering how most commercial vendor supplied assemblers take great pains to not allow you to subtract an address from an integer, and the C compiler itself will try to stop you from indexing an array, rather than an integer, by a pointer, ... hmmm
----------------
#include <stdio.h>
char thing[] = { 'a', 'b', 'c', 'd', 'e', 'f' };
unsigned long three = 3;
int main( int argc, char * argv[] )
{
printf( "abcdef[3] == %c, %d\n", "abcdef"[3], "abcdef"[3] );
printf( "3[\"abcdef\"] == %c, %d\n", 3["abcdef"], 3["abcdef"] );
/* printf( "\"abcdef\"[\"abcdef\"] == %c, %d\n", "abcdefg"["abcdef"], "abcdef"["abcdefg"] ); */
/* printf( "thing[abcdef] == %c, %d\n", thing["abcdef"], thing["abcdefg"] );*/
/* printf( "\"abcdef\"[thing] == %c, %d\n", "abcdefg"[thing], "abcdef"[thing] );*/
printf( "thing[3] == %c, %d\n", thing[3], thing[3] );
printf( "3[thing] == %c, %d\n", 3[thing], 3[thing] );
printf( "thing[three] == %c, %d\n", thing[three], thing[three] );
printf( "three[thing] == %c, %d\n", three[thing], three[thing] );
/* printf( "((char *)0)[0] == %c, %d\n", ((char *)0)[0], ((char *)0)[0] ); */
/* printf( "0[(char *)0] == %c, %d\n", 0[(char *)0], 0[(char *)0] ); */
/* printf( "((char *)8)[8] == %c, %d\n", ((char *)8)[8], ((char *)8)[8] ); */
/* printf( "8[(char *)8] == %c, %d\n", 8[(char *)8], 8[(char *)8] ); */
/* three = * (unsigned long *) 0; */
/* three = * (unsigned long *) NULL; */
three = (unsigned long) thing;
/* printf( "thinged: thing[three] == %c, %d\n", thing[three], thing[three] );*/
/* printf( "thinged: three[thing] == %c, %d\n", three[thing], three[thing] );*/
return 0;
}
----------------
Hmmm.
> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> New standard: http://www.forth200x.org/forth200x.html
> EuroForth 2016: http://www.euroforth.org/ef16/
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-04-09 13:35 -0400 |
| Message-ID | <20170409133515.2b871c2c@_> |
| In reply to | #56897 |
On Sat, 8 Apr 2017 22:45:51 -0700 (PDT) Joel Rees <joel.rees@gmail.com> wrote: > On Friday, April 7, 2017 at 4:32:11 PM UTC+9, Rod Pemberton wrote: > > On Thu, 06 Apr 2017 12:33:44 GMT > > Spiros Bousbouras <spibou@(something).(something)> wrote: > > > Example : the expression array[i] where i is beyond the end of > > > the array. > > > > FYI, C explicitly allows you to access one element past the end of > > the array. This is to allow you to access the nul character when > > comparing strings to check for string termination. > > Now we know who has been writing all that vulnerable code. (Just > kidding. Sort of.) This is used within the C libraries, e.g., string and memory functions, as well as by programmers. > I have heard teachers say that setting a pointer to NULL and then > dereferencing it is safe. Setting a pointer to any explicit value is undefined behavior in C. This is implementation defined behavior. Most OSes and resulting C compilers are reasonable in that they allow the programmer to access memory mapped devices. Hence, they allow you to assign values to pointers. > (There are, in fact, some embedded environments where it is safe, but > those are special cases. Still not what I call clean coding practice.) In many OS environments, you'll end up with a page fault. The OS will not map the zero'th page in order to detect NULL pointer dereferences. > C array syntax allows you to access whatever a [pointer] points at, > and pointer parameters can be named as if they were indefinitely > allocated arrays. Moreover, the grammar specifically allows arbitrary > array references even when the l-value is an array with a specific > declared size. I'm not sure I quite follow here. The C language has array declarations, but doesn't have arrays as a fundamental type as part of the language. C uses the [] subscript operator with a pointer and offset to effect array usage. The name of an array reduces to a pointer to the zero'th element of the array. This allows the array name to be used with the subscript operator. > In the past, certain compiler vendors allocated extra space around > arrays to "help protect" the end users from programmers who did not > understand that C does not bounds check arrays, and therefore assumed > that no breakage this time meant their loops or other array > processing was correct. This would give the appearance of allowing > dereferencing one past the end of an array. C explicitly allows dereferencing one past the end of an array. As stated previously, this requirement is in ALL of the C specifications. > It also allowed programmers to get thoroughly confused when they > started working with multi-dimension arrays, because the compiler and > libraries can't cheat like that for you on multi-dimension arrays. ... > If you read, for instance, the library documentation for string > processing functions in the standard library (fgets(), for instance), > you will note that the buffer size passed in must include room for a > trailing NUL if you want to be sure the trailing NUL gets stored. > > This kind of thing should help you understand that something doesn't > match what you just said. You're confusing strings and arrays. C doesn't have strings as a fundamental type, but uses arrays, which are a partial type. Part of the parsing process of C requires that an extra character for nul be added onto the end of the string. This is done automatically by the compiler unless a specific size is declared for the string. In the case of fgets(), the programmer must account for the extra character needed to terminate strings. > The standard does specify that the run-time has to allow a pointer to > point one past the end of an allocated area, as long as the pointer > is not dereferenced in that state. This allows a loop that has a > post-increment in the test to complete safely. ... > But that means, no, you must not actually access one beyond. That way > lies one-off pointer errors which become vulnerabilities which allow > servers and workstations to be pwned by malicious access. Accessing one beyond is required to check for a nul character. E.g., while(*str++); /* find end-of-string *//* This is not UB */ > > If you go beyond that though, > > it's undefined ... However, many C implementations use the ability > > to access outside a C object behind the scenes without any issues, > > e.g., to access a memory header prior to malloc'd memory blocks. > > When you talk about memory allocation headers, you imply two levels > (at least) of allocation -- a mass block allocation, and a fine-grain > allocation. It doesn't imply that. The memory block and header can be allocated at once. > If you try to access beyond either end of a mass block allocation, > you should expect segment faults. This assumes that paging is enabled and memory isn't contiguously mapped. The later is an implicit requirement of C. Every C object is required to be contiguous. This is usually effected by making memory contiguously mapped. > Within a mass block, the library maintains an allocation list of some > sort, and that list might use headers that sit either edge of the > fine-grained allocation block. The grammar and syntax do allow you to > take a look at those headers, but you really should not, because > other library architects don't want to risk allocation headers being > overwritten by stray pointers. So the allocation lists are elsewhere > in those runt-times. ... > The grammar and syntax allow the accesses, and it is not just one > past. A million past is also allowed by the grammar and syntax. The > run-time, however, is only required to complete an operation safely > if it is within the declared bounds. This is not true. For C, you can legally only access data within C objects or malloc'd memory. Any other access is undefined behavior. C makes an exception for strings to allow accessing one past the end-of-string to check for nul characters. Assigning a value directly to a pointer is also undefined behavior for C. Many environments allow this to access memory mapped devices. > > > Thinking in terms of assembly : "array[i] will be translated into > > > an assembly instruction which calculates an address of the form > > > base + i * constant . > > > > This is a requirement of the subscript operator [] for K&R, ANSI, > > and ISO C. > > Not really required, just the most natural interpretation of a > one-dimensional array reference. > > > It's in all the standards. They define "E1[E2]" to be > > equivalent to "*((E1)+(E2))". The subscript operator takes a > > pointer to a type and also an index. The index is scaled by the > > size of the data type pointed to. The pointer which cannot be a > > pointer-to-void 'void *' since 'void' has no data type, i.e., no > > size, pointer only. The pointer used in the subscript operator can > > be any pointer to any valid type, not just pointer for array > > types. > > Up to here you are just talking about arbitrary math. No, I'm talking about how the subscript operator [] in C works. Most people think it's for array indexes (or indices), but it works with pointers too. C doesn't have arrays within the language itself, but has array declarations. These are reduced to pointers by the compiler, as mentioned elsewhere. > > The arguments to the > > subscript operator can be either order, e.g., "0123456789"[i] is > > equivalent to i["0123456789"] . > > This does not make sense. I know what "string"[index] means, but I > and the compiler are both extremely puzzled by index["string"]. This > is not perl. "string" may resolve to a pointer, but pointers and > indexes have two different sorts of existence, which you refer to > when you mention void pointers. You can't use a pointer as an index > very meaningfully. This is valid C. The compiler knows the type of both parameters for the subscript operator [] . The compiler knows that the string is a pointer to char and it knows the index is one of the integer types. > > Technically, you should think of the > > subscript operator as just the left-brace, then you'll understand > > it's like any other operator in C, e.g., arithmetic +, -> component > > selection, or whatever. > > Syntactically similar, semantically significantly different. > ... > > > Your second reference has > > > char *index; > > > .... > > > *index++ = toupper(*index); > > > > > > .He doesn't explain why he decided to write code like this as > > > opposed to *index = toupper(*index); > > > index++ ; > > > > I'm guessing that this is most likely just pre-ANSI C. Most C style > > guides etc are older and are for K&R C. E.g., most will recommend > > that you use #defines and mask with logical-and instead of using > > bit-fields, since many earlier C compilers were broken. > > The implementation of toupper() is not really relevant to the > semantics of > > *index = toupper( *index++ ); > > demonstrates the need of sequence points. The assignment is a > sequence point there is the assignment operator, "=". > > ++index is equivalent to index = index + 1 in several ways, but the > increment does not contain a sequence point. > It indicates the author didn't follow ANSI C coding rules which require that pre- and post- increment and pre- and post-decrement be removed from surrounding code. This is because they introduced sequence point concept with ANSI C and broke the expected order of operations. > > They also > > recommend avoiding enums for similar reasons. They also recommend > > placing numbers in comparisons as "if(0==value)" instead of > > "if(value==0)" to detect incorrect assignments such as > > "if(value=0)". etc. They'll also say not to use the address of a > > struct by itself, i.e., as a pointer, since an early, widespread C > > compiler, PCC, didn't keep track of the struct's name or somesuch > > issue ... ANSI C added other problems, e.g., obsoleted implicit > > int's since they caused a syntax conflict with typedef's, messed up > > pre- and post- increment and decrement operators, etc. Of course, > > C has some required behavior, which is not part of some of the > > standards, such as the C struct hack and Duff's device, which must > > work correctly. > > I'm finding the above too hard to parse. Try again? > The point was there are a variety of things recommended by C style guidelines due problems with C compilers. Also, some required C behavior is not required by the specifications. Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-04-09 14:07 -0700 |
| Message-ID | <87r3118f3q.fsf@nightsong.com> |
| In reply to | #56940 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> writes: > C explicitly allows dereferencing one past the end of an array. As > stated previously, this requirement is in ALL of the C specifications. I don't think that is right. My understanding was you're allowed to set a pointer to point one past the end of the array, but you're not allowed to dereference that pointer. http://stackoverflow.com/questions/988158/take-the-address-of-a-one-past-the-end-array-element-via-subscript-legal-by-the discusses this at some length. > Accessing one beyond is required to check for a nul character. E.g., > while(*str++); /* find end-of-string *//* This is not UB */ The nul character is supposed to be within the array, not past it. After the exit from that loop, str points one past the end of the array, which is not UB, since you don't actually dereference it. Dereferencing it would be UB according to everything I remember.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-05 12:16 -0700 |
| Message-ID | <8b14b743-b9c9-4e88-96bd-b50d5b7c7844@googlegroups.com> |
| In reply to | #56746 |
Am Mittwoch, 5. April 2017 17:47:53 UTC+2 schrieb krishna...@ccreweb.org: > On Wednesday, April 5, 2017 at 2:00:45 AM UTC-5, minf...@arcor.de wrote: > ... > > C and Assembler are well suited to shoot one's own foot. But that does not imply that you have to protect the shootist. Forth is full of unspecified corners as well. No reason for language talibanism. > > You miss an important distinction between C and assembler -- the ability to predict the actual instructions executed by the processor and the order in which they are executed. One can look at assembly language code and predict exactly which machine instructions will be executed and in what order. That ability is gone with optimized C compilers which are given license to eliminate and/or reorder source code instructions during compilation. C is very different from assembly language in this sense. With Forth, because of its stack-based nature, I think the predictability of run-time execution of source code is much higher than it is for C, but perhaps I'm wrong on this point. > > Incidentally, I always compile my Forth system, written in a mix of C++, C, and assembly language, at the lowest optimization level (-O0) for the C and C++ source files. The assembler of course has no optimization settings (of which I'm aware). The speed of my system is largely independent of the C/C++ compiler optimization anyway since the bulk of the dictionary is implemented in assembly code. > > Krishna Using -O0 on an optimizing compiler is certainly a good way to reduce optimization bugs. ;-) OTOH with one assembler you are stuck to one processor, you lose portability. Luckily most CPU vendors follow down-compatibility between CPU generations, notably then x86 line since the 90s. But as others have pointed out even then you don't always get the same opcodes and of course different cycle timings. Things get even worse when you have to transcode between different non-compatible CPUs. So I don't follow your argument that assembler coding will generate more predictable results.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-05 20:27 -0700 |
| Message-ID | <27f455fd-d0fa-4dab-be77-bbef61adc1b4@googlegroups.com> |
| In reply to | #56760 |
On Wednesday, April 5, 2017 at 2:16:26 PM UTC-5, minf...@arcor.de wrote: ... > Using -O0 on an optimizing compiler is certainly a good way to reduce optimization bugs. ;-) OTOH with one assembler you are stuck to one processor, you lose portability. True. That's one of the drawbacks of assembly language, that you're tied to one set of instructions. > Luckily most CPU vendors follow down-compatibility between CPU generations, notably then x86 line since the 90s. But as others have pointed out even then you don't always get the same opcodes and of course different cycle timings. Predictability at the clock cycle level is not achievable unless all hardware and software interrupts are disabled. However, predictability of the executed instruction sequence, or being able to simulate it just from knowing the assembler source, without regard to the implementation of the assembler is far more probable than for C source code, without knowing about the C compiler implementation. > Things get even worse when you have to transcode between different non-compatible CPUs. So I don't follow your argument that assembler coding will generate more predictable results. Please see my response to Andrew above. Krishna
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-04-06 05:24 -0400 |
| Message-ID | <20170406052411.31813b57@_> |
| In reply to | #56746 |
On Wed, 5 Apr 2017 08:47:51 -0700 (PDT) krishna.myneni@ccreweb.org wrote: > On Wednesday, April 5, 2017 at 2:00:45 AM UTC-5, minf...@arcor.de > wrote: ... >> C and Assembler are well suited to shoot one's own foot. But that >> does not imply that you have to protect the shootist. Forth is full >> of unspecified corners as well. No reason for language talibanism. > > You miss an important distinction between C and assembler -- the > ability to predict the actual instructions executed by the processor > and the order in which they are executed. One can look at assembly > language code and predict exactly which machine instructions will be > executed and in what order. That ability is gone with optimized C > compilers which are given license to eliminate and/or reorder source > code instructions during compilation. C is very different from > assembly language in this sense. With Forth, because of its > stack-based nature, I think the predictability of run-time execution > of source code is much higher than it is for C, but perhaps I'm wrong > on this point. > > Incidentally, I always compile my Forth system, written in a mix of > C++, C, and assembly language, at the lowest optimization level (-O0) > for the C and C++ source files. The assembler of course has no > optimization settings (of which I'm aware). The speed of my system is > largely independent of the C/C++ compiler optimization anyway since > the bulk of the dictionary is implemented in assembly code. > Of course, you use -O0 with GCC specifically because doing so allows you to "predict the actual instructions executed by the processor and the order in which they are executed." Correct? So, if you can disable assembly optimizations for C and the result is approximately the expected one-to-one translation of C to assembly, does the aforementioned important distinction between C and assembler actually exist? ... Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | krishna.myneni@ccreweb.org |
|---|---|
| Date | 2017-04-06 03:26 -0700 |
| Message-ID | <ff5ea6de-fdf6-4423-a5d6-d3d0e6fcb4ae@googlegroups.com> |
| In reply to | #56775 |
On Thursday, April 6, 2017 at 4:23:11 AM UTC-5, Rod Pemberton wrote: > On Wed, 5 Apr 2017 08:47:51 -0700 (PDT) > krishna.myneni@ccreweb.org wrote: > ... > > One can look at assembly > > language code and predict exactly which machine instructions will be > > executed and in what order. That ability is gone with optimized C > > compilers which are given license to eliminate and/or reorder source > > code instructions during compilation. C is very different from > > assembly language in this sense. With Forth, because of its > > stack-based nature, I think the predictability of run-time execution > > of source code is much higher than it is for C, but perhaps I'm wrong > > on this point. > > > > Incidentally, I always compile my Forth system, written in a mix of > > C++, C, and assembly language, at the lowest optimization level (-O0) > > for the C and C++ source files. The assembler of course has no > > optimization settings (of which I'm aware). The speed of my system is > > largely independent of the C/C++ compiler optimization anyway since > > the bulk of the dictionary is implemented in assembly code. > > > > Of course, you use -O0 with GCC specifically because doing so allows > you to "predict the actual instructions executed by the processor and > the order in which they are executed." Correct? So, if you can > disable assembly optimizations for C and the result is approximately > the expected one-to-one translation of C to assembly, does the > aforementioned important distinction between C and assembler actually > exist? ... > Yes, the distinction still exists at the source code level comparison. With no optimizations for the C compiler (-O0), you have a better chance of obtaining object code that maps well to your source without omission or resequencing. But it is still not guaranteed because of cases where the C source is considered undefined behavior in the standard. Then, the C compiler can compile any damn thing it wants into the object code. The -Wall flag at least gives one a chance to see if the C compiler detects undefined behavior, but the compiler is not required to report anything, and possibly might not be able to when the optimizer is turned on. When I write C code, I don't want to play chess with the compiler. I want it to compile what I ask it to compile, or tell me there's a problem. With optimizations, the compiler is substituting it's judgement about the need for the code, and the order in which execution happens, over your judgement. An assembler will compile assembly source code with exactly the instructions you wrote in the source. No nasal demons. Your assembly code may not make any sense, and might result in a processor exception -- the assembler can't check for that.
[toc] | [prev] | [next] | [standalone]
| From | minforth@arcor.de |
|---|---|
| Date | 2017-04-06 04:05 -0700 |
| Message-ID | <1f58e0bb-2e1f-4a6e-bdff-931c0028971a@googlegroups.com> |
| In reply to | #56779 |
Am Donnerstag, 6. April 2017 12:26:40 UTC+2 schrieb krishna...@ccreweb.org: > On Thursday, April 6, 2017 at 4:23:11 AM UTC-5, Rod Pemberton wrote: > > On Wed, 5 Apr 2017 08:47:51 -0700 (PDT) > > krishna.myneni@ccreweb.org wrote: > > > ... > > > One can look at assembly > > > language code and predict exactly which machine instructions will be > > > executed and in what order. That ability is gone with optimized C > > > compilers which are given license to eliminate and/or reorder source > > > code instructions during compilation. C is very different from > > > assembly language in this sense. With Forth, because of its > > > stack-based nature, I think the predictability of run-time execution > > > of source code is much higher than it is for C, but perhaps I'm wrong > > > on this point. > > > > > > Incidentally, I always compile my Forth system, written in a mix of > > > C++, C, and assembly language, at the lowest optimization level (-O0) > > > for the C and C++ source files. The assembler of course has no > > > optimization settings (of which I'm aware). The speed of my system is > > > largely independent of the C/C++ compiler optimization anyway since > > > the bulk of the dictionary is implemented in assembly code. > > > > > > > Of course, you use -O0 with GCC specifically because doing so allows > > you to "predict the actual instructions executed by the processor and > > the order in which they are executed." Correct? So, if you can > > disable assembly optimizations for C and the result is approximately > > the expected one-to-one translation of C to assembly, does the > > aforementioned important distinction between C and assembler actually > > exist? ... > > > > Yes, the distinction still exists at the source code level comparison. With no optimizations for the C compiler (-O0), you have a better chance of obtaining object code that maps well to your source without omission or resequencing. But it is still not guaranteed because of cases where the C source is considered undefined behavior in the standard. Then, the C compiler can compile any damn thing it wants into the object code. The -Wall flag at least gives one a chance to see if the C compiler detects undefined behavior, but the compiler is not required to report anything, and possibly might not be able to when the optimizer is turned on. > > When I write C code, I don't want to play chess with the compiler. I want it to compile what I ask it to compile, or tell me there's a problem. With optimizations, the compiler is substituting it's judgement about the need for the code, and the order in which execution happens, over your judgement. An assembler will compile assembly source code with exactly the instructions you wrote in the source. No nasal demons. Your assembly code may not make any sense, and might result in a processor exception -- the assembler can't check for that. Good that we are not talking about optimising Forth compilers. ;-)))
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-06 06:50 -0500 |
| Message-ID | <oomdnZIZK7bytnvFnZ2dnUU7-LOdnZ2d@supernews.com> |
| In reply to | #56780 |
minforth@arcor.de wrote: > Good that we are not talking about optimising Forth compilers. ;-))) They exist, and some are pretty good. What's not to like? Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> |
|---|---|
| Date | 2017-04-06 05:23 -0400 |
| Message-ID | <20170406052326.24bb3082@_> |
| In reply to | #56740 |
On Wed, 5 Apr 2017 00:00:43 -0700 (PDT) minforth@arcor.de wrote: > So what the heck? Your contrived examples violate basic software > engineering rules to not write obscure code. My examples? Most were elsewhere in the thread, perhaps by Krishna. > C and Assembler are well suited to shoot one's own foot. Do they program robots in C or Assembly? They might use Forth for it's "real-time" capability ... So, you might be able to shoot your own foot, literally, with Forth, by using a robot. Rod Pemberton -- All it takes for humanity to conquer the world's toughest problems is to hope, to believe, to share, and to do, in cooperation.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2017-04-06 04:44 -0500 |
| Message-ID | <tt-dnScioLBikHvFnZ2dnUU7-fWdnZ2d@supernews.com> |
| In reply to | #56774 |
Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote: > > Do they program robots in C or Assembly? They might use Forth for > it's "real-time" capability ... So, you might be able to shoot your > own foot, literally, with Forth, by using a robot. Probably. I have worked on a system which had the property where if I made a mistake in the control software, boiling water was thrown across the room. That concentrated the mind, I can tell you. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Alex <alex@rivadpm.com> |
|---|---|
| Date | 2017-04-06 10:57 +0100 |
| Message-ID | <oc539f$2u9$1@dont-email.me> |
| In reply to | #56776 |
On 4/6/2017 10:44, Andrew Haley wrote: > Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> wrote: >> >> Do they program robots in C or Assembly? They might use Forth for >> it's "real-time" capability ... So, you might be able to shoot your >> own foot, literally, with Forth, by using a robot. > > Probably. I have worked on a system which had the property where if I > made a mistake in the control software, boiling water was thrown > across the room. That concentrated the mind, I can tell you. > > Andrew. > I've had co-workers like that. -- Alex
[toc] | [prev] | [next] | [standalone]
| From | peter.m.falth@gmail.com |
|---|---|
| Date | 2017-04-05 05:29 -0700 |
| Message-ID | <0c35c99c-c6ee-425f-81c9-0513596125bb@googlegroups.com> |
| In reply to | #56739 |
On Wednesday, 5 April 2017 06:43:37 UTC+2, Rod Pemberton wrote: > On Tue, 4 Apr 2017 17:57:52 -0700 (PDT) > krishna.myneni@ccreweb.org wrote: > > > On Tuesday, April 4, 2017 at 8:37:46 AM UTC-5, Albert van der Horst > > wrote: > > > In article <72a319fa-8035-4a17-a5a2-2b2884a57b15@googlegroups.com>, > > > <krishna.myneni@ccreweb.org> wrote: > > > > Having a special action for 1+ is silly anyway. > > > The ++ operator is a remnance of the PDP11 era, there is not a shred > > > of a reason to use it in output for a translator. ... > > > > Isn't there an INC operation in x86? > > > > 16-bit. Yes. > 32-bit. Yes. > 64-bit. No. (It was reassigned for the REX prefix.) It works perfectly well also in 64 bit inc rax produces 48 FF C0 it is not a one byte opcode but it is still shorter then add rax, 1 that produces 48 83 C0 01 Peter > You can see this on Sandpile.org's "1 byte opcodes" page: > http://www.sandpile.org/x86/opc_1.htm > > Sandpile.org > "The world's leading source for technical x86 processor information." > http://www.sandpile.org/ > > > > Everyone using ++ or -- in the output of a Forth to C translator > > > is an idiot. > > >
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-04-14 02:04 +0000 |
| Message-ID | <xn0kopleodrop3000@nntp.aioe.org> |
| In reply to | #56739 |
Rod Pemberton wrote: > > Isn't there an INC operation in x86? > > > > 16-bit. Yes. > 32-bit. Yes. > 64-bit. No. (It was reassigned for the REX prefix.) There is still an INC in 64 bit mode. But it can't be used on r32 or r16 registers directly, because those opcodes are indeed reassigned. But you can still increment r/m8, r/m16, r/m32 and r/m64. -- Rudy Velthuis http://www.rvelthuis.de "A doctor can bury his mistakes but an architect can only advise his clients to plant vines." -- Frank Lloyd Wright (1868-1959)
[toc] | [prev] | [next] | [standalone]
| From | albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2017-04-15 14:03 +0200 |
| Message-ID | <oct279$van$1@cherry.spenarnc.xs4all.nl> |
| In reply to | #57266 |
In article <xn0kopleodrop3000@nntp.aioe.org>, Rudy Velthuis <newsgroups@rvelthuis.de> wrote: >Rod Pemberton wrote: > >> > Isn't there an INC operation in x86? >> > >> >> 16-bit. Yes. >> 32-bit. Yes. >> 64-bit. No. (It was reassigned for the REX prefix.) > >There is still an INC in 64 bit mode. But it can't be used on r32 or >r16 registers directly, because those opcodes are indeed reassigned. >But you can still increment r/m8, r/m16, r/m32 and r/m64. And then there is "add immediate" and a slew of load effective address tricks. These are all INC operations, only one(!) of the INC *instructions* is missing. You may never notice that the INC Rod refers too is missing, because an assembler may substitute one of the alternatives with the same effect, without telling. >-- >Rudy Velthuis http://www.rvelthuis.de Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Rudy Velthuis" <newsgroups@rvelthuis.de> |
|---|---|
| Date | 2017-04-16 00:44 +0000 |
| Message-ID | <xn0koscck33ybit003@nntp.aioe.org> |
| In reply to | #57366 |
Albert van der Horst wrote: > In article <xn0kopleodrop3000@nntp.aioe.org>, > Rudy Velthuis <newsgroups@rvelthuis.de> wrote: > > Rod Pemberton wrote: > > > >> > Isn't there an INC operation in x86? > >> > > > > > >> 16-bit. Yes. > >> 32-bit. Yes. > >> 64-bit. No. (It was reassigned for the REX prefix.) > > > > There is still an INC in 64 bit mode. But it can't be used on r32 or > > r16 registers directly, because those opcodes are indeed reassigned. > > But you can still increment r/m8, r/m16, r/m32 and r/m64. > > And then there is "add immediate" and a slew of > load effective address tricks. These are all INC operations, > only one(!) of the INC instructions is missing. > > You may never notice that the INC Rod refers too is missing, > because an assembler may substitute one of the alternatives > with the same effect, without telling. Indeed. The single-opcode version is missing, that is all. There is still an INC instruction. -- Rudy Velthuis http://www.rvelthuis.de "One death is a tragedy. A million deaths is a statistic." -- Josef Stalin
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.forth
csiph-web