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

531–540 of 978 posts

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

#531

Post by hyc_symas »

The standard string library is still pretty bad. This would have been a much better addition for safe strcpy.

Safe strcpy

    char *stecpy(char *d, const char *s, const char *e)
    {
     while (d
Existing solutions are still error-prone, requiring continual recalculation of buffer len after each use in a long sequence, when the only thing that matters is where the buffer ends, which is effectively a constant across multiple calls.

What are the chances of getting something like this added to the standard library?

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

#532

Post by dang »

ori_b wrote: post #491

What do you think of a variant on this? https://blog.regehr.org/archives/1180

pascal_cuoq cowrote it. Maybe we should ask him if his views have changed since then.

Btw, there was a thread about it at the time: https://news.ycombinator.com/item?id=8233484.

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

#533

Post by rurban »

1. When will we get proper strings in the stdlib?

2. When we will get the Secure Annex K extensions?

3. When we will get mandatory warnings when the compiler decides to throw away statements it thinks it doesn't need? Like memset or assignments. Compilers are getting worse and worse, and certainly not better.

ad 1) Strings are Unicode nowadays, not ASCII. Nobody uses wchar but Microsoft. Everybody else is using utf8, but there's nothing in the standard. Not even search functions with proper casing rules and normalization. Searching for strings should be pretty basic enough.

2. The usual glibc answer is just bollocks. You either do compile-time bounds checks or you don't. But when you don't, you have to do it at runtime. So it's either the compilers job, or the stdlib job. But certainly not the users.

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

#534

Post by 0xDEEPFAC »

rseacord wrote: post #74
0xDEEPFAC wrote: post #70

Dear god, is the precedence of the "&" operator ever going to be fixed?

I can't imagine it will ever be changed, since this would be a breaking change to the language.

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

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

#535

Post by sramsay »

AaronBallman wrote: post #46
teleonorax wrote: post #26

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

We've been considering proposals to add common POSIX APIs into C, but I don't believe we've seen a proposal for strlcpy or strlcat yet. I recall we agreed to add strdup to C given its wide availability and usage.

strdup seems like a perfect example of "standardizing existing practice." And it has never struck me as running against the spirit of C.

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

#536

Post by DougGwyn »

tzs wrote: post #466

If an old timer who used to be good with C wanted to use C again, would they have to learn a whole bunch of weird new stuff or could they pretty much use it like they did back in the stone age (i.e., the 20th century)? Back in the '80s and '90s I was pretty good at C. I don't think there was anything about the language or the compilers than that I did not understand. I used C to write real time multitasking kernels f…

The main editing needed to bring "old C" source code up to snuff using a "modern C" compiler is to make sure that the standard header-defined types are used. No more assuming that a lot of things are, by default, int type. A second, related editing pass is to make sure all functions are declared as prototypes, no longer K&R style; K&R style is slated to be deprecated by the next version of the Standard. (There are some rare uses for non-prototyped functions, but evidently the committee thinks there is more benefit in forcing prototypes.)

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

#537

Post by JoeAltmaier »

btilly wrote: post #510
JoeAltmaier wrote: post #319

Earlier quoted context omitted.

Is this a real concern, beyond 'experts panel' esoteric discussion? Do folks really put a number into an int, that is sometimes going to need to be exactly TYPE_MAX but no larger? I've gone a lifetime programming, and this kind of stuff never, ever matters one iota.

Yes, people really do care about overflow. Because it gets used in security checks, and if they don't understand the behavior then their security checks don't do what they expected. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475 shows someone going hyperbolic over the issue. The technical arguments favor the GCC maintainers. However I prefer the position of the person going hyperbolic.

That example was not 'overflow'. It was 'off by one'? That seems uninteresting, outside as you say the security issue where somebody might take advantage of it.

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

#538

Post by rseacord »

rurban wrote: post #533

1. When will we get proper strings in the stdlib? 2. When we will get the Secure Annex K extensions? 3. When we will get mandatory warnings when the compiler decides to throw away statements it thinks it doesn't need? Like memset or assignments. Compilers are getting worse and worse, and certainly not better. ad 1) Strings are Unicode nowadays, not ASCII. Nobody uses wchar but Microsoft. Everybody else is using utf8,…

Going to try to answer these separately. For (1) if you mean strings that are primitive types my guess is never. When had an hour discussion on this topic at a London meeting where we were discussing new features for C11 and my take away was that this would never happen because it would require a significant change to the memory model for the language.

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

#539

Post by DougGwyn »

hyc_symas wrote: post #513
rseacord wrote: post #160

Earlier quoted context omitted.

There was a proposal for a checked integer type that you might want to look at: N2466 2020/02/09 Svoboda, Towards Integer Safety http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2466.pdf The committee asked the proposers for further work on this effort. Integer types that saturate are an interesting idea. Because signed integer overflow is undefined behavior, implementations are not prohibited from implementing satur…

Eh? I thought that would only be "legal" if it was specified to be implementation-defined behavior. Which would, frankly, be perfectly good. But since it is specified as undefined behavior, programmers are forbidden to use it, and compilers assume it doesn't happen/doesn't exist. The entire notion that "since this is undefined behavior it does not exist" is the biggest fallacy in modern compilers.

The rule is: If you want your program to conform to the C Standard, then (among other things) your program must not cause any case of undefined behavior. Thus, if you can arrange so that instances of UB will not occur, it doesn't matter that identical code under different circumstances could fail to conform. The safest thing is to make sure that UB cannot be triggered under any circumstances; that is, defensive programming.
Post reply on HN