Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

651–660 of 978 posts

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

#651

Post by quelsolaar »

DougGwyn wrote: post #636
quelsolaar wrote: post #622

Earlier quoted context omitted.

Being able to know your alignments is VERY important for a lot of network implementations. They are all defined by the ABIs, but its very annoying that the standard keeps thinking that alignment is unknowable, when in fact its impossible to implement a ABI without defining it. One of the reasons I stick to C89.

Note that the ABIs cover endianness as well as value range and/or object widths. In general, one needs to have explicit marshaling and unmarshaling functions to map from network octet array and C internal data representation. Failure to get this right is (or used to be) a common bug for code developed and tested on too few architectures.

Sure, it wont be portable between any architectures, but a lot of times you know you will be on a little endian platform where types are aligned to their sizeofs. That covers a lot of ground and the performance gains you get from optimizing with this in mind is significant. There is value in C being able to be portable, but there is also a huge value in being able to write non-portable code that takes advantage of what you know about the platform. C needs to acknowledge that that is a legitimate use case.

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

#652

Post by wklieber »

stephencanon wrote: post #503
wklieber wrote: post #500

Earlier quoted context omitted.

>the original homogeneous operations (__builtin_smull_overflow, etc) led to very substantial correctness bugs when users had to pick a single common type for the operation and add conversions. Hi Stephen, thank you for bringing this to our attention. David Svoboda and I are now working to revise the proposal to add a supplemental proposal to support operations on heterogeneous types. We are leaning toward proposing a…

Glad to hear it, looking forward to seeing what you come up with! The question becomes, once you have the heterogeneous operations, is there any reason to keep the others around (my experience is that they simply become a distraction / attractive nuisance, and we're better off without them, but there may be use cases I haven't thought of that justify their inclusion).

When David and I are done revising the proposal, we would like to send you a copy. If you would be interested in reviewing, can you please let us know how to get in touch with you? David and I can be reached at {svoboda,weklieber} @ cert.org.

>once you have the heterogeneous operations, is there any reason to keep the others around

The two-argument form is shorter, but perhaps that isn't a strong enough reason to keep it. Also, requiring a redundant 3rd argument can provide an opportunity for mistakes to happen if it gets out of sync with the type of first two arguments.

As for the non-generic functions (e.g., ckd_int_add, ckd_ulong_add, etc.), we are considering removing them in favor of having only the generic function-like macros.

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

#653

Post by eska »

There's a compiler attribute in GCC to promise that a function is pure, i.e. free from side effects and only uses its inputs.

This is useful for parallel computations, optimizations and readability, e.g.

   sum += f(2);
   sum += f(2);
can be optimized to

   x = f(2);
   sum += x;
   sum += x;
Would the current motto of the consortium forbid adding a feature such as marking a function as pure, that would not just promise, but also enforce that no side effects are caused (only local reads/writes, only pure functions may be called), and no inputs except for the function arguments are used?

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

#654

Post by kazinator »

twic wrote: post #608
kazinator wrote: post #424

Earlier quoted context omitted.

The C family has already evolved in this direction decades ago. Have you heard of C++ (Cee Plus Plus)? It is production-ready; if you want a dialect of C with arrays that know their length, you can use C++. If you wanted a dialect of C in 1993 with arrays that know their length for use in a production app you could also have used C++ then. The problem with all these "can we add X to C" is that there is always an impl…

> if you want a dialect of C with arrays that know their length, you can use C++ C++ doesn't have arrays which know their length.

C++ has features in its syntax so that you can write objects that behave like arrays: support [] indexing via operator [], and can be passed around (according to whatever ownershihp discipline you want: duplication, reference counting). C++ provides such objects in its standard library, such as: std::basic_string and std::vector. There is a newer std::array also.

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

#656

Post by _kst_ »

napsy wrote: post #639
WalterBright wrote: post #625

Earlier quoted context omitted.

That's right. They are converted to pointers when passed to a function, even if the function declares the parameter as an array.

They're not converted but can be implicitly casted to pointer types.

No, they're converted. There is no such thing as an "implicit cast". And it's not specific to arguments in function calls.

Array types and pointer types are distinct.

An expression of array type is, in most but not all contexts, implicitly converted (really more of a compile-time adjustment) to an expression of pointer type that yields the address of the 0th element of the array object. The exceptions are when the array expression is the operand of a unary & (address-of) or sizeof operator, or when it's a string literal in an initializer used to initialize an array (sub)object. (The N1570 draft incorrectly lists _Alignof as another exception. In fact, _Alignof can only take a parenthesized type name as its operand.)

If you do:

    int arr[10];
    some_func(arr);
then arr is "converted" to the equivalent of &arr[0] -- not because it's an argument in a function call, but because it's not in one of the three contexts listed above in which the conversion doesn't take place.

Another rule that causes confusion here is that if you define a function parameter with an array type, it's treated as a pointer parameter. For example, these declarations are exactly equivalent:

    void func(int arr[]);
    void func(int arr[42]); // the 42 is quietly ignored
    void func(int *arr);
Suggested reading: http://www.c-faq.com/, particularly section 6, "Arrays and Pointers".

A conversion converts a value of one type to another type (possibly the same one). The term "cast" refers only to an explicit conversion, one specified by a cast operator (a parenthesized type name preceding the expression to be converted, like "(double)42"). An implicit conversion is one that isn't specified by a cast operator.

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

#657

Post by 0xDEEPFAC »

DougGwyn wrote: post #631
0xDEEPFAC wrote: post #534

Earlier quoted context omitted.

I disagree that this would be a "breaking" change as many people have already resorted to using extra () and such a change might actually may "fix" broken code which makes the reasonable assumption that things like == have a higher-order. https://ericlippert.com/2020/02/27/hundred-year-mistakes/ int x = 0, y = 1, z = 0; int r = (x & y) == z; // 1 int s = x & (y == z); // 0 int t = x & y == z; // 0 UGH

If you're using parentheses, as has been recommended for decades, there is no problem. Otherwise, it is likely that such a change would adversely impact previously working code. There just isn't a pressing need to change it.

Besides the fact that its unintuitive and could lead to low-level or hard-to-find bugs?

It seems to me that C would benefit greatly to iron over its many inconsistencies and exactly the kind of thing people expect in new revisions of the language.

Also, I dont see how it would impact previous working code when compilers already do things like allow selections between versions of languages a la C99, C2x, etc. Users could just avoid the new version if they don't feel like changing.

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

#658

Post by DougGwyn »

hsivonen wrote: post #618
DougGwyn wrote: post #572

Earlier quoted context omitted.

isdigit is likely to remain, because much existing code does use it (perhaps in different contexts from the one you cited). If you need a different function specification to do something different, it could be added in a future release, but that doesn't mean that we need to force programmers to change their existing code.

Does there exist a use case in portable code such that use of isdigit is not a bug? How does the committee view non-portable existing code generally when considering changes?

Code can be non-portable for various reasons, not all of them bad. I just grepped a recent release of DWB and found about 100 uses of isdigit, most of which were not input from random text but rather were used internally, such as "register" names (limited to a specified range). Other packages are likely to have similar usage patterns. I really don't want to have to edit that code just for aesthetics.

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

#659

Post by AaronBallman »

blocks_plz wrote: post #261

Thanks for the AMA 1. Will the Apple's Blocks extension, which allows creation of Closures and Lambda functions, be included in C2X? 2. Are there any plans to improve the _Generic interface (to make it easy to switch on multiple arguements, etc.)?

> 1. Will the Apple's Blocks extension, which allows creation of Closures and Lambda functions, be included in C2X?

We haven't seen a proposal to add them to C2x, yet. However, there has been some interest within the committee regarding the idea, so I think such a proposal could have some support.

> 2. Are there any plans to improve the _Generic interface (to make it easy to switch on multiple arguements, etc.)?

I haven't seen any such plans, but there is some awareness that _Generic can be hard to use, especially as you try to compose generic operations together.

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

#660

Post by _kst_ »

commandersaki wrote: post #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 deriv…

Pointer equality (the == and != operators) is well defined for any pointers (of the same type) to any objects.

Relational operators ( >=) on pointers have undefined behavior unless both pointers point to elements of the same array object or just past the end of it. A single non-array object is treated as a 1-element array for this purpose.

(That's for object pointers. Function pointers can be compared for equality, but relational operators on function pointers are invalid.)

Post reply on HN