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

51–60 of 978 posts

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

#51

Post by rseacord »

rseacord wrote: post #43
rseacord wrote: post #37

Earlier quoted context omitted.

No one has proposed making these standard. I doubt they would gain much support as they are similar to the Annex K Bounds Checked Interface functions strcpy_s and strcat_s but not quite as good IMHO.

There were a number of recent proposals to adopt various POSIX functions by Martin Sebor into C including: N2353 2019/03/17 Sebor, Add strdup and strndup to C2X N2352 2019/03/17 Sebor, Add stpcpy, and stpncpy to C2X N2351 2019/03/17 Sebor, Add strnlen to C2X He is lurking on this thread as well. These proposals can all be found in the document log at http://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log...

The results (from the minutes http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2377.pdf)

6.33 Sebor, Add strnlen to C2X [N 2351] Result: No consensus on putting N2351 into C2X.

6.34 Sebor, Add stpcpy, and stpncpy to C2X [N 2352] Result: No consensus to put N2352 into C2X.

6.35 Sebor, Add strdup and strndup to C2X [N 2353] Result: N2353 be put into C2X. The committee wants a proposal for the wide character versions of any POSIX functions voted in this meeting.

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

#52

Post by AaronBallman »

pantalaimon wrote: post #23

Will C eventually get something like C++' constexpr?

C has some basic support for constant expressions already, but there has not yet been a proposal to bring 'constexpr' over from C++. Personally, I would love this feature to be in C!

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

#55

Post by beefhash »

C has been making strides towards complete Unicode support. I've been having trouble following along though: Am I correct in assuming that there's no actual multi-byte UTF-8 to UTF-32 Rune function and the best approximation depends on whatever wchar_t is? How would I best handle pure Unicode input and output scenarios on a "hostile" OS whose native character encoding is some EBCDIC abomination or a Windows codepage?

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

#57

Post by AaronBallman »

beefhash wrote: post #49
shric wrote: post #47

Is there a rule that any new proposals must already be a feature in an existing major implementation?

(Not one of the OPs:) Wasn't C11 Annex K, the notoriously failed bounds-checking interfaces, a example of not having an existing implementation?

Annex K had an existing implementation from Microsoft. It wasn't a fully conforming implementation when C11 shipped, however (the specification drifted apart from the initial implementation).

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

#58

Post by Daemon404 »

What has been the rationale or hinderance for not adding locale-independent versions of various stdlib functions?

Practically every second C codebase on earth has their own implementations of these at some point, and it remains a huge problem for e.g. writers of libraries, where you don't know how/where your library will be used.

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

#59

Post by stephencanon »

rbultje wrote: post #38

I'd love your opinion on the abundance of "undefined behaviour" (as opposed to implementation-defined, or some new incantation such as "unknown result in variable but system is safe") for relatively trivial things such as signed (but not unsigned) integer overflows. I've heard that this is to allow for non-twos-complement implementations. However, in practice, you notice that most people use ugly workarounds which le…

> (because of e.g. casting to unsigned and allowing the same overflow to happen anyway) only work correctly on twos-complement anyway

Unsigned arithmetic never overflows, and guarantees two's-complement behavior, because unsigned arithmetic is always carried out modulo 2^n:

> A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. (6.2.5, Types)

Doing the computation in unsigned always does the "right thing"; the thing that one needs to be careful of with this approach is the conversion of the final result back to the desired signed type (which is very easy to get subtly wrong).

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

#60

Post by teleonorax »

rseacord wrote: post #37
teleonorax wrote: post #26

What's up with `strlcpy` and `strlcat`? Are they getting standardized?

No one has proposed making these standard. I doubt they would gain much support as they are similar to the Annex K Bounds Checked Interface functions strcpy_s and strcat_s but not quite as good IMHO.

> similar to the Annex K Bounds Checked Interface functions strcpy_s and strcat_s but not quite as good IMHO.

Err... I thought Annex K is deprecated and dead? Whereas strl* seem very much alive, some compilers even give a "strcpy/strncpy is unsafe, use strlcpy instead" warning.

Post reply on HN