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

Banned C standard library functions in Git source code

github.com

Post reply on HN
Print view View original

311–320 of 329 posts

Re: Banned C standard library functions in Git source code

#311

Post by gnulinux »

alister wrote: post #26

I'm glad to see that setjmp() and longjmp() are still allowed. I'm just kidding by the way. For those C programmers who haven't encountered these before, it is a powerful way to do a "goto" in C. Powerful in the sense that you can jump anywhere, not limited to the same function. If it's used at all these days, it's used for exception handling. More info: https://en.wikipedia.org/wiki/Setjmp.h

I had really fun implementing coroutines, (almost-zero cost) exceptions, iterators etc with setjmp and longjmp. I think they're too useful to be banned outright (especially since C has no view on stack) since there are cases where you need to either use them or inline assembly, but I agree that they're the evilest of evilest std C functions.

Re: Banned C standard library functions in Git source code

#312

Post by doboyy »

jstimpfle wrote: post #296
doboyy wrote: post #276

Earlier quoted context omitted.

The thing you are pointing to could have its length prefixed. I've always assumed that this isn't the case because nobody could commit to the size of the length prefix. Is it string8, string16, string32, or string64? Using a sentinel value to denote length is less opinionated and more portable.

And also unbeatable in memory efficiency.

Unfortunately, it's often algorithmically less efficient and more error prone, so everybody ends up replicating what git is doing with 'strbuf' but in slightly incompatible ways. The effect makes dealing with strings in C unnecessarily unpleasant.

Re: Banned C standard library functions in Git source code

#313

Post by saalweachter »

elgenie wrote: post #245
cmroanirgo wrote: post #238

Earlier quoted context omitted.

> 99% ... are better than average. I'm thinking there's a flaw in your mathematics...

99% of the people on Earth have a higher than average number of legs.

And a below-average number of heads.

Re: Banned C standard library functions in Git source code

#314

Post by commandlinefan »

adamnemecek wrote: post #27
stiff wrote: post #11

Looks like Git has its own string type: https://github.com/git/git/blob/master/strbuf.h https://github.com/git/git/blob/master/strbuf.c See this for the story of why strncpy/strncat are insecure: https://en.wikipedia.org/wiki/C_string_handling#Replacements

Like essentially all C programs.

That was my first thought. No strncpy? Ok,

  while (*s1 && n--)  {
    *s2++ = *s1++;
  }
  *s2 = '\0';
it is, then.

Re: Banned C standard library functions in Git source code

#315

Post by thomasjames »

fucking_tragedy wrote: post #212
thomasjames wrote: post #182

Earlier quoted context omitted.

I had only seen them in the context of userspace threading. I wonder what mainstream libs use them. Do you know of any?

Generators are a subset of coroutines, and coroutines are useful in lexing and parsing.

Whoops, I meant that use set/longjmp() to implement coroutines. My wording in retrospect was super unclear. Sorry!

Re: Banned C standard library functions in Git source code

#316

Post by aiCeivi9 »

cmroanirgo wrote: post #238
CamperBob2 wrote: post #194

Earlier quoted context omitted.

Fortunately, 99% of developers, like 99% of drivers, are better than average.

> 99% ... are better than average. I'm thinking there's a flaw in your mathematics...

https://insights.stackoverflow.com/survey/2019#evaluating-co...

> 70% of respondents say they are above average

Re: Banned C standard library functions in Git source code

#317

Post by fwsgonzo »

commandlinefan wrote: post #314
adamnemecek wrote: post #27

Earlier quoted context omitted.

Like essentially all C programs.

That was my first thought. No strncpy? Ok, while (*s1 && n--) { *s2++ = *s1++; } *s2 = '\0'; it is, then.

I don't think strncpy is the function you are looking for, either. Its for zeroing fixed-size character buffers. And it doesn't indicate problems.

https://blog.liw.fi/posts/strncpy/

Re: Banned C standard library functions in Git source code

#318

Post by ConceptJunkie »

Stratoscope wrote: post #269
cmroanirgo wrote: post #238

Earlier quoted context omitted.

> 99% ... are better than average. I'm thinking there's a flaw in your mathematics...

You've never been on a project that was 80% done and 80% to go?

And after the second 80% is finished, then you only have 80% left.

Re: Banned C standard library functions in Git source code

#319

Post by dragonwriter »

cmroanirgo wrote: post #238
CamperBob2 wrote: post #194

Earlier quoted context omitted.

Fortunately, 99% of developers, like 99% of drivers, are better than average.

> 99% ... are better than average. I'm thinking there's a flaw in your mathematics...

Depends which average it refers to any of the means, or the media, or the mode can be “average” (most typically, though, it means the arithmetic mean), and it's only impossible in terms of the median.

Re: Banned C standard library functions in Git source code

#320

Post by nybble41 »

GrumpyYoungMan wrote: post #151
chris_wot wrote: post #92

Earlier quoted context omitted.

I've always wondered why goto is actually considered harmful. I really should read the original paper by Djikstra...

Read David Tribble's "Go To Statement Considered Harmful: A Retrospective" instead: http://david.tribble.com/text/goto.html . It contains the entire text of Dijkstra's paper and goes over its meaning in a modern context on a paragraph-by-paragraph basis. It's very well written and makes clear the "encourages spaghetti code" argument, while true at the time, applied in a era where basic control flow constructs that we…

Thank you for the recommendation; that was a very interesting read. I find that I can't quite agree with the last "nontrivial goto" example, though. This version without explicit gotos is actually shorter, and IMHO not really any more difficult to follow:

    int parse(void)
    {   
      Token tok;
      while ((tok = gettoken()) != END)
      {   
        while (!shift(tok))
          if (!reduce(tok))
            return ERROR;
      }
      return ACCEPT;
    }
I will say that any language without goto, or where the use of goto is discouraged, should at least provide guaranteed tail-call elimination as an alternative. In this case the gotos could easily be converted into loops, but not every algorithm is so accommodating.
Post reply on HN