Live data from Hacker News

GCC SC approves inclusion of Algol 68 Front End

gcc.gnu.org

111–115 of 115 posts

Re: GCC SC approves inclusion of Algol 68 Front End

#111
post #110

Earlier quoted context omitted.

Then don't allow it to decay: void arr_fn(char (*arr)[15]) { enum { len = sizeof *arr }; printf("len of array: %d\n", len); printf("Got: %.*s\n", len, *arr); } void sptr_fn(char ptr[static 15]) { printf("Got: %s\n", ptr); } int main(void) { char array[15] = "Hello, World!"; arr_fn(&array); sptr_fn(array); return 0; } Using gcc (and similarly clang) removing the '15' from 'array', and allowing it to allocate it as 14…

That is the static trick. The issues as it stands today are: - It is still a warning instead of an error, and we all know how many projects have endless lists of warnings - Only GCC and clang issue such warning, if we want to improve C, security must be imposed to all implementations https://c.godbolt.org/z/fEKzT4WfM

OK - assuming you're referring to 'char ptr[static 15]' as the 'static trick', then yeah - other compilers do not complain.

However the other form 'char (*arr)[15]' has always been available, and is complained of in other compilers.

I believe I remember using it in DOS based C-89 compilers back in the early 90s, possibly also in K&R (via lint) in the 80s.

NB: icc, msvc, mvc complain about the misuse of the traditional version if one adjusts your godbolt example.

Yes one has to build with warnings forcing errors, which takes a bit of work to achieve if the code has previously been built without that.

Re: GCC SC approves inclusion of Algol 68 Front End

#112
post #82

Earlier quoted context omitted.

gcc-rs is far from being usable. If you want to use Rust with gcc-only targets you're probably better off with rustc_codegen_gcc instead.

One could also compile to wasm, and then convert that wasm to C.

It sounds convenient %)

Re: GCC SC approves inclusion of Algol 68 Front End

#113
post #101
post #58

Earlier quoted context omitted.

Proper strings and arrays for starters, instead of being pointers that the programmer is responsible for doing length housekeeping.

Arrays are not pointers and if you do not let them decay to one, they do preserve the length information.

    int arr[4];
    foo(arr);
We can look at this code like it passes an array by reference, but how to pass `arr` by value?

Re: GCC SC approves inclusion of Algol 68 Front End

#114
post #113
post #101

Earlier quoted context omitted.

Arrays are not pointers and if you do not let them decay to one, they do preserve the length information.

int arr[4]; foo(arr); We can look at this code like it passes an array by reference, but how to pass `arr` by value?

You can pass it by value when putting it into a struct. You can also pass a pointer to the array instead of letting it decay.

void foo(int (*arr)[4]);

int arr[4]; foo(&arr);

Re: GCC SC approves inclusion of Algol 68 Front End

#115
post #110

Earlier quoted context omitted.

Then don't allow it to decay: void arr_fn(char (*arr)[15]) { enum { len = sizeof *arr }; printf("len of array: %d\n", len); printf("Got: %.*s\n", len, *arr); } void sptr_fn(char ptr[static 15]) { printf("Got: %s\n", ptr); } int main(void) { char array[15] = "Hello, World!"; arr_fn(&array); sptr_fn(array); return 0; } Using gcc (and similarly clang) removing the '15' from 'array', and allowing it to allocate it as 14…

That is the static trick. The issues as it stands today are: - It is still a warning instead of an error, and we all know how many projects have endless lists of warnings - Only GCC and clang issue such warning, if we want to improve C, security must be imposed to all implementations https://c.godbolt.org/z/fEKzT4WfM

There isn't really much difference between "ignoring warnings" in C and careless use of "unsafe" or "unwrap" in Rust. Once you entered the realm of sloppiness, the programming language will not safe you.

The point is to what extend the tools for safe programming are available. C certainly has gaps, but not having proper arrays is not one of them.

Post reply on HN