Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git's list of banned C functions

github.com

Post reply on HN
Print view View original

611–620 of 639 posts

Re: Git's list of banned C functions

#611

Post by WalterBright »

JoeAltmaier wrote: post #575
WalterBright wrote: post #533

Earlier quoted context omitted.

1. whenever you see strncpy(), there's a bug in the code. Nobody remembers if the `n` includes the terminating 0 or nor. I implemented it, and I never remember. I always have to look it up. Don't trust your memory on it. Same goes for all the `n` string functions. 2. be aware of all the C string functions that do strlen. Only do strlen once. Then use memcmp, memcpy, memchr. 3. assign strlen result to a const variable…

So many potential pitfalls to string functions. But memcpy and friends can have pitfalls too. I was working on a RISC processor and somebody started using various std lib functions like memcpy from a linux tool chain. I got a bug report - it crashed on certain alignments. Made sense - this processor could only copy words on word alignment etc. So I wrote a test program for memcpy. Copy 0-128 bytes from a source buffe…

The x86 does have a builtin memcpy instruction. But whether it is best to use it or not depends on which iteration of the x86 you're targeting. Sigh.

Re: Git's list of banned C functions

#612

Post by WalterBright »

synergy20 wrote: post #570
WalterBright wrote: post #533

Earlier quoted context omitted.

1. whenever you see strncpy(), there's a bug in the code. Nobody remembers if the `n` includes the terminating 0 or nor. I implemented it, and I never remember. I always have to look it up. Don't trust your memory on it. Same goes for all the `n` string functions. 2. be aware of all the C string functions that do strlen. Only do strlen once. Then use memcmp, memcpy, memchr. 3. assign strlen result to a const variable…

Super insightful list. What will be the alternative for strncpy/strncat? I thought they're a safer strcpy/strcat but now I need something to replace them. I assume snprintf for sprintf, vsnprintf for vsprintf. No idea what to do with gmtime/localtime/ctime/ctime_r/asctime/asctime_r, any alternatives for them too?

My alternative is to do a strlen for each string, then use memcpy memset memchr instead.

> I thought they're a safer strcpy/strcat

Let's look at the documentation for strncpy, from the C Standard:

"The strncpy function copies not more than n characters (characters that follow a null character are not copied) from the array pointed to by s2 to the array pointed to by s1."

There's a subtle gotcha there. It may not result in a 0 terminated string!

"If the array pointed to by s2 is a string that is shorter than n characters, null characters are appended to the copy in the array pointed to by s1, until n characters in all have been written."

A performance problem if you're using a large buffer.

Yeah, always prefer snprintf.

The time functions? I'm just very careful using them.

Re: Git's list of banned C functions

#613

Post by WalterBright »

dotancohen wrote: post #555
WalterBright wrote: post #533

Earlier quoted context omitted.

1. whenever you see strncpy(), there's a bug in the code. Nobody remembers if the `n` includes the terminating 0 or nor. I implemented it, and I never remember. I always have to look it up. Don't trust your memory on it. Same goes for all the `n` string functions. 2. be aware of all the C string functions that do strlen. Only do strlen once. Then use memcmp, memcpy, memchr. 3. assign strlen result to a const variable…

Thank you Walter! I will be sure to internalize this. There are some terrific tips in here, such as using shorter array lengths for debug build and avoiding Thank you, have a great weekend!

char being signed used to be commonplace. But it is allowed by the C Standard, and it's best not to assume one way or the other.

Re: Git's list of banned C functions

#614

Post by IgorPartola »

kaba0 wrote: post #588
scoutt wrote: post #557

Earlier quoted context omitted.

Any runtime security measure produces overhead (array bounds checking, dynamically checked borrow rules like Rust RefCell, etc.), at least in computational cycles. There is no magic formula. Calculating mandelbrot fractals to measure speed might be a nice exercise in which Rust or Zig can compete with C. But in a real software implementation, when you need to open a file you still have to call the OS function fopen()…

Compile time security measures have absolutely no runtime overhead. Also, I don’t see what you mean by File::open — there is a kernel call somewhere there. But if you are writing a new OS you are free to implement the fopen call as you wish - C has no advantage here.

Not all bounds checking can be done at compile time, can it? You can’t check if a file exists on a target system before it is opened at compile time, can you?

Re: Git's list of banned C functions

#615

Post by kiwidrew »

ufo wrote: post #551
moonchild wrote: post #486

Earlier quoted context omitted.

Bounds checking can be done, and it doesn't need any special language features. Tcc does it, as do some of the sanitizers (present in gcc and clang).

Can you bounds check dynamically sized arrays? For example, a function that receives the size as a separate argument? double f(double *xs, int n){ return xs[g()]; }

Yes. In my hypothetical world where the C compiler makes use of the VLA declaration in the function arguments, it would certainly be possible for the compiler to insert automatic bounds checking in this case:

  double f(xs, n)
    double xs[n];
    size_t n;
  {
    size_t _tmp0 = g();   /* temporary var created by compiler */
    assert(_tmp0
The key to making this possible is telling the compiler about the relationship between double* xs and size_t n; once the compiler has the knowledge that the type of xs is double [n] (array of double with first dimension n) it would be able to automatically insert dynamic bounds checks.

Re: Git's list of banned C functions

#616

Post by moonchild »

ufo wrote: post #551
moonchild wrote: post #486

Earlier quoted context omitted.

Bounds checking can be done, and it doesn't need any special language features. Tcc does it, as do some of the sanitizers (present in gcc and clang).

Can you bounds check dynamically sized arrays? For example, a function that receives the size as a separate argument? double f(double *xs, int n){ return xs[g()]; }

> dynamically sized arrays

Yes. What you can't do is associate bounds information with some specific pointer to an array, but this will work, for instance:

  int *x = malloc(2 * sizeof(int));
  x[1]; //ok
  x[2]; //runtime error

Re: Git's list of banned C functions

#617

Post by spacechild1 »

mariusor wrote: post #530
swlkr wrote: post #122

Earlier quoted context omitted.

I'm partial to https://github.com/antirez/sds these days

The only problem I have with antirez's lib is that he didn't make it into a single header library.

Is it so hard to add a single source file to your build system?

If yes, then you can do #include “sds.c“ in some random source file. In fact, that's what so-called header-only libraries in C implicitly do. shudder

Re: Git's list of banned C functions

#618

Post by mariusor »

spacechild1 wrote: post #617
mariusor wrote: post #530

Earlier quoted context omitted.

The only problem I have with antirez's lib is that he didn't make it into a single header library.

Is it so hard to add a single source file to your build system? If yes, then you can do #include “sds.c“ in some random source file. In fact, that's what so-called header-only libraries in C implicitly do. shudder

A C file implies a compilation unit. For the projects I write I like to have a single compilation unit per binary (what's called a unity build). In the case of C, this doesn't bring much speed to the table, but it allows for a simpler build toolchain none the less.

Re: Git's list of banned C functions

#619

Post by MikeTheGreat »

ineedasername wrote: post #479
MikeTheGreat wrote: post #463

Earlier quoted context omitted.

Minor detail: lecturers don't get tenure. The job role of 'professor' may be able to get tenure (I think these roles usually do) but 'lecturer' really means 'full time temporary teacher, with a contract for a specified amount of time.

I occasionally adjunct. What students call me at the beginning of the semester is always awkward: Them: "Hello Professor" Me: "Technically I'm not a professor." Them: "Okay, we'll just call you Doctor." Me: "Yeah, about that... not a doctor either." Them: "So why are we paying you?" Me: "Technically, you're paying the school. And the school is paying me... very little" Them: "Answer the question" Me: "Because I know…

I knew someone who was TA'ing a class back when they were in grad school. I heard a story about him - to get ahead of this uncertainty he gave the class three options for what to call him:

1) 'Steve' (his first name)

2) 'Mr. Wolfman' (his last name)

3) 'Darth Wolfman' (funny, obvious not meant to be taken seriously, option)

Guess what the class overwhelmingly voted for? :)

Re: Git's list of banned C functions

#620

Post by InvOfSmallC »

unixhero wrote: post #511
InvOfSmallC wrote: post #477

Earlier quoted context omitted.

I'm not really const. I'm definitely volatile depending on the budget. It's definitely a side gig.

I need a side gig, for shits and giggles. I miss uni a lot, for the community of it. Would you recommend it?

I love teach students what I know. I would love it to be a full time job. But then I realized I got it due to my work experience so...
Post reply on HN