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

621–630 of 978 posts

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

#621

Post by napsy »

quelsolaar wrote: post #615
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.

Arrays are pointers. If they aren't pointers then you need to copy the data when you are giving an array as a function parameter. that's a lot slower. Being able to prepare an set of data in an array and then giving a pointer to a function is very useful. You could add a second type of array on top of what you have in C that includes more stuff, but if that's what you want you can implement that yourself with a struc…

An array is not a pointer. These are completely different data types. For example, you can't apply pointer arithmetic to arrays without casting them to pointers.

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

#622

Post by quelsolaar »

DougGwyn wrote: post #345
axelf4 wrote: post #314

In C89 is there a portable way to figure out the alignment requirement for a struct, to be able to, say, store it after the NUL terminator in the same allocation as a C string?

I'm not sure what your requirement is. Usually things work out if you're careful not to assume any specific value for alignment etc. It may mean a few unused bytes here and there, but keeping things simple and portable often pays off.

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.

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

#623

Post by clarry »

jhallenworld wrote: post #79
sgawlik wrote: post #15

When you're looking at an unfamiliar C code base for the first time, how do you approach it? Which files do you look for? Which tools to you open up immediately?

cscope can help

Is there a vim-style cscope interface for emacs? I hate that xcscope brings up its own persistent buffers (replacing other buffers that I had deliberately placed on the screen). Vim, conveniently, just pops up the cscope interface when I need to enter some input, and then hides it away. Also I don't think xcscope works with evil's tag stack whereas in vim, I believe, you can just return to where you were with ^T, whether using ctags or cscope.

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

#624

Post by DougGwyn »

dhhwrongagain wrote: post #575

Is memset(malloc(0), 0, 0) undefined behavior?

Let's assume the types have been corrected. malloc((size_t)0) behavior is defined by the implementation; there are two choices: (a) always returns a null pointer; or (b) acts like malloc((size_t)1) which can allocate or fail, and if it allocates then the program shall not try to reference anything through the returned non-null pointer. Now, memset itself is required (among other things) to be given as its first argument a valid pointer to a byte array. In particular, it shall not be a null pointer. Tracking through the conformance requirements, if the malloc call returns a null pointer then the behavior is undefined. Thus, you should not program like this.

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

#625

Post by WalterBright »

napsy wrote: post #621
quelsolaar wrote: post #615

Earlier quoted context omitted.

Arrays are pointers. If they aren't pointers then you need to copy the data when you are giving an array as a function parameter. that's a lot slower. Being able to prepare an set of data in an array and then giving a pointer to a function is very useful. You could add a second type of array on top of what you have in C that includes more stuff, but if that's what you want you can implement that yourself with a struc…

An array is not a pointer. These are completely different data types. For example, you can't apply pointer arithmetic to arrays without casting them to pointers.

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

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

#626

Post by begriffs »

What does the presence or absence of __STDC_ISO_10646__ indicate exactly? I found this part of the C99 spec obscure.

For instance, the macOS clang environment does not define this symbol. Is their implementation of wchar_t or lacking some aspect of Unicode support?

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

#627

Post by quelsolaar »

clarry wrote: post #616
quelsolaar wrote: post #603

A few proposals: Why not mandate a warning every time the compiler detects and makes use of UB? It would solve SO many issues. If you are looking to improve security of C programs, then letting the user know what the compiler does should be number one. Try to convert as many UB's to Platform specific, as possible would also be a big help. I would love to see native vector types. Its time. Vector types are now more co…

> Why not mandate a warning every time the compiler detects and makes use of UB? It would solve SO many issues. Because that's hardly ever what happens, except when it actually does, and compilers do an increasingly good job of issuing diagnostics in that case. If you actually mandated it, no compiler today would come close to being standards compliant. This comes close to making the language unimplementable. The mos…

They need to do better then remove NULL checks silently. You can read all about Linus rants on this. Every time the compiler breaks things they blame the C standard for letting them do what ever. Thats whats wrong with C today. The C standard hasn't put its foot down.

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

#628

Post by JoeAltmaier »

btilly wrote: post #576
JoeAltmaier wrote: post #537

Earlier quoted context omitted.

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.

That example absolutely was overflow. The bug is, "assert(int+100 > int) optimized away". GCC has the behavior that overflowing a signed integer gives you a negative one. But an if tests that TESTS for that is optimized away! The reason is that overflow is undefined behavior, and therefore they are within their rights to do anything that they want. So they actually overflow in the fastest way possible, and optimize c…

Sure. Sorry, I was ambiguous. The earlier example of ++i in a loop I was thinking of. Anyway, yes, overflow for small ints is a real thing.

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

#630

Post by JoeAltmaier »

napsy wrote: post #621
quelsolaar wrote: post #615

Earlier quoted context omitted.

Arrays are pointers. If they aren't pointers then you need to copy the data when you are giving an array as a function parameter. that's a lot slower. Being able to prepare an set of data in an array and then giving a pointer to a function is very useful. You could add a second type of array on top of what you have in C that includes more stuff, but if that's what you want you can implement that yourself with a struc…

An array is not a pointer. These are completely different data types. For example, you can't apply pointer arithmetic to arrays without casting them to pointers.

Sure you can. int aFoo[]; has many legal array operations possible:

  *(aFoo+3) should work fine and return the 4th int in the array.
Post reply on HN