Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #26180 > unrolled thread
| Started by | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| First post | 2017-03-23 18:17 -0500 |
| Last post | 2017-03-26 14:43 +0200 |
| Articles | 20 on this page of 64 — 13 participants |
Back to article view | Back to comp.arch.embedded
Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-23 18:17 -0500
Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-23 23:21 -0700
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-24 09:18 +0100
Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-24 18:24 +0000
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-24 19:32 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Stefan Reuther <stefan.news@arcor.de> - 2017-03-25 09:59 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:08 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-25 01:57 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Clifford Heath <no.spam@please.net> - 2017-03-25 18:34 +1100
Re: Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-26 23:53 +0000
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-27 09:51 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Clifford Heath <no.spam@please.net> - 2017-03-27 20:19 +1100
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-27 12:17 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-25 09:20 -0700
Re: Type-safety and C++, was: Re: Dimension of a matrix George Neuner <gneuner2@comcast.net> - 2017-03-24 23:14 -0400
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-25 11:07 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix George Neuner <gneuner2@comcast.net> - 2017-03-26 05:45 -0400
Re: Type-safety and C++, was: Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-26 13:14 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-26 11:08 -0700
Re: Type-safety and C++, was: Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-26 20:24 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-26 15:16 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-27 00:09 +0000
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-26 19:43 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-27 16:57 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-27 11:53 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-27 22:04 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-27 18:32 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Clifford Heath <no.spam@please.net> - 2017-03-28 11:03 +1100
Re: Type-safety and C++, was: Re: Dimension of a matrix Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-27 22:07 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-27 23:42 -0700
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-28 09:22 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-28 00:42 -0700
Re: Type-safety and C++, was: Re: Dimension of a matrix Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-28 09:07 +0100
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-28 19:34 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-29 11:39 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-28 19:29 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-29 10:31 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-30 00:23 +0000
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-29 19:31 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix Phil Martel <pomartel@comcast.net> - 2017-03-30 11:51 -0400
Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-30 19:16 -0500
Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-31 09:21 +0200
Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-28 14:19 -0500
Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-24 11:05 -0500
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-24 17:33 +0100
Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-24 12:09 -0500
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:09 -0500
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:05 -0500
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-24 09:20 +0100
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:12 -0500
Re: Dimension of a matrix Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-25 20:08 +0100
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:17 -0500
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-26 17:32 +0200
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-26 11:55 -0500
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-26 21:23 +0200
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-29 19:36 -0500
Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-30 00:36 +0000
Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-29 19:55 -0700
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-30 09:49 +0200
Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-30 18:07 +0000
Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-30 09:47 +0200
Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-25 19:08 +0100
Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:21 -0500
Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-26 14:43 +0200
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-30 19:16 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <obk6mq$avt$1@dont-email.me> |
| In reply to | #26350 |
Phil Martel wrote: > On 3/29/2017 20:31, Les Cargill wrote: >> David Brown wrote: >>> On 29/03/17 02:29, Les Cargill wrote: >>>> David Brown wrote: >>>>> On 28/03/17 08:42, Paul Rubin wrote: >>>>>> Tim Wescott <tim@seemywebsite.com> writes: >>>>>>> I don't write many bugs that have to do with overrunning >>>>>>> array boundaries, particularly because I both inspect >>>>>>> and test for it. >>>>>> >>>>>> It helps if you're writing embedded code, which tends to >>>>>> not deal with too much variable sized data or have >>>>>> complicated control flow. Otherwise how can you really >>>>>> tell? Inspection stops helping much once the program is >>>>>> large enough. Do you do any fuzz testing etc.? >>>>>> >>>>> >>>>> I think the key point is program design, rather than testing. >>>>> Testing can help show that you /have/ bugs, it doesn't show >>>>> that you /don't/ have bugs. >>>>> >>>> >>>> But design is about constraints, and testing can show that >>>> constraints are met. That has a seriously Pareto ( 90/10 ) >>>> effect on development outcomes. The other 10 percent takes the >>>> other 90 percent of time allotted. >>>> >>>>> I don't have many bugs involving overrunning arrays either >>>>> (despite being a mere human). I just make sure I know the >>>>> size of my arrays when I use them. >>>>> >>>> >>>> Me too. >>>> >>>> Apparently, that is too hard and we'll all suffer deadly >>>> incursions. >>>> >>> >>> There are some kinds of defects that can be avoided by good >>> design. >> >> And that is really all this is. >> >>> Some kinds can be spotted by static error checking at compile >>> time. And some kinds can be best spotted using tests. >>> >> >> Static checking won't find much amongst people who have good >> self-checking habits. I've seen two cases where ancient code bases >> were cleaned up using static checkers, and it was mostly noise. >> >> Where static analysis shines is "before every checkin." But it all >> adds up. >> >>> Array overruns are best avoided by good programming practice - >>> you know exactly what size your array is when you use it. >> >> Now how hard was that? >> >>> You don't make assumptions - make sure you /know/. And they are >>> usually very hard to find by tests - the effect of an array >>> overrun is typically "something odd is happening" because you >>> have written to a different memory object unexpectedly. >>> >> >> you effectively cannot reliably test for them. They must be >> prevented by other practices. >> >>> You cannot sensibly use run-time checks of array sizes, except >>> occasionally during development. You can only check the array >>> bounds on access if you know the bounds - and if you know the >>> bounds during the access, then the code that makes the accesses >>> already knows these bounds and should not attempt such accesses. >> >> Yep. > I'd be concerned about code reuse. I keep hoping to see a single example of effective code reuse before I stop working. A wise man once told me "reuse is at the team level" - you reuse teams familiar with the code, not just the code. No point in paying for the learning curve twice... > *I* will know about the array bounds and hopefully document them well > and remember them when I pick up the code in six months. Yes! > I'm not so sure that the next guy will do the right thing, > particularly after I've left a project... That's up to him/her. When I get a new code base, I tend to create a to-be-deleted branch and put in all sorts of instrumentation to establish what the rules of it are. IMO, the biggest sin programmers commit is trying to make ever second count as "productive time ", working towards an assigned goal. You gotta spend time with a code base to get to know it. >> >>> At best, you might spot typographical errors - using >>> "sizeOfInBuffer" when you meant "sizeOfOutBuffer". >>> >> >> So I often start with "all buffers are the same size", and then >> reduce them as needed, using a typedef enum to ... enumerate all >> the possible sizes. >> >> In that case, you change one at a time, following it through its >> entire lifetime. If you can't follow it through its entire >> lifetime, then you have a much bigger problem. >> >> And to be totally honest, I'll at times "write an MMU" - have an >> array of struct of the addresses and lengths of all the buffers, >> then add extent checks that can be turned off. >> >> Most people who have buffer overrun problems have opaque void * >> style buffer being flung around. Tsk. >> > > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-31 09:21 +0200 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <obkvt3$veg$1@dont-email.me> |
| In reply to | #26350 |
On 30/03/17 17:51, Phil Martel wrote: > On 3/29/2017 20:31, Les Cargill wrote: >> David Brown wrote: >>> Array overruns are best avoided by good programming practice - you >>> know exactly what size your array is when you use it. >> >> Now how hard was that? >> >>> You don't >>> make assumptions - make sure you /know/. And they are usually very >>> hard to find by tests - the effect of an array overrun is typically >>> "something odd is happening" because you have written to a different >>> memory object unexpectedly. >>> >> >> you effectively cannot reliably test for them. They must be >> prevented by other practices. >> >>> You cannot sensibly use run-time checks of array sizes, except >>> occasionally during development. You can only check the array bounds >>> on access if you know the bounds - and if you know the bounds during >>> the access, then the code that makes the accesses already knows these >>> bounds and should not attempt such accesses. >> >> Yep. > I'd be concerned about code reuse. *I* will know about the array bounds > and hopefully document them well and remember them when I pick up the > code in six months. I'm not so sure that the next guy will do the right > thing, particularly after I've left a project... There are really just two simple rules here. 1. Make sure it is obvious how large your array is. 2. Don't access arrays unless you know its size. The next guy working on your code should not /be/ working on your code, or any code, if these rules are not blindingly obvious to him. Some "traditional" C mistakes, like overrunning string buffers, I can understand - people are sometimes lazy or make unwarranted assumptions about sizes, beginners have read books with functions like "strcat", "strcpy" and "sprintf", and even more advanced users can easily misunderstand the subtle details of the "n" variants. But arrays are well-defined structures with specific sizes. You /know/ the size when the array is created, and you need to know the size when you use it. Getting this wrong is not just making unwarranted assumptions - it is misunderstanding the point of the code you are trying to write. Of course all sorts of mistakes can creep into a program, especially during heavy development and before checks, code reviews, and testing. But array size errors should be a rare event - they are not something that should be common enough to be singled out.
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2017-03-28 14:19 -0500 |
| Subject | Re: Type-safety and C++, was: Re: Dimension of a matrix |
| Message-ID | <ie-dnTWlBtGrKkfFnZ2dnUU7-V2dnZ2d@giganews.com> |
| In reply to | #26322 |
On Mon, 27 Mar 2017 23:42:08 -0700, Paul Rubin wrote: > Tim Wescott <tim@seemywebsite.com> writes: >> I don't write many bugs that have to do with overrunning array >> boundaries, particularly because I both inspect and test for it. > > It helps if you're writing embedded code, which tends to not deal with > too much variable sized data or have complicated control flow. Otherwise > how can you really tell? Inspection stops helping much once the program > is large enough. Do you do any fuzz testing etc.? This _is_ an embedded group. When I'm writing desktop code I'm more prone to use 'at', or otherwise actively test for overrunning boundaries. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2017-03-24 11:05 -0500 |
| Message-ID | <KsWdnVJlJ99B3kjFnZ2dnUU7-S-dnZ2d@giganews.com> |
| In reply to | #26190 |
On Thu, 23 Mar 2017 23:21:07 -0700, Paul Rubin wrote: > Tim Wescott <seemywebsite@myfooter.really> writes: >> Is there anything in the standard libraries that does this easy and >> obvious thing? > > In full-fat C++ systems it's preferable to use STL containers for arrays > instead of using hacky C-style pointers to simulate them. On embedded > devices STL might be considered too much bloat though. I know what I'm doing. I just want to know if the oft-used #DIM construct has ever been formalized. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 17:33 +0100 |
| Message-ID | <ob3hk6$4eb$2@dont-email.me> |
| In reply to | #26210 |
On 24/03/17 17:05, Tim Wescott wrote: > On Thu, 23 Mar 2017 23:21:07 -0700, Paul Rubin wrote: > >> Tim Wescott <seemywebsite@myfooter.really> writes: >>> Is there anything in the standard libraries that does this easy and >>> obvious thing? >> >> In full-fat C++ systems it's preferable to use STL containers for arrays >> instead of using hacky C-style pointers to simulate them. On embedded >> devices STL might be considered too much bloat though. > > I know what I'm doing. I just want to know if the oft-used #DIM > construct has ever been formalized. > The short answer is "no".
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <tim@seemywebsite.com> |
|---|---|
| Date | 2017-03-24 12:09 -0500 |
| Message-ID | <2qGdnRfrOuMmz0jFnZ2dnUU7-N-dnZ2d@giganews.com> |
| In reply to | #26213 |
On Fri, 24 Mar 2017 17:33:58 +0100, David Brown wrote: > On 24/03/17 17:05, Tim Wescott wrote: >> On Thu, 23 Mar 2017 23:21:07 -0700, Paul Rubin wrote: >> >>> Tim Wescott <seemywebsite@myfooter.really> writes: >>>> Is there anything in the standard libraries that does this easy and >>>> obvious thing? >>> >>> In full-fat C++ systems it's preferable to use STL containers for >>> arrays instead of using hacky C-style pointers to simulate them. On >>> embedded devices STL might be considered too much bloat though. >> >> I know what I'm doing. I just want to know if the oft-used #DIM >> construct has ever been formalized. >> >> > The short answer is "no". Thanks. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-25 13:09 -0500 |
| Message-ID | <ob6bce$7vb$3@dont-email.me> |
| In reply to | #26210 |
Tim Wescott wrote: > On Thu, 23 Mar 2017 23:21:07 -0700, Paul Rubin wrote: > >> Tim Wescott <seemywebsite@myfooter.really> writes: >>> Is there anything in the standard libraries that does this easy and >>> obvious thing? >> >> In full-fat C++ systems it's preferable to use STL containers for arrays >> instead of using hacky C-style pointers to simulate them. On embedded >> devices STL might be considered too much bloat though. > > I know what I'm doing. I just want to know if the oft-used #DIM > construct has ever been formalized. > It has not been formalized to my knowledge. Which is curious. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-25 13:05 -0500 |
| Message-ID | <ob6b4n$7vb$1@dont-email.me> |
| In reply to | #26190 |
Paul Rubin wrote: > Tim Wescott <seemywebsite@myfooter.really> writes: >> Is there anything in the standard libraries that does this easy and >> obvious thing? > > In full-fat C++ systems it's preferable to use STL containers for > arrays instead of using hacky C-style pointers to simulate them. On > embedded devices STL might be considered too much bloat though. > It might and it might not be. There are cases where a (hacky C-style) library may expect a contiguous block of some type. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-24 09:20 +0100 |
| Message-ID | <ob2kn7$vd$3@dont-email.me> |
| In reply to | #26180 |
On 24/03/17 00:17, Tim Wescott wrote: > I just put the following into yet another c/c++ file: > > #define DIM(x) (sizeof(x) / sizeof(*x)) > > It calculates the number of elements in the array x (assuming that x is, > indeed an array). This is the common way to define such a macro. It does not work if you pass arrays around, of course - they decay into pointers when you pass them as function pointers (unless your array is wrapped in a struct). > > Is there anything in the standard libraries that does this easy and > obvious thing? >
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-25 13:12 -0500 |
| Message-ID | <ob6bi3$a7o$1@dont-email.me> |
| In reply to | #26195 |
David Brown wrote: > On 24/03/17 00:17, Tim Wescott wrote: >> I just put the following into yet another c/c++ file: >> >> #define DIM(x) (sizeof(x) / sizeof(*x)) >> >> It calculates the number of elements in the array x (assuming that x is, >> indeed an array). > > This is the common way to define such a macro. It does not work if you > pass arrays around, of course - they decay into pointers when you pass > them as function pointers (unless your array is wrapped in a struct). > I could not tell you which versions of which compilers support this, but in some toolchains, it's possible to specify the size of an array being passed - void p(char x[256])... . I may be thinking of compiling C code using a C++ compiler, or it may be in C99. I don't think it's in C89/ANSI. >> >> Is there anything in the standard libraries that does this easy and >> obvious thing? >> > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2017-03-25 20:08 +0100 |
| Message-ID | <ejnti4FbilfU1@mid.dfncis.de> |
| In reply to | #26254 |
Am 25.03.2017 um 19:12 schrieb Les Cargill: > David Brown wrote: > I could not tell you which versions of which compilers support this, > but in some toolchains, it's possible to specify the size of an array > being passed - void p(char x[256])... . All C compilers are actually required to allow you to pass a size like that. It doesn't have any effect whatsoever, though. Any number you put between those [] is really just decoration. These 4 function declarations are totally equivalent: void p(char x[256]); void p(char x[7]); void p(char x[]); void p(char *x);
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-25 15:17 -0500 |
| Message-ID | <ob6irp$nv$4@dont-email.me> |
| In reply to | #26255 |
Hans-Bernhard Bröker wrote: > Am 25.03.2017 um 19:12 schrieb Les Cargill: >> David Brown wrote: > >> I could not tell you which versions of which compilers support this, >> but in some toolchains, it's possible to specify the size of an array >> being passed - void p(char x[256])... . > > All C compilers are actually required to allow you to pass a size like > that. It doesn't have any effect whatsoever, though. Any number you > put between those [] is really just decoration. These 4 function > declarations are totally equivalent: > > void p(char x[256]); > void p(char x[7]); > void p(char x[]); > void p(char *x); > > I recall (vaguely) code where sizeof(x) would return 256, but it's a hazy memory. I don't remember the toolchain; probably latter day MS VS stuff. And even if it's just decoration, it preserves the size of the array out of band. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-26 17:32 +0200 |
| Message-ID | <ob8mok$fch$2@dont-email.me> |
| In reply to | #26260 |
On 25/03/17 21:17, Les Cargill wrote: > Hans-Bernhard Bröker wrote: >> Am 25.03.2017 um 19:12 schrieb Les Cargill: >>> David Brown wrote: >> >>> I could not tell you which versions of which compilers support this, >>> but in some toolchains, it's possible to specify the size of an array >>> being passed - void p(char x[256])... . >> >> All C compilers are actually required to allow you to pass a size like >> that. It doesn't have any effect whatsoever, though. Any number you >> put between those [] is really just decoration. These 4 function >> declarations are totally equivalent: >> >> void p(char x[256]); >> void p(char x[7]); >> void p(char x[]); >> void p(char *x); >> >> > > I recall (vaguely) code where sizeof(x) would return 256, but it's a > hazy memory. I don't remember the toolchain; probably latter day MS > VS stuff. That would be a broken compiler. > > And even if it's just decoration, it preserves the size of the array out > of band. > Specifying the size here is just a comment. And it is a dangerous comment, because it /looks/ like it might be something that the compiler will check, or that lets you use "sizeof" in the manner you describe - but it will not. In all the cases above, "x" is a pointer to char - /not/ an array.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-26 11:55 -0500 |
| Message-ID | <ob8rce$v0f$1@dont-email.me> |
| In reply to | #26283 |
David Brown wrote: > On 25/03/17 21:17, Les Cargill wrote: >> Hans-Bernhard Bröker wrote: >>> Am 25.03.2017 um 19:12 schrieb Les Cargill: >>>> David Brown wrote: >>> >>>> I could not tell you which versions of which compilers support >>>> this, but in some toolchains, it's possible to specify the size >>>> of an array being passed - void p(char x[256])... . >>> >>> All C compilers are actually required to allow you to pass a size >>> like that. It doesn't have any effect whatsoever, though. Any >>> number you put between those [] is really just decoration. These >>> 4 function declarations are totally equivalent: >>> >>> void p(char x[256]); void p(char x[7]); void p(char x[]); void >>> p(char *x); >>> >>> >> >> I recall (vaguely) code where sizeof(x) would return 256, but it's >> a hazy memory. I don't remember the toolchain; probably latter day >> MS VS stuff. > > That would be a broken compiler. > It might have been a C++ toolchain. I don't recall. Those are out there for sure - although given all the furor over Blind Pointers Will Be The End of Western Civilization these days.... >> >> And even if it's just decoration, it preserves the size of the >> array out of band. >> > > Specifying the size here is just a comment. It is and it isn't. > And it is a dangerous > comment, because it /looks/ like it might be something that the > compiler will check, or that lets you use "sizeof" in the manner you > describe - but it will not. In all the cases above, "x" is a pointer > to char - /not/ an array. > As a programmer, you have to check what things are. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-26 21:23 +0200 |
| Message-ID | <ob949v$ub1$1@dont-email.me> |
| In reply to | #26284 |
On 26/03/17 18:55, Les Cargill wrote:
> David Brown wrote:
>> On 25/03/17 21:17, Les Cargill wrote:
>>> Hans-Bernhard Bröker wrote:
>>>> Am 25.03.2017 um 19:12 schrieb Les Cargill:
>>>>> David Brown wrote:
>>>>
>>>>> I could not tell you which versions of which compilers support
>>>>> this, but in some toolchains, it's possible to specify the size
>>>>> of an array being passed - void p(char x[256])... .
>>>>
>>>> All C compilers are actually required to allow you to pass a size
>>>> like that. It doesn't have any effect whatsoever, though. Any
>>>> number you put between those [] is really just decoration. These
>>>> 4 function declarations are totally equivalent:
>>>>
>>>> void p(char x[256]); void p(char x[7]); void p(char x[]); void
>>>> p(char *x);
>>>>
>>>>
>>>
>>> I recall (vaguely) code where sizeof(x) would return 256, but it's
>>> a hazy memory. I don't remember the toolchain; probably latter day
>>> MS VS stuff.
>>
>> That would be a broken compiler.
>>
>
> It might have been a C++ toolchain. I don't recall.
>
> Those are out there for sure - although given all the furor over
> Blind Pointers Will Be The End of Western Civilization these days....
>
>>>
>>> And even if it's just decoration, it preserves the size of the
>>> array out of band.
>>>
>>
>> Specifying the size here is just a comment.
>
> It is and it isn't.
>
>> And it is a dangerous
>> comment, because it /looks/ like it might be something that the
>> compiler will check, or that lets you use "sizeof" in the manner you
>> describe - but it will not. In all the cases above, "x" is a pointer
>> to char - /not/ an array.
>>
>
> As a programmer, you have to check what things are.
>
Section 6.7.6.3 "Function declarators (including prototypes)" of the C
standards has paragraph 7:
A declaration of a parameter as ‘‘array of type’’ shall be adjusted
to ‘‘qualified pointer to
type’’, where the type qualifiers (if any) are those specified
within the [ and ] of the
array type derivation. If the keyword static also appears within the
[ and ] of the
array type derivation, then for each call to the function, the value
of the corresponding
actual argument shall provide access to the first element of an
array with at least as many
elements as specified by the size expression.
Using an array as a parameter type has /exactly/ the same effect as
using a pointer. Applying "sizeof" to it returns the size of a pointer.
C++ has the same thing (but without the option is using "static"). The
wording in C++14 section 8.3.5 paragraph 5 is different but gives the
same results.
As a programmer, you absolutely should /not/ have to check that the
compiler follows the fundamental rules of the language you are using. A
compiler - C or C++ - which gives the "sizeof" a C array parameter as
the sizeof the array rather than the size of the pointer, is /broken/.
This is not an option, or a feature, or something that some compilers do
- it is how C and C++ arrays work. And it is part of the reason for the
introduction of std::array in C++.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2017-03-29 19:36 -0500 |
| Message-ID | <obhjhm$i1p$1@dont-email.me> |
| In reply to | #26289 |
David Brown wrote: > On 26/03/17 18:55, Les Cargill wrote: <snip> > > As a programmer, you absolutely should /not/ have to check that the > compiler follows the fundamental rules of the language you are using. The rules may be opaque - one toolchain had been rebuilt with the default char signedness set to unsigned char. Maybe it's just me, but I have to check. It doesn't take too long. I have seen so many toolchains, some of which have bizarre extensions... > A compiler - C or C++ - which gives the "sizeof" a C array parameter > as the sizeof the array rather than the size of the pointer, is > /broken/. That unfortunately does not mean they do not exist. > This is not an option, or a feature, or something that some > compilers do - it is how C and C++ arrays work. And it is part of > the reason for the introduction of std::array in C++. > > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2017-03-30 00:36 +0000 |
| Message-ID | <obhjtu$i7n$1@dont-email.me> |
| In reply to | #26345 |
On 2017-03-30, Les Cargill <lcargill99@comcast.com> wrote: > David Brown wrote: >> On 26/03/17 18:55, Les Cargill wrote: ><snip> >> >> As a programmer, you absolutely should /not/ have to check that the >> compiler follows the fundamental rules of the language you are using. > > The rules may be opaque - one toolchain had been rebuilt with the > default char signedness set to unsigned char. Maybe it's just me, > but I have to check. It doesn't take too long. > That's another annoyance of mine. :-) If I had my way, integers would be unsigned by default in all of today's programming languages and you would have to ask for a signed integer if you wanted one. As it is, all of my variables are declared as unsigned, regardless of language (assuming the language supports it), unless I need a signed one. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2017-03-29 19:55 -0700 |
| Message-ID | <87k277cw3c.fsf@nightsong.com> |
| In reply to | #26346 |
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: > If I had my way, integers would be unsigned by default in all of today's > programming languages and you would have to ask for a signed integer if > you wanted one. What happens if you subtract 3 from 2? Are these unsigneds supposed to represent natural numbers, so you throw an exception if you get a negative result? Or are you saying all languages should use twos complement wraparound arithmetic including the ones that have exact integers now?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-03-30 09:49 +0200 |
| Message-ID | <obid4h$78q$2@dont-email.me> |
| In reply to | #26347 |
On 30/03/17 04:55, Paul Rubin wrote: > Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: >> If I had my way, integers would be unsigned by default in all of today's >> programming languages and you would have to ask for a signed integer if >> you wanted one. > > What happens if you subtract 3 from 2? Are these unsigneds supposed to > represent natural numbers, so you throw an exception if you get a > negative result? Or are you saying all languages should use twos > complement wraparound arithmetic including the ones that have exact > integers now? > Presumably he uses signed integers in situations where it makes sense to subtract 3 from 2, and in other situations he simply does not subtract 3 from 2. Making your "noOfOranges" variable signed does not let you subtract 3 oranges from 2 oranges.
[toc] | [prev] | [next] | [standalone]
| From | Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> |
|---|---|
| Date | 2017-03-30 18:07 +0000 |
| Message-ID | <objhgl$rv2$1@dont-email.me> |
| In reply to | #26349 |
On 2017-03-30, David Brown <david.brown@hesbynett.no> wrote: > On 30/03/17 04:55, Paul Rubin wrote: >> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes: >>> If I had my way, integers would be unsigned by default in all of today's >>> programming languages and you would have to ask for a signed integer if >>> you wanted one. >> >> What happens if you subtract 3 from 2? Are these unsigneds supposed to >> represent natural numbers, so you throw an exception if you get a >> negative result? Or are you saying all languages should use twos >> complement wraparound arithmetic including the ones that have exact >> integers now? >> If you think your variable might go negative, you use a signed integer otherwise you use an unsigned integer. > > Presumably he uses signed integers in situations where it makes sense to > subtract 3 from 2, and in other situations he simply does not subtract 3 > from 2. Making your "noOfOranges" variable signed does not let you > subtract 3 oranges from 2 oranges. > Exactly. You pick the data type which most closely models the problem you are trying to solve. Picking a signed integer when you know your data is always going to be positive is not a good match if unsigned integers are available in your chosen language. In my code (both work and hobbyist) I use unsigned values vastly more frequently than I do signed values and another reason is that signed integers have caused security issues in the past. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web