db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
@InProceedings{Teig99,
  title =        "{A}nother {S}ide of {SP}o{C}: occam's {ALT}er {E}go {D}issected with {PC}-lint",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  author=        "Teig,  Øyvind",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  editor=        "Cook,  Barry M.",
db_connect: Could not connect to paper db at "wotug@dragon.kent.ac.uk"<br>
  pages =        "19--36",
  booktitle=     "{P}roceedings of {W}o{TUG}-22: {A}rchitectures, {L}anguages and {T}echniques for {C}oncurrent {S}ystems",
  isbn=          "90 5199 480 X",
  year=          "1999",
  month=         "mar",
  abstract=      "26500 lines of Standard C (ANSI C) generated from occam
     sources by the Southampton Portable occam Compiler (SPoC)
     has been analysed by the static analysis tool PC-lint. The
     target machine is a TMS320C32 DSP where all (the supported)
     C\'s primitive data types are mapped to 32 bit read and
     writes. This architecture stretches
     \&amp;quot;ANSI\&amp;quot; C quite a bit, but the
     \&amp;quot;portable\&amp;quot; occam compiler promised to
     handle it. Even if we had experienced no problems with the
     generated code and it compiled with all error handling
     enabled, we had to insert some 15-20 different global
     PC-lint filters plus local filters via in-line C in the
     occam sources. This was in addition to the base-level
     filters we also used for hand-written C. It kept PC-lint
     quiet, for individual C files as well as \&amp;quot;global
     wrap up\&amp;quot;. By discussing each individual filter we
     arrive at the conclusion that none hid errors in the
     generated C. The analysis revealed a few points where the
     occam language definition could have been made stricter. We
     would like to PC-lint the generated sources with fewer
     messages disabled - changes to SPoC are therefore suggested.
     Altogether SPoC seems to have passed this test quite well.
     Even if we have no expertise to modify the (open) SPoC
     sources, this report could be considered as contributing to
     a prospective \&amp;quot;Bazaar\&amp;quot; development model
     - to bring forward an even more robust compiler for a
     portable and perhaps prospering occam language."
}