Supported type suffixes

Example:

{variable:int}

Supported

  • :int
  • :long
  • :size_t
  • :float
  • :double
  • :number
  • :bool
  • :time
  • :string
  • :html

Behavior:

  • :string renders as a string and escapes HTML.
  • :html renders unescaped via cweb_output_raw(...).
  • :bool becomes "true" or "false".
  • :time is formatted using localtime(...) and strftime("%Y-%m-%d %H:%M:%S", ...).
  • Numeric types are converted to text via snprintf(...).

Default behavior without a type suffix

Without a suffix, the generator emits:

if (expr) cweb_output_html(expr);

That only makes sense for expressions that can be used like char*. For numbers or other non-string types, the default is not appropriate.

So in practice:

  • Always add a type suffix for numbers.
  • Also annotate time_t, bool, size_t, and similar types explicitly.
  • Without a suffix, the system is not type-inference-based.

Type safety: what is true about it, and what is not

What is actually type-safe

Type safety here comes from two sources:

  1. Your data structure is a real C type.
  2. The generated template is real C code and is compiled normally.

If, for example, you use data->menu_count, the C compiler checks whether that field exists and whether the generated code is syntactically and semantically valid.

What is not automatically checked

The type suffixes are not real type inference. The generator trusts your annotation.

Examples:

  • {x:int} does not enforce that x is actually an int.
  • {x:string} does not enforce that x is actually a char *.
  • Wrong annotations can lead to compile errors, warnings, or incorrect formatting, depending on the case.

So the system is better described as:

  • C-typed
  • compile-time validated
  • but not template-inference-based