[Ns-developers] suggested addition to coding style document

[Tommaso Pecorella]

I agree, but I have some little concerns about the "user" role.

In my point of view there are not two kinds of people using ns-3, there are 3.
- coders - the ns-3 contributors
- simulation builders - creating a simulation with ns-3 blocks
- end-users (might be or might not be also simulation builders)

Now, the point you're addressing is a concern for coders, not for simulation builders. But the bug might be spotted by end-users as well, possibly blaming ns-3 whereas the problem isn't in ns-3 but in how it has been used.

When you're talking about the model, you're obviously referring to the ns-3 "standard" distribution, not to what a simulation builder might write (with his/her bugs and mistakes). If I'm right you propose to use the NS_ABORT_MSG_UNLESS() to check if the simulation builder made a mistake in his/her own code, propagating it to the system (e.g., call something expecting a valid pointer and passing a null instead).

This in my opinion is not so clear in the text. Of course the straight and simple "use NS_ABORT_MSG_UNLESS() to check if the simulation builder is dumb" is not politically correct, so not to be used.

I'd change:
If the former, change the model to account properly for this
possibility, but if the latter, consider to use the following macro

to
If the former, change the model to account properly for this
possibility. In case of objects/functions using objects depending 
on the user's code, consider to use the following macro


Best regards,

Tommaso



On 19/feb/2010, at 22.13, Tom Henderson wrote:

> Since we have been fixing some (valid) concerns about null pointer
> references in our code, I thought it would help to document a design
> decision we made a while back, regarding whether and how to check for
> invalid pointers.  I propose to add the below to the coding style
> document if there are no concerns.
> 
> 
> In many places in the code, pointers are used without being checked
> whether they are valid.  Sometimes these lead to segmentation faults
> reported by users.  This project made a design decision to not
> always explicitly check pointer validity throughout the codebase.
> If segmentation faults are reported for
> null pointer values, the preferred way to address each one is to
> consider whether the model makes a poor assumption about whether a
> pointer should be valid or not at all points in time in the object
> lifecycle, or whether the error might represent a problem in the user
> code.  If the former, change the model to account properly for this
> possibility, but if the latter, consider to use the following macro
> (defined in src/core/abort.h) to alert the user more explicitly that an
> invalid pointer may be symptomatic of a problem in the user's code.
> <pre>
> #define NS_ABORT_MSG_UNLESS(cond, msg)
> </pre>
> But in general, if a pointer is assumed by a model to always be
> valid, one does not need to explicitly check it before each usage.

--------------------------------------------------------------

The nice thing about standards is that there are so many to choose from.
And if you really don't like all the standards you just have to wait another year until the one arises you are looking for.
-- A. Tanenbaum, "Introduction to Computer Networks"

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Elettronica e Telecomunicazioni
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: tommaso.pecorella at unifi.it
       tommaso.pecorella at cnit.it

phone : +39-055-4796412
mobile: +39-320-4379803
fax   : +39-055-494569