Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dbus
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 248
    • Issues 248
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 32
    • Merge requests 32
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • dbus
  • dbus
  • Issues
  • #38

Closed
Open
Created Feb 03, 2011 by Bugzilla Migration User@bugzilla-migration

lack of clarity in dbus-marshal-recursive.c: can type_str be NULL?

Submitted by Simon McVittie

Assigned to Simon McVittie

Link to original bug (#33870)

Description

+++ This bug was initially created as a clone of Bug #33128 +++

Attachment #42061 (a patch applied in Maemo) adds an assertion that writer->type_str can't be NULL in a particular part of the marshalling code, which was probably done to shut up a static analysis tool. It's not at all obvious whether the assertion is justified.

On closer inspection of the code, it seems that type_str can be NULL initially, but everything that uses it is guarded by extra initialization which ensures that it's non-NULL by copying in the message's signature. This is deferred until after dbus_message_iter_init, so that that function can't fail with OOM.

I think the right way to improve clarity here would be to rearrange the initialization so it's literally never NULL, then we can get rid of ~15 useless "is it NULL?" guards.

Possibilities include:

  • copy the signature in dbus_message_iter_init; if that fails, set an "already had OOM" flag which we check in all other accessors

  • defer initializing the writer until the point at which we currently copy in the signature

  • preallocate the DBusString for the signature as part of the DBusMessage

Version: 1.5

Depends on

  • Bug 38285
Assignee
Assign to
Time tracking