Re: [Qemu-devel] [PATCH 1/5] s390x/css: introduce css data stream

[Halil Pasic <pasic@linux.vnet.ibm.com>]

On 09/13/2017 11:53 AM, Cornelia Huck wrote:
> On Mon, 11 Sep 2017 18:36:00 +0200
> Halil Pasic <pasic@linux.vnet.ibm.com> wrote:
> 
>> On 09/06/2017 02:51 PM, Cornelia Huck wrote:
>>>>>> +void ccw_dstream_init(CcwDataStream *cds, CCW1 const *ccw, ORB const *orb)
>>>>>> +{
>>>>>> +    /*
>>>>>> +     * We don't support MIDA (an optional facility) yet and we
>>>>>> +     * catch this earlier. Just for expressing the precondition.
>>>>>> +     */
>>>>>> +    assert(!(orb->ctrl1 & ORB_CTRL1_MASK_MIDAW));    
>>>>> I don't know, this is infrastructure, should it trust its callers? If
>>>>> you keep the assert, please make it g_assert().    
>>>>
>>>> Why g_assert? I think g_assert comes form a test framework, this is not
>>>> test code.  
>>> g_assert() is glib, no?
>>>   
>>
>> It lives in GLib > GLib Utilities > Testing:
>> https://developer.gnome.org/glib/stable/glib-Testing.html
>>
>> The description of "Testing" starts like this: "GLib provides a framework
>> for writing and maintaining unit tests in parallel to the code they are
>> testing. The API is designed according to established concepts found in
>> the other test frameworks (JUnit, NUnit, RUnit), which in turn is based
>> on smalltalk unit testing concepts."
>>
>> So yes, it's both glib and testing framework. This is why I
>> ask why should one use g_assert in not-unit-test code.
> 
> I have searched the archives, but unfortunately was not able to come to
> a conclusion. Checkpatch advises against using anything but g_assert or
> g_assert_not_reached in anything but test code, but that is because
> those other g_asserts can be made non-fatal. g_assert_not_reached does
> not seem to have a non-glib equivalent.
> 

I think the standard library equivalent of g_assert_not_reached is
assert(false).

Yeah, checkpatch does not advise against using g_assert and
g_assert_not_reached in non-test code, but it does not advise against
using standard lib assert.

> I have it somewhere in the back of my mind that g_assert should be
> preferred...
> 

OK, I will use g_assert.