Commits

Armin Rigo  committed ad93f68

Fix ReST.

  • Participants
  • Parent commits 8f59353

Comments (0)

Files changed (1)

File doc/design.rst

   primitive, don't need a blob because it's not possible to take their
   raw address.
 
-* It would be possible to add a debug mode: when we cast "struct foo"
-  to "struct foo *" or store it in some other struct, then we would
-  additionally record a weakref to the original "struct foo" blob.
-  If later we try to access the "struct foo *" but the weakref shows
+* It would be possible to add a debug mode: when we cast ``struct foo``
+  to ``struct foo *`` or store it in some other struct, then we would
+  additionally record a weakref to the original ``struct foo`` blob.
+  If later we try to access the ``struct foo *`` but the weakref shows
   that the blob was freed, we complain.  This is a difference with
   ctypes, which in these cases would store a strong reference and
   keep the blob alive.  "Explicit is better than implicit", so we ask
   it may be used (instead of doing the right things in 90% of the cases
   but still crashing in the remaining 10%).
 
-* LuaJIT uses "struct foo &" for a number of things, like for ``p[0]``
-  if ``p`` is a "struct foo *".  I suppose it's not a bad idea at least
+* LuaJIT uses ``struct foo &`` for a number of things, like for ``p[0]``
+  if ``p`` is a ``struct foo *``.  I suppose it's not a bad idea at least
   to have internally such types, even if you can't specify them through
-  pycparser.  Basically "struct foo &" is a type that doesn't own a
-  blob, whereas "struct foo" is the type that does.
+  pycparser.  Basically ``struct foo &`` is a type that doesn't own a
+  blob, whereas ``struct foo`` is the type that does.
 
-* LuaJIT uses "int[?]" which pycparser doesn't accept.  I propose
-  instead to use "int[]" for the same purpose (its use is anyway quite
-  close to the C standard's use of "int[]").
+* LuaJIT uses ``int[?]`` which pycparser doesn't accept.  I propose
+  instead to use ``int[]`` for the same purpose (its use is anyway quite
+  close to the C standard's use of ``int[]``).