地角天邊
江郎才盡,不足為訓
https://www.manongbook.com/other/931.html
https://blog.csdn.net/weixin_36692820/article/details/89221923 C++PV6en
vs code setup: https://stackoverflow.com/questions/47872250/cant-compile-code-launch-program-program-path-does-not-exist
g++ f1.cxx f2.cxx -lg++
g++ f1.cxx f2.o -lg++
一，代碼分析工具
gcc -Wall -Werror
https://opensourceforu.com/2017/04/different-c-standards-story-c/
K&R C: 28 keywords
ANSI C=C83=C89=C90，增加const, enum, signed, void 和 volatile
C99：增加 _Bool, _Complex, _Imaginary, inline and restrict. New header files , , , 。 其餘包括long long int和循環中的類型定義：for （int i等。弱化gets，必須支持變長數組。https://www.cs.dartmouth.edu/~cs23/C-intro.pdf http://www.dii.uchile.cl/~daespino/files/Iso_C_1999_definition.pdf
C11：增加_Alignas, _Alignof, _Atomic, _Generic, _Noreturn, _Static_assert and _Thread_local和。取消gets。增加Anonymous structures。變長數組可選。
GnuLib: https://www.gnu.org/software/gnulib/MODULES.html
Embedded C（1998）： Embedded C mostly has the syntax and semantics of normal C with additional features like fixed-point arithmetic, named address spaces, and basic I/O hardware addressing.
A perfect example of such a function is gets(), because there is no way to tell it how big the destination buffer is. Consequently, any program that reads input using gets() has a buffer overflow vulnerability. For similar reasons, one should use strncpy() in place of strcpy() and strncat() in place of strcat().
Yet some more examples include the tmpfile() and mktemp() function due to potential security issues with overwriting temporary files and which are superseded by the more secure mkstemp() function.
Non-Reentrant
Other examples include gethostbyaddr() and gethostbyname() which are non-reentrant (and, therefore, not guaranteed to be threadsafe) and have been superseded by the reentrant getaddrinfo() and freeaddrinfo().
You may be noticing a pattern here... either lack of security (possibly by failing to include enough information in the signature to possibly implement it securely) or non-reentrance are common sources of deprecation.
Outdated, Non-Portable
Some other functions simply become deprecated because they duplicate functionality and are not as portable as other variants. For example, bzero() is deprecated in favor of memset().
Thread Safety and Reentrance
You asked, in your post, about thread safety and reentrance. There is a slight difference. A function is reentrant if it does not use any shared, mutable state. So, for example, if all the information it needs is passed into the function, and any buffers needed are also passed into the function (rather than shared by all calls to the function), then it is reentrant. That means that different threads, by using independent parameters, do not risk accidentally sharing state. Reentrancy is a stronger guarantee than thread safety. A function is thread safe if it can be used by multiple threads concurrently. A function is thread safe if:
- It is reentrant (i.e. it does not share any state between calls), or:
- It is non-reentrant, but it uses synchronization/locking as needed for shared state.
In general, in the Single UNIX Specification and IEEE 1003.1 (i.e. "POSIX"), any function which is not guaranteed to be reentrant is not guaranteed to be thread safe. So, in other words, only functions which are guaranteed to be reentrant may be portably used in multithreaded applications (without external locking). That does not mean, however, that implementations of these standards cannot choose to make a non-reentrant function threadsafe. For example, Linux frequently adds synchronization to non-reentrant functions in order to add a guarantee (beyond that of the Single UNIX Specification) of threadsafety.
Strings (and Memory Buffers, in General)
You also asked if there is some fundamental flaw with strings/arrays. Some might argue that this is the case, but I would argue that no, there is no fundamental flaw in the language. C and C++ require you to pass the length/capacity of an array separately (it is not a ".length" property as in some other languages). This is not a flaw, per-se. Any C and C++ developer can write correct code simply by passing the length as a parameter where needed. The problem is that several APIs that required this information failed to specify it as a parameter. Or assumed that some MAX_BUFFER_SIZE constant would be used. Such APIs have now been deprecated and replaced by alternative APIs that allow the array/buffer/string sizes to be specified.
Scanf (In Answer to Your Last Question)
Personally, I use the C++ iostreams library (std::cin, std::cout, the << and >> operators, std::getline, std::istringstream, std::ostringstream, etc.), so I do not typically deal with that. If I were forced to use pure C, though, I would personally just use fgetc() or getchar() in combination with strtol(), strtoul(), etc. and parse things manually, since I'm not a huge fan of varargs or format strings. That said, to the best of my knowledge, there is no problem with [f]scanf(), [f]printf(), etc. so long as you craft the format strings yourself, you never pass arbitrary format strings or allow user input to be used as format strings, and you use the formatting macros defined in where appropriate. (Note, snprintf() should be used in place of sprintf(), but that has to do with failing to specify the size of the destination buffer and not the use of format strings). I should also point out that, in C++, boost::format provides printf-like formatting without varargs.
To know pointer use: https://cdecl.org/ for example: int (*(*f)())[10]; - declare f as pointer to function returning pointer to array 10 of int
//https://www.onlinegdb.com/online_c_compiler https://repl.it/languages/c
if (*(char*)&x == 1)
printf("Little endiann");
#include
#define f(a,b) a##b
#define g(a) #a
#define h(a) g(a)
int main()
{
printf("%sn",h(f(1,2)));
printf("%sn",g(f(1,2)));
return 0;
}
Just by looking at the program one "might" expect the output to be, the same for both the printf statements. But on running the program you get it as:
bash$ ./a.out
12
f(1,2)
bash$
