After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 597999 - Inconsistent treating of assertions
Inconsistent treating of assertions
Status: RESOLVED OBSOLETE
Product: vala
Classification: Core
Component: general
0.7.x
Other All
: Normal enhancement
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2009-10-10 12:59 UTC by Aleksander Wabik
Modified: 2018-05-22 13:23 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Aleksander Wabik 2009-10-10 12:59:51 UTC
IMO there should be one, unified way of getting rid of assertions in code, when compiling. Now it looks like this:

1) all assertions (implicit & explicitly declared by assert()) are compiled in by default
2) --disable-assert disables only implicit assertions
3) to disable assert(), you CAN'T DO THIS AT THE VALA LEVEL. You must pass "-X -DG_DISABLE_ASSERT", and assertions will be disabled by the C compiler.

Asssertions are commonly used to check constrains in debug versions, I know that Glib gives them slightly different role, but there should be some way of debug-version-only asserting.

A little offtopic:

My proposition would be even to introduce keyword "debug" with syntax:

debug {
//statements
}

And the debug block would be compiled into program only in debug builds.
Comment 1 Michael 'Mickey' Lauer 2009-10-15 23:41:27 UTC
I agree that a device like that for debugging would be helpful. I'm not sure whether a dedicated keyword is not too intrusive. I'm with you on the subject of adding something to remove assert() creation at the Vala level though.
Comment 2 GNOME Infrastructure Team 2018-05-22 13:23:59 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/49.