diff options
author | Eli Bendersky <eliben@gmail.com> | 2012-12-28 13:52:48 -0800 |
---|---|---|
committer | Eli Bendersky <eliben@gmail.com> | 2012-12-28 13:52:48 -0800 |
commit | 1311cde1f0d9adb97eaa3cf655aee4e01998c266 (patch) | |
tree | 6dec9a5135c7ee4cbb8a90dee9b2fd87a32b48b9 /README.rst | |
parent | 1b778a7e3c656ce7196451455ea61b734c5e829c (diff) | |
download | pycparser-1311cde1f0d9adb97eaa3cf655aee4e01998c266.tar.gz |
Fix typo (issue #4) and update TODO
Diffstat (limited to 'README.rst')
-rw-r--r-- | README.rst | 2 |
1 files changed, 1 insertions, 1 deletions
@@ -97,7 +97,7 @@ What about the standard C library headers? C code almost always includes various header files from the standard C library, like ``stdio.h``. While, with some effort, ``pycparser`` can be made to parse the standard headers from any C compiler, it's much simpler to use the provided "fake" standard includes in ``utils/fake_libc_include``. These are standard C header files that contain only the bare necessities to allow valid parsing of the files that use them. As a bonus, since they're minimal, it can significantly improve the performance of parsing large C files.
-The key point to understand here is that ``pycparser`` doesn't really care aabout the semantics of types. It only needs to know whether some token encountered in the source is a previously defined type. This is essential in order to be able to parse C correctly.
+The key point to understand here is that ``pycparser`` doesn't really care about the semantics of types. It only needs to know whether some token encountered in the source is a previously defined type. This is essential in order to be able to parse C correctly.
See the ``using_cpp_libc.py`` example for more details.
|