Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.std.c > #1415 > unrolled thread
| Started by | John Nagle <nagle@animats.com> |
|---|---|
| First post | 2012-08-13 11:39 -0700 |
| Last post | 2012-08-17 15:33 -0700 |
| Articles | 20 on this page of 105 — 13 participants |
Back to article view | Back to comp.std.c
Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-13 11:39 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-13 23:23 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-13 17:04 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-13 20:08 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-13 22:23 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 11:20 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 14:54 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 21:09 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 16:00 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 18:08 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-14 23:05 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 06:48 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 11:22 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 15:13 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 13:00 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 22:52 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 17:18 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-16 19:20 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 13:40 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-16 11:04 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 14:35 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-16 11:47 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 14:52 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 14:41 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2012-08-16 12:39 +0100
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-16 09:57 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-16 13:28 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2012-08-16 23:52 +0100
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 18:56 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 19:23 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-15 21:47 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-16 19:14 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-16 20:28 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 15:05 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-14 21:09 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 13:24 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 16:39 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 15:23 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-14 22:58 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 00:37 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 16:42 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-15 22:57 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 17:02 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 14:59 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 15:35 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 00:51 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 06:43 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 08:31 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 09:14 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 18:58 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 06:45 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Philip Lantz <prl@canterey.us> - 2012-08-14 22:51 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 07:18 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 14:15 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 14:28 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 14:36 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 14:54 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 15:08 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 12:50 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 23:22 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 14:38 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-16 00:51 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 16:32 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-16 09:05 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 17:22 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-15 20:29 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-15 12:36 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-15 16:09 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 08:47 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 16:33 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 16:38 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 06:46 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-14 22:28 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-15 08:34 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-15 09:12 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-16 13:09 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Wojtek Lerch <wojtek_l@yahoo.ca> - 2012-08-16 16:21 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-16 14:22 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-16 15:28 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Wojtek Lerch <wojtek_l@yahoo.ca> - 2012-08-16 19:49 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 08:56 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" James Kuyper <jameskuyper@verizon.net> - 2012-08-14 06:18 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 12:42 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-14 09:43 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-14 19:52 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-14 21:03 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-14 21:39 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-08-14 08:26 -0400
Re: Initial draft proposal: "Safe arrays and pointers for C" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-13 22:44 +0100
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-13 18:05 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-14 21:00 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Marc <marc.glisse@gmail.com> - 2012-08-14 21:18 +0000
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-14 23:51 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-17 09:40 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-17 21:00 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-17 13:30 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-17 23:14 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-18 01:07 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-19 23:14 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Ike Naar <ike@sverige.freeshell.org> - 2012-08-20 07:16 +0000
Re: Initial draft proposal: "Safe arrays and pointers for C" John Nagle <nagle@animats.com> - 2012-08-20 00:25 -0700
Re: Initial draft proposal: "Safe arrays and pointers for C" Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-20 11:49 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2012-08-20 22:40 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" jacob navia <jacob@spamsink.net> - 2012-08-20 23:08 +0200
Re: Initial draft proposal: "Safe arrays and pointers for C" Keith Thompson <kst-u@mib.org> - 2012-08-17 15:33 -0700
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | John Nagle <nagle@animats.com> |
|---|---|
| Date | 2012-08-13 11:39 -0700 |
| Subject | Initial draft proposal: "Safe arrays and pointers for C" |
| Message-ID | <502949DA.9000604@animats.com> |
We are circulating an early draft proposal for an extension to C which offers a way to prevent most buffer overflows while retaining backwards compatibility with old code. This has been discussed on some programming language forums (LtU) and updated to reflect criticisms and comments, and now we're exposing it to a wider community. This is not the first attempt to address this problem. We know about most of the others, from SAL to Cyclone. This one appears to have backwards compatibility good enough to be a potential candidate for inclusion in a future version of the C standard. Comments are requested. Abstract: Buffer overflows continue to plague C programs. This is a draft proposal for dealing with that problem. The basis of this proposal is to define means for expressing the size of arrays in C. C already has fixed-size arrays with useful semantics. In this proposal, the existing syntax for fixed-size arrays is generalized to allow known-size arrays, where the size of the array is known at variable initialization time. With relatively minor and compatible changes to C, the most troublesome causes of program crashes and security vulnerabilities can be dealt with. The short intro: C already allows arrays of fixed size as formal parameters. C99 allows arrays of variable size as local variables. C++ allows references. If we combine those concepts, we can add to the language arrays of known size as formal parameters, with a size based on other formal parameters. Like this: int read(int fd, char(&)buf[n], size_t n); This is not new syntax; that's how a reference to an array is passed in C++. We're just allowing the size to be a variable. This leads to a backwards-compatible way to talk about and check array sizes. The paper: http://www.animats.com/papers/languages/safearraysforc36.pdf Please read this over and critique. Thanks. John Nagle Animats
[toc] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-13 23:23 +0200 |
| Message-ID | <50297066.1010202@loria.fr> |
| In reply to | #1415 |
Hello, I think this proposal tries to do too many things at a time, and is more intimidating than anything else. Am 13.08.2012 20:39, schrieb John Nagle: > Please read this over and critique. Thanks. > Summary of language changes > The language changes required are minor. you must be kidding > Relaxation of existing restrictions > • Expressions allowed in most array size declarations. (This is the > key enhancement.) I don't see how this is new to C. If you mean you want to extend the idea of VLA to file scope, I'd first like to have a reasonable semantic for this. (When will the corresponding size expressions be evaluated?) > Features imported from C++11 > • auto Things like this doesn't happen as quickly to C as to C++. The auto feature is perhaps not too bad (has been discussed several times) but reusing a keyword without obsoleting it first for several years is not in the habits of C, and I guess will never be. (C++ really messed this up.) > • References why not? but it is unlikely that such a thing will enter C through the backdoor of array handling. This would need a very detailed analysis and proposal of its own, which should be treated as separate issue. > New reserved words > • force_cast (storage class, for casts only, allows forcing certain casts in strict mode) different types of cast as they are in C++? > • void_space (type, for arrays of memory with unspecified contents) there is simply no need for this since C already has such a data type. It is call unsigned char. > New predefined functions > • size_t lengthof(array); ok > • arraytype &(array_slice(array, start, end))[end - start]; (Generic function) > • typeofvalue init_space(variable, value) (Generic function) a generic memset? Why not, could be nice. But I don't know how you want to fit such a thing into generic functions in C. These are usually limited to fixed set of types and are not easily expandable as templates in C++ for example. > • void clear_space(variable); (Generic function) same thoughts Another observation is that your proposal messes heavily with evaluation order of function prototypes, this is not going to happen. You have > void copybyref(int (&a)[n], const int (&b)[n], size_t n) which is a show stopper because n is declared after its use. Things like this should read void copybyref(size_t n, int (&a)[n], const int (&b)[n]) But this already shows that the advantage you are trying to advertise is minimal. In existing C such an interface could look void copybyref(size_t n, int (*a)[n], const int (*b)[n]) which is a legal way to lift the array dimensions to the function. (The disadvantage is the syntax that you'd have to use for accessing the members (*a)[i] is a bit ugly, aggreed.) > In C99, expressions are allowed in array declaration sizes provided > that all variables referenced are compile-time constants, and the only > functions allowed in such expressions are built-ins such as sizeof. This is only true for arrays that are not VLA. You have to use a much more precise language to advocate your cause. > In struct declarations, any structure field name may be used in a size > expression, provided that this does not result in a dependency loop. I don't see such a thing entering the C language for the next 20 years. What you are actually proposing is to allow a sort of object oriented view inside an initialization expression. Again, as for references, this is an idea that can be discussed, but must so separately as a feature of its own. Why allow such a thing just for array indices? And not to initialize other fields? > Type void_space values are converted to type unsigned int if used in an arithmetic context. you really reinvent unsigned char from scratch, with that exception. (unsigned char usually promotes to int when it is an operand.) why should this type behave differently from other narrow arithmetic types? In my opinion, this is not going to happen. Jens
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-13 17:04 -0700 |
| Message-ID | <lnvcgms5i6.fsf@nuthaus.mib.org> |
| In reply to | #1416 |
Jens Gustedt <jens.gustedt@loria.fr> writes:
> Am 13.08.2012 20:39, schrieb John Nagle:
[...]
> > Features imported from C++11
> > • auto
>
> Things like this doesn't happen as quickly to C as to C++. The auto
> feature is perhaps not too bad (has been discussed several times) but
> reusing a keyword without obsoleting it first for several years is not
> in the habits of C, and I guess will never be. (C++ really messed this
> up.)
Background: C has always had "auto" as a keyword, though it's rarely
used. It's a storage class specifier. At block scope, this:
auto int x = 42;
is equivalent to
int x = 42;
At file scope, it's a constraint violation. (It was useful when
declarations without a type defaulted to int, in the pre-ANSI days, and
it goes back to C's typeless predecessors.)
The 2011 C++ standard introduced a new use of "auto", to allow declaring
an object whose type is inferred from its initializer:
auto x = 42; // x is of type int
It simultaneously removed the use of "auto" as a storage class
specifier. I'm not convinced that C++ had to do so, or that C would
have to do so; I believe the new usage is compabitible with the old one.
"auto" as it exists now is largely useless, and I suppose the C++
committee felt it was a good opportunity to get rid of it.
[...]
> > New predefined functions
> > • size_t lengthof(array);
>
> ok
>
> > • arraytype &(array_slice(array, start, end))[end - start]; (Generic
> function)
> > • typeofvalue init_space(variable, value) (Generic function)
>
> a generic memset? Why not, could be nice. But I don't know how you
> want to fit such a thing into generic functions in C. These are
> usually limited to fixed set of types and are not easily expandable as
> templates in C++ for example.
This introduces the concept of "predefined functions", something
that C doesn't currently have. What is the type of the "lengthof"
function? Can you construct a pointer to it? "lengthof" makes
much more sense as an operator, analagous to "sizeof" and the
new "_Alignof". Following precedent, it would probably be a new
"_Lengthof" operator, with a standard header containing
#define lengthof _Lengthof
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | John Nagle <nagle@animats.com> |
|---|---|
| Date | 2012-08-13 20:08 -0700 |
| Message-ID | <k0cfg2$7a5$1@dont-email.me> |
| In reply to | #1416 |
On 8/13/2012 2:23 PM, Jens Gustedt wrote:
> Hello,
> I think this proposal tries to do too many things at a time, and is
> more intimidating than anything else.
All the changes proposed are directed to one end - preventing
buffer overflows by providing means to describe the size of arrays
within the C language, at places where arrays of unspecified size
are presently used.
As the introduction to the paper says, "In any useful program,
each array has a size known to the programmer. In C, there is
currently no way to consistently express that size in the language. This
proposal adds that capability."
>
> > Relaxation of existing restrictions
> > • Expressions allowed in most array size declarations. (This is the
> > key enhancement.)
>
> I don't see how this is new to C. If you mean you want to extend the
> idea of VLA to file scope, I'd first like to have a reasonable
> semantic for this. (When will the corresponding size expressions be
> evaluated?)
See page 8, "Array size expressions": "the array size
expressions evaluated where a function is called must produce the
same results when recomputed inside the function when the function
is entered." The key concept here is that array size expressions
are computable using only constants and function parameters
(or structure elements, for structures).
>
> > Features imported from C++11
> > • auto
>
> Things like this doesn't happen as quickly to C as to C++.
See previous message by Keith Thompson, who addresses this
in some detail.
>
> > • References
>
> why not? but it is unlikely that such a thing will enter C through the
> backdoor of array handling. This would need a very detailed analysis
> and proposal of its own, which should be treated as separate issue.
C++ references seem to play well with C semantics. If there were
problems in that area, they would have been discovered a decade or two
ago.
> > New reserved words
> > • force_cast (storage class, for casts only, allows forcing certain
> casts in strict mode)
>
> different types of cast as they are in C++?
force_cast is really reinterpret_cast of C++, but the corner-bracket
syntax used in C++ isn't allowed in C. Hence the problem.
The general idea is that, in strict mode (see the paper) C casts
are restricted to memory-safe operations. force_cast is for the
rare occasions it is necessary to override that.
>
> > • void_space (type, for arrays of memory with unspecified contents)
>
> there is simply no need for this since C already has such a data
> type. It is call unsigned char.
If that were correct, the POSIX declaration of "read" would not
be
ssize_t read(int fd, void *buf, size_t count);
But it is.
"void *" was introduced to avoid type conversion problems when going
from uninterpreted bits to a defined type. But "void *" has no size.
We want to have sized arrays of uninterpreted bytes, which can
be converted to and from other types without casting, as with void*,
provided that the sizes match and the type does not contain pointers
or references.
>
> > New predefined functions
> > • size_t lengthof(array);
>
> ok
As someone else pointed out, "sizeof" is really an operator, so
"lengthof" should be one as well.
>
> > • arraytype &(array_slice(array, start, end))[end - start]; (Generic
> function)
> > • typeofvalue init_space(variable, value) (Generic function)
>
> a generic memset? Why not, could be nice. But I don't know how you
> want to fit such a thing into generic functions in C. These are
> usually limited to fixed set of types and are not easily expandable as
> templates in C++ for example.
This is optional. The reason I included it is to allow common and
safe operations without casting. The goal is that there should
be very little need for force_cast, which is an unsafe operation.
>
> Another observation is that your proposal messes heavily with
> evaluation order of function prototypes, this is not going to
> happen. You have
>
> > void copybyref(int (&a)[n], const int (&b)[n], size_t n)
>
> which is a show stopper because n is declared after its use. Things
> like this should read
>
> void copybyref(size_t n, int (&a)[n], const int (&b)[n])
There's much legacy code, including POSIX, Linux, and
C library APIs in which the size is given last. It's an old
tradition in C. Breaking that would have substantial impact.
GCC already offers a feature like this as an extension.
See
http://gcc.gnu.org/onlinedocs/gcc/Variable-Length.html#Variable-Length
GCC gets around this problem by allowing forward declarations
in parameter lists. In GCC, the above would be written:
void copybyref(size_t n; int (&a)[n], const int (&b)[n], size_t n)
where "size_t n;" is a forward declaration, not a parameter.
What's thinking on this? Is it better to have forward declarations
of formal parameters, or to handle array size expressions as a
special, limited form of expression?
> But this already shows that the advantage you are trying to advertise
> is minimal. In existing C such an interface could look
>
> void copybyref(size_t n, int (*a)[n], const int (*b)[n])
>
> which is a legal way to lift the array dimensions to the
> function.
C99 lets you go further than that. See ISO/IEC 9899:TC2, Example 4,
page 133:
(page ref to: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf)
void addscalar(int n, int m,
double a[n][n*m+300], double x);
int main()
{
double b[4][308];
addscalar(4, 2, b, 2.17);
return 0;
}
void addscalar(int n, int m,
double a[n][n*m+300], double x)
{
for (int i = 0; i < n; i++)
for (int j = 0, k = n*m+300; j < k; j++)
// a is a pointer to a VLA with n*m+300 elements
a[i][j] += x;
}
That code is passing an array by reference, even though
C99 doesn't use that term. So C99 already has much of
what I'm proposing. This is an obscure feature, one
I hadn't known about. It doesn't seem to be used,
or even mentioned, much. This is not allowed in C++.
In GCC, applying "sizeof" to the array a above returns 4,
That's probably wrong, per 6.3.5.4, para. 2:
"If the type of the operand is a variable length array
type, the operand is evaluated". "sizeof" in C99 is
supposed to be able to access the size of variable length
arrays.
The hard parts of what I'm proposing seem to be already in C99.
But some of the supporting features needed to make them useful
is missing. You can currently talk about array sizes in C99,
but can't get at the information. I need to do some revision. Thanks.
John Nagle
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-13 22:23 -0700 |
| Message-ID | <lnr4rarqqz.fsf@nuthaus.mib.org> |
| In reply to | #1420 |
John Nagle <nagle@animats.com> writes:
> On 8/13/2012 2:23 PM, Jens Gustedt wrote:
[...]
>> > • void_space (type, for arrays of memory with unspecified contents)
>>
>> there is simply no need for this since C already has such a data
>> type. It is call unsigned char.
>
> If that were correct, the POSIX declaration of "read" would not
> be
>
> ssize_t read(int fd, void *buf, size_t count);
>
> But it is.
>
> "void *" was introduced to avoid type conversion problems when going
> from uninterpreted bits to a defined type. But "void *" has no size.
> We want to have sized arrays of uninterpreted bytes, which can
> be converted to and from other types without casting, as with void*,
> provided that the sizes match and the type does not contain pointers
> or references.
"void*" has two distinguishing features: it can point to any type (after
conversion), and conversions between void* and other pointer types are
implicit.
Before void* was added to the language, char* or unsigned char* served
the former purpose (early C didn't have the "unsigned" keyword); for the
latter, explicit conversions were sometimes required.
The result is not entirely consistent. void* points to arbitrary chunks
of memory, but the chunks themselves are best represented as arrays of
unsigned char. Which means that if memset, for example:
void *memset(void *s, int c, size_t n);
is implemented in C, the code is going to have to convert the value of
"s" to unsigned char* before it can operate on it.
I'm sure that a cleaner model could be built from scratch, but adding a
new void_space type to the existing language strikes me as unnecessary
and potentially confusing.
[...]
> C99 lets you go further than that. See ISO/IEC 9899:TC2, Example 4,
> page 133:
> (page ref to: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf)
n1256.pdf is newer; it includes TC3. And n1570.pdf is the latest public
draft of C11. Section numbers are much more useful references than page
numbers; your PDF viewer should let you view a nice tree-structured list
of sections.
> void addscalar(int n, int m,
> double a[n][n*m+300], double x);
>
> int main()
> {
> double b[4][308];
> addscalar(4, 2, b, 2.17);
> return 0;
> }
>
> void addscalar(int n, int m,
> double a[n][n*m+300], double x)
> {
> for (int i = 0; i < n; i++)
> for (int j = 0, k = n*m+300; j < k; j++)
> // a is a pointer to a VLA with n*m+300 elements
> a[i][j] += x;
> }
>
> That code is passing an array by reference, even though
> C99 doesn't use that term. So C99 already has much of
> what I'm proposing. This is an obscure feature, one
> I hadn't known about. It doesn't seem to be used,
> or even mentioned, much. This is not allowed in C++.
>
> In GCC, applying "sizeof" to the array a above returns 4,
> That's probably wrong, per 6.3.5.4, para. 2:
> "If the type of the operand is a variable length array
> type, the operand is evaluated". "sizeof" in C99 is
> supposed to be able to access the size of variable length
> arrays.
C does not have parameters of array type. "a" is not an array, it's a
pointer. The array isn't passed "by reference" in the C++ sense; rather
a pointer to the first element of the array is passed.
N1570 6.7.6.3p7:
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.
So a is of type "pointer to array [n*m+300] of double". sizeof a
is the size of that pointer. and sizeof a[0] is
n*m*300 * sizeof (double).
"sizeof a[0]" can also be written as "sizeof *a".
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | John Nagle <nagle@animats.com> |
|---|---|
| Date | 2012-08-14 11:20 -0700 |
| Message-ID | <k0e4tl$892$1@dont-email.me> |
| In reply to | #1421 |
On 8/13/2012 10:23 PM, Keith Thompson wrote:
> John Nagle <nagle@animats.com> writes:
>> On 8/13/2012 2:23 PM, Jens Gustedt wrote:
> [...]
>> void addscalar(int n, int m,
>> double a[n][n*m+300], double x)
>> {
>> for (int i = 0; i < n; i++)
>> for (int j = 0, k = n*m+300; j < k; j++)
>> // a is a pointer to a VLA with n*m+300 elements
>> a[i][j] += x;
>> }
...
> C does not have parameters of array type. "a" is not an array, it's a
> pointer. The array isn't passed "by reference" in the C++ sense; rather
> a pointer to the first element of the array is passed.
>
> N1570 6.7.6.3p7:
>
> 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.
Qualified pointers are mentioned in N1570 at
"Simple Assignment" (6.5.16.1), and in "Array declarators",
but they're never really discussed as a subject. 6.7.6.1 (Pointer
declarators) says "For two pointer types to be compatible, both
shall be identically qualified and both shall be pointers to
compatible types." This would seem to imply that implementations
should (or at least could) check VLA size match at function calls.
It may thus be within the existing spec to take Annex K
runtime-constraint action when sizes don't match. That's
a good first step to preventing buffer overflows.
> So a is of type "pointer to array [n*m+300] of double". sizeof a
> is the size of that pointer. and sizeof a[0] is
> n*m*300 * sizeof (double).
GCC 4.5.3, at least, does not agree. sizeof a[0] is the size
of one row of the 2D array, not the whole array. That's what
I would have expected. sizeof(a) is the size of a pointer, here
4. That's questionable.
It's questionable because sizeof results for a local VLA are
different. If I add
double wrk[n][n];
int siz1 = sizeof(wrk);
printf("Size of wrk is %d\n", siz1);
at the top of the function above (which is from N1570, Example 4,
6.7.6.3, which calls this with n=4), I get 128 from GCC. That's
4*4*8, the full size of the array. That's what should happen.
Is this intentional, a GCC bug, or an ambiguity in the standard?
It's certainly desirable to be able to obtain the size of an array
when the language knows it. "sizeof" shouldn't have different
semantics depending upon whether an array is a a parameter or
a local. In practice, the use case for "sizeof" usually involves
I/O, where getting the size wrong is a quick route to a buffer overflow.
John Nagle
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-14 14:54 -0400 |
| Message-ID | <502A9EEB.6050309@verizon.net> |
| In reply to | #1428 |
On 08/14/2012 02:20 PM, John Nagle wrote:
> On 8/13/2012 10:23 PM, Keith Thompson wrote:
>> John Nagle <nagle@animats.com> writes:
>>> On 8/13/2012 2:23 PM, Jens Gustedt wrote:
>> [...]
>
>>> void addscalar(int n, int m,
>>> double a[n][n*m+300], double x)
>>> {
>>> for (int i = 0; i < n; i++)
>>> for (int j = 0, k = n*m+300; j < k; j++)
>>> // a is a pointer to a VLA with n*m+300 elements
>>> a[i][j] += x;
>>> }
> ...
>> C does not have parameters of array type. "a" is not an array, it's a
>> pointer. The array isn't passed "by reference" in the C++ sense; rather
>> a pointer to the first element of the array is passed.
>>
>> N1570 6.7.6.3p7:
>>
>> 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.
>
> Qualified pointers are mentioned in N1570 at
> "Simple Assignment" (6.5.16.1), and in "Array declarators",
> but they're never really discussed as a subject. ...
Qualified pointers require little special description. They are
pointers, with all that that implies, and the pointed-at type is
qualified, with all that that implies. There's very little interaction
between those two aspects of qualified pointers; virtually everything
that needs to be said about them is said separately about each aspect.
It's true that a parameter declared as "double a[const n][n*m+300]"
would get adjusted to "double const (*a)[n*m+300]", but the carry over
of the 'const' qualifier is a feature that was introduced in C99 that is
irrelevant to the point Keith was making; it's the adjustment from an
array type to a pointer type that matters.
> ... 6.7.6.1 (Pointer
> declarators) says "For two pointer types to be compatible, both
> shall be identically qualified and both shall be pointers to
> compatible types." This would seem to imply that implementations
> should (or at least could) check VLA size match at function calls.
Yes - but since "double a[n][n*m+300]" gets adjusted to "double
(*a)[n*m+300]", the pointed-at type is double[n*m+300]. Whenever an
lvalue of array type is used in almost any context (including being
passed to a function), it gets converted to a pointer to its first
element. As a result, neither the leading dimension of the argument nor
the leading dimension of the corresponding parameter plays any role in
the compatibility check.
> It may thus be within the existing spec to take Annex K
> runtime-constraint action when sizes don't match. That's
> a good first step to preventing buffer overflows.
>
>> So a is of type "pointer to array [n*m+300] of double". sizeof a
>> is the size of that pointer. and sizeof a[0] is
>> n*m*300 * sizeof (double).
Correction:
(n*m+300)*sizeof(double)
> GCC 4.5.3, at least, does not agree. sizeof a[0] is the size
> of one row of the 2D array, not the whole array.
"One row of the 2D array" has the size "(n*m+300) * sizeof (double)", so
assuming that I've correctly diagnosed a typo in Keith's message, you
and Keith are in agreement here.
> ... That's what
> I would have expected. sizeof(a) is the size of a pointer, here
> 4. That's questionable.
It may be questionable whether the standard should have been written
that way, but there's very little controversy about the fact that it was
in fact written to require that result.
...
> Is this intentional, a GCC bug, or an ambiguity in the standard?
Intentional.
[toc] | [prev] | [next] | [standalone]
| From | Jens Gustedt <jens.gustedt@loria.fr> |
|---|---|
| Date | 2012-08-14 21:09 +0200 |
| Message-ID | <502AA275.70703@loria.fr> |
| In reply to | #1429 |
Hello Am 14.08.2012 20:54, schrieb James Kuyper: > It's true that a parameter declared as "double a[const n][n*m+300]" > would get adjusted to "double const (*a)[n*m+300]", but the carry over > of the 'const' qualifier is a feature that was introduced in C99 that is > irrelevant to the point Keith was making; it's the adjustment from an > array type to a pointer type that matters. I would have thought this is adjusted to double (*const a)[n*m+300] and my compiler confirms me in that opinion. Where do you get this "carry over" of the const qualifier from? If this would be so the introduction of [const ] would have added nothing at all to the language. Jens
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-14 16:00 -0400 |
| Message-ID | <502AAE7A.3080001@verizon.net> |
| In reply to | #1434 |
On 08/14/2012 03:09 PM, Jens Gustedt wrote: > Hello > > Am 14.08.2012 20:54, schrieb James Kuyper: >> It's true that a parameter declared as "double a[const n][n*m+300]" >> would get adjusted to "double const (*a)[n*m+300]", but the carry over >> of the 'const' qualifier is a feature that was introduced in C99 that is >> irrelevant to the point Keith was making; it's the adjustment from an >> array type to a pointer type that matters. > > I would have thought this is adjusted to > > double (*const a)[n*m+300] You're right. > and my compiler confirms me in that opinion. Where do you get this > "carry over" of the const qualifier from? If this would be so the > introduction of [const ] would have added nothing at all to the > language. The typo in my message made the difference between something useful and something redundant - but neither the useful feature nor the non-existent redundant feature has anything to do with the point that Keith was making.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-14 18:08 -0400 |
| Message-ID | <502ACC52.1060808@verizon.net> |
| In reply to | #1429 |
On 08/14/2012 02:54 PM, James Kuyper wrote: > On 08/14/2012 02:20 PM, John Nagle wrote: ... >> ... That's what >> I would have expected. sizeof(a) is the size of a pointer, here >> 4. That's questionable. > > It may be questionable whether the standard should have been written > that way, but there's very little controversy about the fact that it was > in fact written to require that result. On reflection, I realize that's not quite true. Nick Maclaren objected, for both C90 and C99, to the fact that the standard does not specify precisely when the adjustment of array parameters into pointers occurs relative to other things that occur in what is now called translation phase 8. One example would be whether it comes before or after evaluation of the sizeof operator. His defect report was "resolved" with the response "The standard is clear enough as it is.", which fails to answer the "Yes/No" question he asked. He acknowledged that "Everyone knows" that the adjustment is supposed to occur first (at least, they do after any code written on the contrary assumption fails to generate the expected result), but it's not clear that the standard actually says so. I'm not sure whether the committee has ever actually officially answered that question, or inserted wording in the standard to render it unnecessary. Your desired result could be obtained by simply changing the standard to explicitly specify that the adjustment of an array parameter does not occur until after evaluation of sizeof expressions involving that parameter. This would, of course, be completely unacceptable because it would break huge amounts of existing code.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2012-08-14 23:05 -0700 |
| Message-ID | <MPG.2a94dc129cb7ed389896ba@news.eternal-september.org> |
| In reply to | #1445 |
James Kuyper wrote: > Your desired result could be obtained by simply changing the standard > to explicitly specify that the adjustment of an array parameter does > not occur until after evaluation of sizeof expressions involving that > parameter. This would, of course, be completely unacceptable because > it would break huge amounts of existing code. It has the potential to break existing code, but I would bet that most code that applies sizeof to a parameter declared as an array is already broken. I doubt that a change such as this would break much code. Still unacceptable, though. However, introducing a new operator to get the size information for a parameter that was declared as an array (before it was adjusted to a pointer) seems doable. (The parameter would still be adjusted to a pointer, of course. The compiler would just have to remember that it was originally written the other way, and remember the first dimension, in order to correctly apply the new operator.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-15 06:48 -0400 |
| Message-ID | <k0fupn$kgi$1@dont-email.me> |
| In reply to | #1460 |
On 08/15/2012 02:05 AM, Philip Lantz wrote:
> James Kuyper wrote:
>> Your desired result could be obtained by simply changing the standard
>> to explicitly specify that the adjustment of an array parameter does
>> not occur until after evaluation of sizeof expressions involving that
>> parameter. This would, of course, be completely unacceptable because
>> it would break huge amounts of existing code.
>
> It has the potential to break existing code, but I would bet that most
> code that applies sizeof to a parameter declared as an array is already
> broken. ...
Actually, I think that's rather unlikely. If someone writes
void func(T array[10])
{
and uses sizeof(array) inside that function without expecting it to
return sizeof(T*), the code stands a pretty good chance of
malfunctioning. In code that has actually seen any significant use, I'd
expect most occurrences of code like sizeof(array) to have been written
with correct expectations about the value of that expression (even if if
those are not the same as the expectations when it was originally written).
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | John Nagle <nagle@animats.com> |
|---|---|
| Date | 2012-08-15 11:22 -0700 |
| Message-ID | <k0gpd0$mpf$1@dont-email.me> |
| In reply to | #1466 |
On 8/15/2012 3:48 AM, James Kuyper wrote:
> On 08/15/2012 02:05 AM, Philip Lantz wrote:
>> James Kuyper wrote:
>>> Your desired result could be obtained by simply changing the standard
>>> to explicitly specify that the adjustment of an array parameter does
>>> not occur until after evaluation of sizeof expressions involving that
>>> parameter. This would, of course, be completely unacceptable because
>>> it would break huge amounts of existing code.
I'm trying to find any production code that actually uses
variable length arrays. Google Code Search is still available. (It was
officially discontinued, but it's still up.
Try "http://code.google.com/codesearch").
I tried searching for
double\s+\w+\s+\[[:alpha:]\w+\]
float\s+\w+\s+\[[:alpha:]\w+\]
char\s+\w+\s+\[[:alpha:]\w+\]
which just finds declarations of char, float and double arrays where the
dimensions are symbols, not numeric constants. This feature is most
useful for multidimensional arrays, and would be directly useful in
math libraries, so "double" and "float" are a likely usage.
This was run on C code only. You can repeat these searches with
http://code.google.com/codesearch#search/&q=double\s%2B\w%2B\s%2B\[[:alpha:]\w%2B\]%20lang:^c$&sq=&type=cs
http://code.google.com/codesearch#search/&q=float\s%2B\w%2B\s%2B\[[:alpha:]\w%2B\]%20lang:^c$&sq=&type=cs
http://code.google.com/codesearch#search/&q=char\s%2B\w%2B\s%2B\[[:alpha:]\w%2B\]%20lang:^c$&type=cs
I then looked through the results of that by hand.
Every declaration I found with a symbol in a dimension turned out
to be a #define constant. I would have expected to find math
libraries using this, but I'm not. There were no float or
double VLAs found.
A few char VLAs were found:
Test suite for GCC:
http://code.google.com/codesearch#wZuuyuB8jKQ/src/third_party/gcc/gcc/testsuite/gcc.dg/20101010-1.c&q=char%5Cs%2B%5Cw%2B%5Cs%2B%5C%5B%5B:alpha:%5D%5Cw%2B%5C%5D%20lang:%5Ec$&ct=rc&cd=10
"The Dot Game"
http://code.google.com/codesearch#M5u26Gl8L1E/DG_Client/net.h&q=char\s%2B\w%2B\s%2B\[[:alpha:]\w%2B\]%20lang:^c$&sq=&ct=rc&cd=109
Erlang library:
http://code.google.com/codesearch#Cq8p_XNhMfk/trunk/erts/emulator/drivers/common/inet_drv.c&q=char\s%2B\w%2B\s%2B\[[:alpha:]\w%2B\]%20lang:^c$&sq=&ct=rc&cd=148
(Two occurrences in the Erlang library, one of which is a textual
copy of the other.)
These are all local arrays. I didn't find any variable length
array function parameters at all.
So usage of variable length arrays in open source C code is very low.
In no case was a "sizeof" operator applied to a VLA. I'm not finding
"huge amounts of existing code".
John Nagle
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-15 15:13 -0400 |
| Message-ID | <502BF4CA.1040304@verizon.net> |
| In reply to | #1477 |
On 08/15/2012 02:22 PM, John Nagle wrote:
> On 8/15/2012 3:48 AM, James Kuyper wrote:
>> On 08/15/2012 02:05 AM, Philip Lantz wrote:
>>> James Kuyper wrote:
>>>> Your desired result could be obtained by simply changing the standard
>>>> to explicitly specify that the adjustment of an array parameter does
>>>> not occur until after evaluation of sizeof expressions involving that
>>>> parameter. This would, of course, be completely unacceptable because
>>>> it would break huge amounts of existing code.
>
> I'm trying to find any production code that actually uses
> variable length arrays. Google Code Search is still available. (It was
> officially discontinued, but it's still up.
...
> So usage of variable length arrays in open source C code is very low.
> In no case was a "sizeof" operator applied to a VLA. I'm not finding
> "huge amounts of existing code".
Your search was too narrow, in one way, and too broad, in another.
That change would break code using fixed length array parameters just as
easily as it would break VLAs. If you don't understand why, re-read it -
it makes no distinctions between fixed and variable length arrays. On
the other hand, it only affects function parameters declared are arrays;
other array declarations would be unaffected. I could be mistaken, but I
got the impression from your description that you were looking at all
VLAs, regardless of where they are defined.
Note, in particular, that 'a' in the following example is NOT a VLA, but
would be affected by this change:
size_t func(size_t n, char a[n])
{
return sizeof a;
}
According to the standard as currently written, func() must always
return sizeof(char*). With my sarcastic suggestion, it would be required
to always return the value of n. In neither case would the return value
depend in any way upon the value of the second argument.
[toc] | [prev] | [next] | [standalone]
| From | John Nagle <nagle@animats.com> |
|---|---|
| Date | 2012-08-15 13:00 -0700 |
| Message-ID | <k0gv5g$vap$1@dont-email.me> |
| In reply to | #1478 |
On 8/15/2012 12:13 PM, James Kuyper wrote: > On 08/15/2012 02:22 PM, John Nagle wrote: >> On 8/15/2012 3:48 AM, James Kuyper wrote: >>> On 08/15/2012 02:05 AM, Philip Lantz wrote: >>>> James Kuyper wrote: >>>>> Your desired result could be obtained by simply changing the standard >>>>> to explicitly specify that the adjustment of an array parameter does >>>>> not occur until after evaluation of sizeof expressions involving that >>>>> parameter. This would, of course, be completely unacceptable because >>>>> it would break huge amounts of existing code. >> >> I'm trying to find any production code that actually uses >> variable length arrays. Google Code Search is still available. (It was >> officially discontinued, but it's still up. > ... >> So usage of variable length arrays in open source C code is very low. >> In no case was a "sizeof" operator applied to a VLA. I'm not finding >> "huge amounts of existing code". > > Your search was too narrow, in one way, and too broad, in another. You can, of course, repeat the search yourself. I provided the information necessary to do that. > That change would break code using fixed length array parameters just as > easily as it would break VLAs. Occurrences of "sizeof" on fixed length arrays also appear to be rare to nonexistent in the corpus of C code known to Google Code Search. Rather than speculating, it is useful to examine the available data. It's worth noting that Microsoft has declined to support VLAs in Visual C, because they are not also a C++ feature. This appears to be a C99 feature so little used and so weakly supported (ref http://en.wikipedia.org/wiki/C99) that legacy code probably isn't going to be a problem. VLAs are already an optional feature in the current C standard draft. It may be worth working on an approach that is not incompatible with C++ instead. The existing approach, after 13 years, has been rejected by the market. John Nagle
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2012-08-15 22:52 +0200 |
| Message-ID | <a92ggiFptrU1@mid.dfncis.de> |
| In reply to | #1481 |
On 15.08.2012 22:00, John Nagle wrote: > Occurrences of "sizeof" on fixed length arrays also appear to be > rare to nonexistent in the corpus of C code known to Google Code Search. If so, then that either appearance is grievously misleading, or Google doesn't really have a representative sample of real-world C code. > VLAs are already an optional feature in the current C standard draft. Given they were a _non_-optional feature of the previous actual standard of 1999, I'd like a draft number, chapter and verse before I believe that. > The existing approach, after 13 years, has been rejected by the > market. With all due respect, I don't think that you should be the one to determine such things.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-15 17:18 -0400 |
| Message-ID | <502C1215.5010506@verizon.net> |
| In reply to | #1483 |
On 08/15/2012 04:52 PM, Hans-Bernhard Bröker wrote: > On 15.08.2012 22:00, John Nagle wrote: ... >> VLAs are already an optional feature in the current C standard draft. > > Given they were a _non_-optional feature of the previous actual standard > of 1999, I'd like a draft number, chapter and verse before I believe that. n1570.pdf: §6.7.6.2p4: "Variable length arrays are a conditional feature that implementations need not support;" §6.10.8.3p1: "The following macro names are conditionally defined by the implementation: ... _ _STDC_NO_VLA_ _ The integer constant 1, intended to indicate that the implementation does not support variable length arrays or variably modified types." While n1570.pdf is a draft, it's very close to the final standard; I doubt that this changed. >> The existing approach, after 13 years, has been rejected by the >> market. > > With all due respect, I don't think that you should be the one to > determine such things. He didn't. The committee did.
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2012-08-16 19:20 +0200 |
| Message-ID | <a94ofgFmbsU1@mid.dfncis.de> |
| In reply to | #1485 |
On 15.08.2012 23:18, James Kuyper wrote: > On 08/15/2012 04:52 PM, Hans-Bernhard Bröker wrote: >> On 15.08.2012 22:00, John Nagle wrote: >>> VLAs are already an optional feature in the current C standard draft. >> Given they were a _non_-optional feature of the previous actual standard >> of 1999, I'd like a draft number, chapter and verse before I believe that. > n1570.pdf: §6.7.6.2p4: "Variable length arrays are a conditional feature > that implementations need not support;" Hmm... and here I sit, trying hard as I can not to ask "They did ... WHAT?" Guess I'll have to dig me up a C11 Rationale, then.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-08-16 13:40 -0400 |
| Message-ID | <502D3099.3020704@verizon.net> |
| In reply to | #1499 |
On 08/16/2012 01:20 PM, Hans-Bernhard Bröker wrote: > On 15.08.2012 23:18, James Kuyper wrote: >> On 08/15/2012 04:52 PM, Hans-Bernhard Bröker wrote: >>> On 15.08.2012 22:00, John Nagle wrote: > >>>> VLAs are already an optional feature in the current C standard draft. > >>> Given they were a _non_-optional feature of the previous actual standard >>> of 1999, I'd like a draft number, chapter and verse before I believe that. > >> n1570.pdf: §6.7.6.2p4: "Variable length arrays are a conditional feature >> that implementations need not support;" > > Hmm... and here I sit, trying hard as I can not to ask "They did ... > WHAT?" Guess I'll have to dig me up a C11 Rationale, then. There isn't one, yet, I gather. The document that proposed the change is available to the public (though I have no idea which document it is) and probably contains an argument in favor of that change. However, the rationale is fairly straightforward: the number of fairly important C compilers that have never bothered to fully implement VLAs. There were very few fully-conforming implementations of C99, and VLAs were one of the reasons. The committee wanted to do something to change that with C2011. They have no power to give implementors greater incentives to conform, so they took the alternative route of lowering the requirements for full conformance.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-08-16 11:04 -0700 |
| Message-ID | <lnzk5upvc3.fsf@nuthaus.mib.org> |
| In reply to | #1501 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 08/16/2012 01:20 PM, Hans-Bernhard Bröker wrote:
>> On 15.08.2012 23:18, James Kuyper wrote:
>>> On 08/15/2012 04:52 PM, Hans-Bernhard Bröker wrote:
>>>> On 15.08.2012 22:00, John Nagle wrote:
>>>>> VLAs are already an optional feature in the current C standard draft.
>>
>>>> Given they were a _non_-optional feature of the previous actual standard
>>>> of 1999, I'd like a draft number, chapter and verse before I believe that.
>>
>>> n1570.pdf: §6.7.6.2p4: "Variable length arrays are a conditional feature
>>> that implementations need not support;"
>>
>> Hmm... and here I sit, trying hard as I can not to ask "They did ...
>> WHAT?" Guess I'll have to dig me up a C11 Rationale, then.
>
> There isn't one, yet, I gather. The document that proposed the change is
> available to the public (though I have no idea which document it is) and
> probably contains an argument in favor of that change. However, the
> rationale is fairly straightforward: the number of fairly important C
> compilers that have never bothered to fully implement VLAs. There were
> very few fully-conforming implementations of C99, and VLAs were one of
> the reasons. The committee wanted to do something to change that with
> C2011. They have no power to give implementors greater incentives to
> conform, so they took the alternative route of lowering the requirements
> for full conformance.
Were there any compilers that didn't support VLAs whose authors
expressed any interest in supporting C99? Microsoft's C compiler
doesn't support VLAs, but it neither does it support mixing declarations
and statements within a block (as of Microsft Visual C++ 2010 Express).
Presumably making VLAs optional won't make any difference in what
Microsoft decides to do.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.std.c
csiph-web