Massacring C Pointers

Post by beefhash » Tue, Jun 26, 2018, 5:04 PM UTC

ChrisSD wrote: post #47

saagarjha wrote: post #25

Earlier quoted context omitted.

I take it you come from a higher level language, where null termination would seem risky. In C, however, strlen is considered safe (as opposed to say strcpy, strcat, etc. which do have "safe" replacements). As for terse examples being given to beginners, here's the example The C Programming Language gives for strcpy: void strcpy(char *s, char *t) { while ((*s++ = *t++) != '\0') ; }

C11 introduced strnlen_s, a "safe" replacement to strlen.

Post by mayankkaizen » Tue, Jun 26, 2018, 5:12 PM UTC

delhanty wrote: post #121

waffle_ss wrote: post #58

I was going to ask if any attempt was made to reach the book author for comment, but it looks like he died in 2007. RIP. https://www.findagrave.com/memorial/29007415/robert-joseph-t...

It appears that someone having read your comment here has left a horribly abusive comment on that memorial page now under the handle "Screw You Bob". > ... The Hacker News army is here. "Screw You Bob" you do not speak for me. Hopefully, you don't speak for many people on HN. Words fail me. Can't we let the dead rest in peace?

Post by bitL » Tue, Jun 26, 2018, 5:17 PM UTC

mannykannot wrote: post #182

bitL wrote: post #172

Earlier quoted context omitted.

I was a kid back then; K&R was pretty hard to find in my area and it was quite outdated anyway, most people were happy to use whatever resources they could get; the best in mid-to-late 90s ended up things like what DJ Delorie wrote, stuff from John Carmack, Dave Eberly etc. that were pretty low on rigor but very high on practical value.

You are defending 'Mastering C Pointers' on the grounds that K&R was outdated ?

Post by jschwartzi » Tue, Jun 26, 2018, 5:22 PM UTC

simias wrote: post #115

jmts wrote: post #110

Earlier quoted context omitted.

Documented behaviour is a little different to "effectively broken". The difference between strncpy and strlcpy is that strlcpy will NUL terminate the last byte for you always. There is nothing stopping you from doing the same thing yourself when you use strncpy. If you care enough, write your own strlcpy - it's only one extra line.

I'm not saying it's hard to work around but I maintain it's broken. You have a function that deals with C-string that in some conditions returns something that's not a C-string but can't be trivially distinguished from one and will trigger undefined behavior if used like one. It's terrible ergonomics and almost certainly not what you want to do in any situation. You can argue that truncation is an error condition but…

Post by blt » Tue, Jun 26, 2018, 5:27 PM UTC

minipci1321 wrote: post #35

leodeid wrote: post #17

Earlier quoted context omitted.

I haven't touched C in years, but here's my descending "wtf" list: 1. Returns pointer to stack-allocated data, which immediately becomes invalid. Instead, it should be using some sort of allocation (e.g. 'malloc'), or taking in a destination pointer. 2. 'r' is arbitrarily set with length 100. Smaller strings don't need all that space, and larger strings definitely will overrun. 3. The function signature is really awk…

> 5. 'strcpy' should usually be replaced by 'strncpy'... That prevents a class of exploitable errors known as "buffer overruns". To be honest, strncpy is barely better in this respect (as a security improvement) - truncating against arbitrary size limit in this day and age of text-only protocols... I wonder if outright crashing at the testing stage would be preferable rather than subtle misbehavior creeping into the…