Live data from Hacker News

Tell HN: C Experts Panel – Ask us anything about C

news.ycombinator.com

431–440 of 978 posts

Re: Tell HN: C Experts Panel – Ask us anything about C

#431

Earlier quoted context omitted.

- In your example there's no guarantee that the length will be accurate, or that the data hasn't been modified independently elsewhere in the program. - In other words you've created a fantastic shoe-gun. One update line missed (either length or data, or data re-used outside the struct) and your "simple" struct is a huge headache, including potential security vulnerabilities. - Re-implementing a common error prone th…

>In your example there's no guarantee that the length will be accurate, or that the data hasn't been modified independently elsewhere in the program. And having a special data-and-length type would make these guarantees... how? You're ultimately going to need to be able to create these objects from bare data and length somehow, so it's a case of garbage-in-garbage-out.

Declaring it with a custom struct:

    int raw_arr[4] = {0,0,0,0};
    struct SmartArray arr;
    arr.length = 4;
    arr.val = raw_arr;
    some_function(arr);
Smart declaration with custom type: (assume that they'll come up with a good syntax)

    smart_int_arr arr[4] = {0,0,0,0};
    some_function(arr);

With the custom struct, it requires the number `4` to be typed twice manually, while in the second it only needs a single input.

Re: Tell HN: C Experts Panel – Ask us anything about C

#432
post #296

Has Annex K been axed yet, and if not, why not?

It has not. The C Committee has taken two votes on this, and in each case, the committee has been equally divided. Without a consensus to change the standard, the status quo wins. Sounds like you don't care for Annex K. What don't you like about it?

I think my complaints are summed up nicely in some of your coauthors' report:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

(1) runtime constraint handler callbacks are a terrible API.

(2) The additional boilerplate doesn't buy us anything — the user can still specify the wrong size.

(3) The Annex invents a feature out of whole cloth, rather than standardizing existing practices. There are no performant real-world implementations that anyone uses. Microsoft's similar functionality is non-standard.

Re: Tell HN: C Experts Panel – Ask us anything about C

#433

It is 2020. You are looking at a series of projects your company has teed up. All are greenfield efforts - no legacy. What would be the attributes of a project that would have you recommend C as the programming language?

For anything embedded you have practically no choice but to use C (or assembly). Same goes for a lot of systems programming, e.g. writing Linux drivers.

Re: Tell HN: C Experts Panel – Ask us anything about C

#435
post #118

Are there any plans to "clean up C"? A lot of effort has been put into alternative languages, which are great, but there is still a lot of momentum with C, and it seems that a lot of improvements that could be done in a backwards compatible way and without introducing much in the way of complexity. For example: - Locking down some categories of "undefined behaviour" to be "implementation defined" instead. - Proper ar…

There are "projects" underway to clean up the spec where it's viewed as either buggy, inconsistent, or underspecified. The atomics and threads sections are a coupled of example. There are efforts to define the behavior in cases where implementations have converged or died out (e.g., twos complement, shifting into the sign bit). There have been no proposals to add new array types and it doesn't seem likely at the core…

>clean up the spec

Would this involve further specification of bitfields? Feel implementation defined nature of bitfields limits potential

Re: Tell HN: C Experts Panel – Ask us anything about C

#436
A few years ago I came across this article Pointers Are More Abstract Than You Might Expect In C [1].

I followed the article which attempted to interpret the C standard and come to a conclusion. The conclusion is:

> The takeaway message is that pointer arithmetic is only defined for pointers pointing into array objects or one past the last element. Comparing pointers for equality is defined if both pointers are derived from the same (multidimensional) array object. Thus, if two pointers point to different array objects, then these array objects must be subaggregates of the same multidimensional array object in order to compare them. Otherwise this leads to undefined behavior.

Based on the above, I arrived at the conclusion after reading this that comparing two distinct malloc()'d pointers for equality itself is undefined behaviour since malloc() is likely to return pointers to distinct objects that are not part of a sub-aggregate object.

I know this is incorrect, but I don't know why I'm wrong.

[1]: https://stefansf.de/post/pointers-are-more-abstract-than-you...

Re: Tell HN: C Experts Panel – Ask us anything about C

#437
post #28

What is the story behind the removal of VLAs from C99 in later revisions?

So I spend a possibly unreasonable amount of time and page space discussing VLAs in the Effective C book. I understand there are some problems with them, but for what it is worth, I really like the feature, particularly when used in function prototype scope.

Re: Tell HN: C Experts Panel – Ask us anything about C

#438

Earlier quoted context omitted.

Thanks for your answers. A related question: this article [0] appears to single out memcpy and memmove as being special regarding effective type. Is it accurate? It seems to be at odds with your suggestion that there's nothing stopping me writing my own memcpy provided I'm careful to use the right types. [0] https://en.cppreference.com/w/c/language/object#Effective_ty...

I think that may be inaccurate -- IIRC, in C, you can do type punning via a union but not memcpy, and in C++ you can do type punning via memcpy but not a union and this incompatibility drives me nuts because it makes inline functions in a header file shared between C and C++ really messy. (Moral of the story: don't pun types.)

The C standard also allows to use memcpy to do type punning:

    If a value is copied into an object having no declared type using memcpy or memmove,
    or is copied as an array of character type, then the effective type of the modified
    object for that access and for subsequent accesses that do not modify the value is
    the effective type of the object from which the value is copied, if it has one
Simply memcpy into a variable (as opposed to dynamically allocated memory).

https://port70.net/~nsz/c/c11/n1570.html#6.5p6

Post reply on HN