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

771–780 of 978 posts

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

#771

Post by jart »

DougGwyn wrote: post #536
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 so…

> but evidently the committee thinks there is more benefit in forcing prototypes

Why?

Consider the following code:

    LetsReconsiderPriorities(n, A)
      int n, A[n];
    {
      return A[n + 1];
    }

    main() {
      static int A[1];
      return LetsReconsiderPriorities(1, A);
    }
Can anyone guess what clang/gcc complain about? They complain about K&R syntax, yet say nothing about the buffer overflow error. Thanks to modern arrays, the overflow can be said to clearly contradict the intentions of the program author. So why aren't compiler authors focusing on that? Rather than showing warnings that I'd say rightfully belong in lint? Note: Same is true with -Wall, [static n], and even [static 1]: compiler complains about language style and ignores real bugs.

I would estimate that roughly 15% of the issues / pull requests that get filed against C language projects are due to these linter errors that accumulated in compilers over the years, based on a quick glance at STB. https://github.com/nothings/stb/issues?q=warning (29 + 132.) / (156 + 794) It's a big obstacle to sharing C code with others. It'd be great if the C Language Committee could ask compiler authors to remove all these distracting warnings like "unused parameter" now that we have amazing tools like runtime sanitizers that deliver real results.

Also, have we considered addressing the prototype problem with the freedom to choose an ILP64 data model instead? How much do prototypes honestly matter in that case? DSO ABI compatibility might be an issue for Linux distros, but it doesn't concern all of us. Also not terribly concerned about 64-bit type promo since 16-bit is usually what fast DSP wants, and the language today doesn't make that easy.

Lastly consider that C was designed at a research laboratory. If there's one thing researchers love to do, it's what I like to call "yolo coding" which is perfectly valid use case of getting experimental / prototyping code written in a way where one needn't care too much about language formalities and best practices. It'd be great if the standards committee acknowledged that as being a legitimate use case (similar to how "high level assembler" is explicitly acknowledged), because future revisions of the language should ideally maintain as much of the original intentions as possible. See also: https://www.lysator.liu.se/c/dmr-on-noalias.html (Note: I think dmr goes too far here, but interesting bit of history to think about, now that everything that isn't char is implicitly noalias!)

In other words, let us choose. Please don't force us.

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

#772

Post by saagarjha »

beefhash wrote: post #281
AaronBallman wrote: post #255

Earlier quoted context omitted.

Correct -- it would be nice if the glibc maintainers would reconsider their opinion of supporting the optional Annex K functionality. There is definitely user demand for the feature.

And every BSD out there. And whatever it is that macOS does. Microsoft looks to be the outlier to me.

macOS is POSIX compliant.

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

#774

Post by memling »

asveikau wrote: post #744
saagarjha wrote: post #728

Earlier quoted context omitted.

Misreads of much less than that have been exploitable in the past.

Depends a lot on the specifics. For example heartbleed was a misread that led to the buffer being sent on the socket. And I think it was more than 32 bits. 32 bits of garbage into a log file that needs privileges to read sounds a tad less scary, but like I say, not out of the question to be harmful.

> Depends a lot on the specifics. For example heartbleed was a misread that led to the buffer being sent on the socket. And I think it was more than 32 bits. 32 bits of garbage into a log file that needs privileges to read sounds a tad less scary, but like I say, not out of the question to be harmful.

If you can do it a lot of times, though, that changes matters.

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

#776

Post by WalterBright »

tropo wrote: post #729
WalterBright wrote: post #590

I wrote about a simple addition to C that could eliminate most buffer overflows: https://www.digitalmars.com/articles/C-biggest-mistake.html I.e. offering a way that arrays won't automatically decay to pointers when passed as a function parameter.

C currently replaces my use of an array with a pointer. This sucks, because I'd have taken the address if I wanted that. Your proposal replaces my use of an array with two things, a pointer (as before) and a length. This is not too helpful, because I already could have done that if I'd wanted to. What is missing is the ability to pass an array. Sometimes I want to toss a few megabytes on the stack. Don't stop me. I s…

> Your proposal replaces my use of an array with two things, a pointer (as before) and a length. This is not too helpful, because I already could have done that if I'd wanted to.

C doesn't have a reasonable way of doing that. I know my proposal works, because we've been using it in D for 20 years.

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

#777

Post by kazinator »

kevin_thibedeau wrote: post #704
zokier wrote: post #650

Earlier quoted context omitted.

What's std::array then? > combines the performance and accessibility of a C-style array with the benefits of a standard container, such as knowing its own size https://en.cppreference.com/w/cpp/container/array

They're objects that mostly behave like arrays. You can't index element two of std::array foo as 1[foo] since it isn't an actual C array.

A Pascal array is just ones and zeros that behave like an array. So is a Fortran array.

> You can't index element two of std::array foo as 1[foo] since it isn't an actual C array.

That's just a silly quirk of C syntax that is deliberately not modeled in C++ operator overloading. It's not a real capability; it doesn't make arrays "do" anything new, so it' hard to call it an array behavior. It's a compiler behavior, that's for sure.

It could easily be added to C++, similarly to the way preincrement and postincrement are represented (which allows that obj++ and ++obj to be separate overloads).

   T &array_class::operator [] (int index) {
      // handles array[42]
   }

   T &array_class::operator [] (int index, int) {  // Fictional!!
      // handles 42[array]
   }
The dummy extra int parameter would mean "this overload of operator [] implements the flipped case, when the object is between the [ ] and the index is on the left".

C++ could easily have this; the technical barrier is almost nonexistent. (I wonder what the minimal diff against GNU C++ would be to get it going.)

I suspect that it's explicitly unwanted.

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

#778

Post by tropo »

rseacord wrote: post #71
emilfihlman wrote: post #36

Thank you for taking time to take questions! Have you ever considered or will you consider deprecating char, int, long, (s)size_t, float, double and etc in favour of specific length types? Will you ever add / have you considered adding [su]\d+ and f\d+ as synonyms for those mentioned stdint.h? Since char is signed on most platforms, arm eabi being an exception and even there it's really just a matter of compile time…

I don't think we'll ever deprecate char, int, long, float, double, or size_t. ssize_t is not part of the C Standard, and hopefully never will be as it is a bit of an abomination. The main driver behind the evolution of the C Standard is not to break existing code written in C, because the world largely runs on C programs. C does provide fixed width types like uint8_t, uint16_t, uint32_t, and uint64_t. These are optio…

Those types should not be optional. CHAR_BIT needs to be 8. It is clearly possible to implement the types even on a 6502 or Alpha. From the early days of pre-ANSI C, the language supported types for which the hardware did not have appropriate word sizes. There was a 32-bit long on the 16-bit PDP-11 hardware.

I would go beyond that, requiring all sizes that are a multiple of 8 bits from 8-bit through 512-bit. This better supports cryptographic keys and vector registers.

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

#779

Post by kevin_thibedeau »

saagarjha wrote: post #738
kevin_thibedeau wrote: post #704

Earlier quoted context omitted.

They're objects that mostly behave like arrays. You can't index element two of std::array foo as 1[foo] since it isn't an actual C array.

Ok, but who actually uses that?

The point is to demonstrate that std::array isn't an array.

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

#780

Post by saagarjha »

kevin_thibedeau wrote: post #779
saagarjha wrote: post #738

Earlier quoted context omitted.

Ok, but who actually uses that?

The point is to demonstrate that std::array isn't an array.

Ok, fair. But for almost all practical purposes, std::array is an appropriate array replacement.
Post reply on HN