Article:		What I Hate About Your Programming Language
Subject:		C Nitpick: exec* are not part of the language
Date:		2003-05-13 15:10:45
From:		anonymous2
The exec* family of functions aren't part of the C standard library. They're part of the Unix system library (which is named differently on each platform...). Your beef in this case is with Unix, not the C language.

Showing messages 1 through 3 of 3.

• C Nitpick: exec* are not part of the language
  2003-05-13 15:40:30  chromatic | [View]
  
  
  Good point, thank you. An earlier version of the article mentioned sprintf, snprintf, and friends, but one of the reviewers gave me a good mnemonic to remember them and pointed out exec* and friends, which are harder to remember.
  
  I'm not sure I can make a clear mental separation between C and Unix, though. :)
• C Nitpick: exec* are not part of the language
  2003-05-13 16:35:19  anonymous2 [View]
  
  
  <blockquote>one of the reviewers gave me a good mnemonic</blockquote>
  Care to share?
• C Nitpick: exec* are not part of the language
  2003-05-13 19:08:29  anonymous2 [View]
  
  
  I've never had any difficulty keeping printf, fprintf, sprintf, snprintf, vsprintf, vsnprintf, wsnprintf, etc. straight. For one thing, I almost never use sprintf() because of the possibility of buffer overflows. That aside, it's a pretty common convention in C to use 'n' in a function name to indicate a bounded buffer (strncpy comes to mind). I once saw a laughable use of strncat, though: this programmer evidently thought repeatedly strncat()'ing with the same buffer length would prevent buffer overflows.
  
  What does trip me up from time to time is the difference between fputs() and puts(). I keep expecting the stream (FILE) to come first, although I'm getting better at it. I often have trouble remembering whether putchar() or putc() writes to stdout Sometimes I just wish they wouldn't have these convenient shortcuts, and just make you specify stdout explicitly.