Re: Request for comments on language extension: Safe arrays and pointers for C.
On Fri, 31 Aug 2012, John Nagle wrote: > On 8/31/2012 3:32 PM, Joseph S. Myers wrote: > > My comments are: > > > > * TL;DR. > >Then, perhaps, commenting is premature. The alternative would have been to ignore your message completely (having already concluded based on the initial comp.std.c discussion that there was unlikely to be much of interest here); it seemed better to give outline thoughts about the deficiencies of the proposal and why we can't give sensible effort estimates. > > * No specification given at the level of edits to C11. > >That's correct. This is still an informal proposal. Our experience is that extensions that have only been described informally are especially likely to be problematic; they need specifications at the level of standard edits, carefully developed with experience of C standards work. Adding references to C would likely have consequences throughout the entire language standard. Producing the proper specification for this would be a large amount of work for someone with extensive expertise in the standard (and in the C++ standard, for comparison), and is prerequisite for producing implementation effort estimates, which as I noted is also a large amount of work. > > * How does this relate to various cases in the secure coding rules > > draft TS (a specification for static analyzers, but should still be > > relevant here if you can point to examples of bad code therein that > > would be detected reliably through use of your proposals)? > >The "Arrays" section of the CERT guide, > https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=263 > is a style guide, not a spec for hard checking. See > "ARR30-C. Do not form or use out of bounds pointers or array subscripts". I'm referring to ISO/IEC draft TS 17961 (e.g. WG14 N1624). > Reading onward to page 17 of the paper, where SAL, Cyclone, and You need to make the compelling, self-contained case from page 1, not page 17. > That may happen, but I'm still getting comments informally at > this point. I'd like to see enough of this implemented in GCC > as an extension that people could try it out. You're welcome to write patches, but we are extremely unlikely to want to put anything as wide-ranging as references for C in the mainline sources without a compelling case in terms of actual standard adoption or widespread use of code using the extension, and unlikely to put in the days or weeks of work required to define the feature properly or produce an implementation design and effort estimates without a much better case made for the feature. -- Joseph S. Myers jos...@codesourcery.com
Re: Request for comments on language extension: Safe arrays and pointers for C.
On Fri, Aug 31, 2012 at 2:55 PM, John Nagle wrote: >We have proposed an extension to C (primarily) and C++ (possibly) > to address buffer overflow prevention. Buffer overflows are still > a huge practical problem in C, and much important code is still > written in C. This is a new approach that may actually work. > > The proposal, > "Safe arrays amd pointers for C, round 2", is here: > > http://www.animats.com/papers/languages/safearraysforc41.pdf > > This has been discussed on Lambda the Ultimate and comp.std.c, > and the flaws found in those discussions have been dealt with. > So far, no one has found a killer reason why this can't work. > > The proposal is to combine the concepts of C variable length > array formal parameters and C++ references. This allows > passing arrays as arrays, rather than pointers. Could you say a little more of why it appears necessary to introduce references into C for this? The reason I'm puzzled is that C already has the ability to pass arrays in a way that preserves their size (just pass the address of the array) -- what is it that references change in this picture that justifies such a radical change? Could we just permit pointer-to-array-of-n elements to convert to pointer-to-array-of-(n-1) elements, and/or provide some way to slice explicitly? Of course to make this succeed you'll need buy-in from implementors and of the standards committee(s), who will need to trust that the other (and therefore that users) will find this worth the cost. It generally takes a lot of work (in terms of robust specification and possibly implementation in a fork of an open source compiler or two) to generate the consensus necessary for a proposal to succeed. Something that might ultimately seek to change or even disallow much existing C code has an even higher bar -- getting an ISO committee to remove existing support is no small achievement (e.g., look at how long gets() persisted). I'd love to see a reduction in the number of buffer overruns that are present in code, but it's an uphill struggle. -- James
Re: [libstdc++] Mis-configure _GLIBCXX_LONG_DOUBLE_COMPAT?
Hello! > I've seen this today both for alpha and s390 cross from x86_64: > > libtool: compile: /home/rth/work/gcc/bld-s390/./gcc/xgcc -shared-libgcc > > -B/home/rth/work/gcc/bld-s390/./gcc -nostdinc++ > > -L/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/src > > -L/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/src/.libs > > -B/home/rth/work/gcc/run-cross/s390x-linux/bin/ > > -B/home/rth/work/gcc/run-cross/s390x-linux/lib/ -isystem > > /home/rth/work/gcc/run-cross/s390x-linux/include -isystem > > /home/rth/work/gcc/run-cross/s390x-linux/sys-include > > -I/home/rth/work/gcc/git-master/libstdc++-v3/../libgcc > > -I/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/include/s390x-linux > > -I/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/include > > -I/home/rth/work/gcc/git-master/libstdc++-v3/libsupc++ > > -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi > > -fdiagnostics-show-location=once -ffunction-sections -fdata-sections > > -frandom-seed=locale-inst.lo -g -O2 -D_GNU_SOURCE -c > > ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc -fPIC > > -DPIC -o loca! le-inst.o > > ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:362:8: > > error: âvoid > > _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES3_S3_RSt8ios_basecRKSs()â > > aliased to undefined symbol > > â_ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES4_S4_RSt8ios_basecRKSsâ > > > > _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES3_S3_RSt8ios_basecRKSs); > > ^ > > ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:329:19: > > note: in definition of macro '_GLIBCXX_LDBL_COMPAT' > >extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) > >^ > > where, given that I've configured --with-long-double-128, appears to have > mis-identified the correct setting of _GLIBCXX_LONG_DOUBLE_COMPAT. > > Is anyone else seeing this? Is this a problem for cross-compile only? > Certainly editing config.h after the fact lets the build complete... No, it also fails on native alphaev68-unknown-linux-gnu compile: ../../../../../gcc-svn/trunk/libstdc++-v3/src/c++98/locale-inst.cc:362:8: error: ‘void _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES3_S3_RSt8ios_basecRKSs()’ aliased to undefined symbol ‘_ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES4_S4_RSt8ios_basecRKSs’ _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES3_S3_RSt8ios_basecRKSs); ^ ../../../../../gcc-svn/trunk/libstdc++-v3/src/c++98/locale-inst.cc:329:19: note: in definition of macro '_GLIBCXX_LDBL_COMPAT' extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) ... and many more ... Uros.
Re: [libstdc++] Mis-configure _GLIBCXX_LONG_DOUBLE_COMPAT?
On Thu, Aug 30, 2012 at 5:16 PM, Richard Henderson wrote: > I've seen this today both for alpha and s390 cross from x86_64: And powerpc64. Steven provided a patch: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00018.html . Thanks, Andrew Pinski > >> libtool: compile: /home/rth/work/gcc/bld-s390/./gcc/xgcc -shared-libgcc >> -B/home/rth/work/gcc/bld-s390/./gcc -nostdinc++ >> -L/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/src >> -L/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/src/.libs >> -B/home/rth/work/gcc/run-cross/s390x-linux/bin/ >> -B/home/rth/work/gcc/run-cross/s390x-linux/lib/ -isystem >> /home/rth/work/gcc/run-cross/s390x-linux/include -isystem >> /home/rth/work/gcc/run-cross/s390x-linux/sys-include >> -I/home/rth/work/gcc/git-master/libstdc++-v3/../libgcc >> -I/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/include/s390x-linux >> -I/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/include >> -I/home/rth/work/gcc/git-master/libstdc++-v3/libsupc++ >> -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi >> -fdiagnostics-show-location=once -ffunction-sections -fdata-sections >> -frandom-seed=locale-inst.lo -g -O2 -D_GNU_SOURCE -c >> ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc -fPIC -DPIC >> -o loca! > le-inst.o > >> ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:362:8: >> error: ‘void >> _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES3_S3_RSt8ios_basecRKSs()’ >> aliased to undefined symbol >> ‘_ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES4_S4_RSt8ios_basecRKSs’ >> >> _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb1EEES3_S3_RSt8ios_basecRKSs); >> ^ >> ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:329:19: >> note: in definition of macro '_GLIBCXX_LDBL_COMPAT' >>extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) >>^ >> ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:360:8: >> error: ‘void >> _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb0EEES3_S3_RSt8ios_basecRKSs()’ >> aliased to undefined symbol >> ‘_ZNKSt17__gnu_cxx_ldbl1289money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb0EEES4_S4_RSt8ios_basecRKSs’ >> >> _ZNKSt9money_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE9_M_insertILb0EEES3_S3_RSt8ios_basecRKSs); >> ^ >> ../../../../../git-master/libstdc++-v3/src/c++98/locale-inst.cc:329:19: >> note: in definition of macro '_GLIBCXX_LDBL_COMPAT' >>extern "C" void ldbl (void) __attribute__ ((alias (#dbl), weak)) >>^ > > where, given that I've configured --with-long-double-128, appears to have > mis-identified the correct setting of _GLIBCXX_LONG_DOUBLE_COMPAT. > > Is anyone else seeing this? Is this a problem for cross-compile only? > Certainly editing config.h after the fact lets the build complete... > > > r~
gcc-4.7-20120901 is now available
Snapshot gcc-4.7-20120901 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120901/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 190849 You'll find: gcc-4.7-20120901.tar.bz2 Complete GCC MD5=f31dda249f7ba623f08cfc895ba85dcd SHA1=435e42429c44c11623a6f7339f33a091b61a4c33 Diffs from 4.7-20120825 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Request for comments on language extension: Safe arrays and pointers for C.
On 9/1/2012 9:59 AM, James Dennett wrote: > On Fri, Aug 31, 2012 at 2:55 PM, John Nagle > wrote: >> We have proposed an extension to C (primarily) and C++ (possibly) >> to address buffer overflow prevention. Buffer overflows are still >> a huge practical problem in C, and much important code is still >> written in C. This is a new approach that may actually work. ... > Could you say a little more of why it appears necessary to introduce > references into C for this? The reason I'm puzzled is that C already > has the ability to pass arrays in a way that preserves their size > (just pass the address of the array) -- what is it that references > change in this picture that justifies such a radical change? Could > we just permit pointer-to-array-of-n elements to convert to > pointer-to-array-of-(n-1) elements, and/or provide some way to slice > explicitly? That's an important point. C99 already has variable-length array parameters: int fn(size_t n, float vec[n]); Unfortunately, when the parameter is received in the function body, per 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.' What this means is that, in the body of the function, "vec" has type "float *", and "sizeof vec" is the size of a pointer. The standard currently requires losing the size of the array. While C99 variable-length array parameters aren't used much (searches of open-source code have failed to find any use cases, Microsoft refuses to implement them, and N1570 makes them optional), these semantics also apply to passing fixed-length arrays: int fn(float vec[4]); As before, "vec" is delivered as "float* vec". The constant case is widely used, and changing the semantics there might silently break existing code that uses "sizeof". We had a go-round on this on comp.std.c, and the conclusion was that changing the semantics of C array passing would break too much. The real reason for using references is that size information is needed in other places than parameters. It's needed in return types, on the left side of assignments, in casts, and in structures. References to arrays have associated information; pointers don't. As for slicing, see "array_slice" in the paper. It's not a built-in; it's a macro that uses "decltype" and a cast to generate the appropriate result type. Personally, I'd like to have a Python-like slicing notation: arr[start:endplus1] but that's not essential to the proposal, so I'm not suggesting it. > Of course to make this succeed you'll need buy-in from implementors > and of the standards committee(s), who will need to trust that the > other (and therefore that users) will find this worth the cost. It > generally takes a lot of work (in terms of robust specification and > possibly implementation in a fork of an open source compiler or two) > to generate the consensus necessary for a proposal to succeed. > Something that might ultimately seek to change or even disallow much > existing C code has an even higher bar -- getting an ISO committee to > remove existing support is no small achievement (e.g., look at how > long gets() persisted). I'd love to see a reduction in the number of > buffer overruns that are present in code, but it's an uphill > struggle. Of course. Support may come from the security community. CERT still reports buffer overflows, usually in C/C++ code, as the single biggest source of vulnerabilities. Vulnerabilities in software are now a public policy level issue. In the last week, software attacks have taken down Saudi Aramco and RasGas, two of the world's largest energy producers. This issue is growing in importance as "info-war" moves from a potential threat to reality. It's now something that has to be fixed. John Nagle
Re: Request for comments on language extension: Safe arrays and pointers for C.
On Sat, Sep 1, 2012 at 8:35 PM, John Nagle wrote:
> On 9/1/2012 9:59 AM, James Dennett wrote:
>> On Fri, Aug 31, 2012 at 2:55 PM, John Nagle
>> wrote:
>>> We have proposed an extension to C (primarily) and C++ (possibly)
>>> to address buffer overflow prevention. Buffer overflows are still
>>> a huge practical problem in C, and much important code is still
>>> written in C. This is a new approach that may actually work.
> ...
>> Could you say a little more of why it appears necessary to introduce
>> references into C for this? The reason I'm puzzled is that C already
>> has the ability to pass arrays in a way that preserves their size
>> (just pass the address of the array) -- what is it that references
>> change in this picture that justifies such a radical change? Could
>> we just permit pointer-to-array-of-n elements to convert to
>> pointer-to-array-of-(n-1) elements, and/or provide some way to slice
>> explicitly?
>
>That's an important point. C99 already has variable-length
> array parameters:
>
> int fn(size_t n, float vec[n]);
>
> Unfortunately, when the parameter is received in the function body,
> per 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.'
>
> What this means is that, in the body of the function,
> "vec" has type "float *", and "sizeof vec" is the size of
> a pointer. The standard currently requires losing the size
> of the array.
>
> While C99 variable-length array parameters aren't used much
> (searches of open-source code have failed to find any use
> cases, Microsoft refuses to implement them, and N1570 makes
> them optional), these semantics also apply to passing
> fixed-length arrays:
>
> int fn(float vec[4]);
>
> As before, "vec" is delivered as "float* vec". The constant
> case is widely used, and changing the semantics there might silently
> break existing code that uses "sizeof". We had a go-round on
> this on comp.std.c, and the conclusion was that changing the
> semantics of C array passing would break too much.
>
> The real reason for using references is that size information
> is needed in other places than parameters. It's needed in
> return types, on the left side of assignments, in casts, and
> in structures. References to arrays have associated information;
> pointers don't.
That's my point/question: pointers to arrays have exactly the same
information associated with them as references to arrays, and exist in
C today (and have existed in C for decades, they're just not used in
conventional idioms). You seem to be asserting something about
pointers that is not true. Granted, the pointer-to-first-element that
an array implicitly decays to in most contexts loses that information,
but that is not a pointer to the array (though for multi-dimensional
arrays, i.e., arrays of arrays, it is a pointer to a subarray and its
type information records the size of that subarray).
A concrete example: Given the declaration
void fn(int (*pointer_to_array)[5]);
inside fn, pointer_to_array has type pointer to array of 5 ints, and
sizeof(*pointer_to_array) is 5*sizeof(int). Callers can't pass in an
array of the wrong size without a cast. Unfortunately right now they
can't even pass in a _larger_ array without a cast, though I think
that would be relatively minor surgery to the languages (C and C++).
A call to fn looks like fn(&array), e.g.,
int main(void) {
int array[5];
fn(&array);
}
Moving to references instead of pointers seems to give little except
avoiding the need to write "&", which C programmers are already
comfortable with.
Maybe what you need is an extension of VLA-like syntax to something more like
void fn(int (*pointer_to_array)[n], size_t n)
though while C has gone down the path of allowing sizeof(variable) to
vary at compile time, C++ has not and would, I expect, be likely to
resist such a change.
-- James
