On Sunday 17 November 2013, Felix Salfelder wrote: > > This part of spice syntax doesn't have a counterpart in > > verilog syntax. > > yes. what do you suggest? raise an exception? i do not care > too much, but it should not segfault :)
Immediately, my suggestion followed in that same email. An assert in the code is documentation of some condition that is assumed to be true. An assert fail is not a bug in itself, but rather a hint at where the bug really is. In this case, _component_proto needs to be initialized non-NULL by a constructor. See other code such as the device models, d_switch, or d_logic. Longer term, it raises another issue that I have been aware of for a long time but don't have the answer yet. The other issue here is that there is a bug in a plugin that causes an assert fail in core, indicating a need for a change in strategy. A lot of the asserts in core should be considered as possible user errors, if you think of developing plugins as a user activity. Developing plugins really is a user activity. When we get our act together on the model compilers, gnucap could become the preferred platform for developing and debugging device models regardless of the target simulator. Stroustrup discusses this in "The C++ Programming Language". I see it moving in that direction. The problem with changing all of the asserts is that there would be a significant performance hit. > > > It is not a link back to the kind of device it matches, so > > that code is incorrect. > > agreed. > > > The real problem is that the constructor MODEL_SEMI**** is > > defective, so it should be fixed there. The purpose of > > _component_proto is exactly this, so the constructor must > > initialize it. > > hmm which value for _component_proto would be correct? if i > don't want an unconditional resistor, then i will have to > catch the null pointer somewhere within MODEL_CARD. See the other models to see how it is done there. I think this is the only one that is unclear. In others, one DEV can have many MODELs. For example .. levels of mosfets. But I think this is the only one that goes the other way. _______________________________________________ Gnucap-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnucap-devel
