"PTTLink Wiki" - User contributions [en]

Stats Server

2018-03-03T13:52:07Z

KD3SU: link

Status server

Requires graphviz

This consists of several C programs as CGI's and uses LMDB to store data nodes post to the server.

The source is under /usr/local/src/status

* index.cgi - generates the code for the index page and textual output
* uhandler.cgi - receives the http get requests of data from the nodes and writes it to the LMDB
* nodeinfo.cgi - gives the per node report text page
* getconn.cgi - not really needed for the user interface. ?$NODE returns text with the total number of connected nodes and the state of each connected node separated by pipes
* statsdb.cgi - not needed for the interface. If the compiled in IP is matched, it will return a dump of the database.
* jsondata.cgi - not needed for the interface, used for returning JSON formated node data from database.
* getstatus.cgi - generates the per node PNG image using getstatus and neato. This is a bash script.
* graphic-status.html - used to display the big network wide graph

These next are not publicly accessible files and are called by the system for generating the various parts of the config.

These must be installed under /var/www/stats-private
* updatenodesdb - updates the database from the registration server. The registration server must permit this.

* dostatus - executed from roots crontab, and makes the overall network PNG

* mkstatslmdb - makes the raw stats LMDB if not there, might be good to run on boot
* mkstatus - used by dostatus, it makes the text data that neato uses to make the large graph
* getstatus - used by getstatus.cgi, it makes the text data neato uses to build the per node graph
* /var/www/stats-private/stats-lmdb - location of the LMDB database. This should be compiled in.
For speed we can run the stats db on a tempfs in memory. I've disabled this for now. but it could be enabled in /etc/fstab.

'''Note: The db hangs from time to time and one needs to run a cron job of /usr/local/src/liblmdb/mdb_stat -rr /var/www/stats-private/stats-lmdb to clear the stale readers. see: http://www.lmdb.tech/doc/index.html'''

Helper scripts

2018-01-27T21:37:26Z

KD3SU: Initial

{| class="wikitable"
|-
! Script Name !! Purpose
|-
| astdn.sh || Shuts down Asterisk
|-
| astres.sh|| Restarts Asterisk. Use to fore a reload of all configuration files.
|-
| astupd.sh || Fetch, compile and install the latest version of Asterisk
|-
| astup.sh || Starts up Asterisk
|}

Coding standards

2018-01-27T17:45:01Z

KD3SU:

== Open Source ==
Allstar is an open-source project licensed under the GPL based on [https://www.asterisk.org/ Asterisk] and written in C. This means you get the source code and can make any modifications you wish provided you make your modifications available to the community.

== Formatting source code ==

Keep the length of source lines to 79 characters or less, for maximum readability in the widest range of environments.

It is important to put the open-brace that starts the body of a C function in column one, so that they will start a defun. Several tools look for open-braces in column one to find the beginnings of C functions. These tools will not work on code not formatted that way.

Avoid putting open-brace, open-parenthesis or open-bracket in column one when they are inside a function, so that they won’t start a defun. The open-brace that starts a struct body can go in column one if you find it useful to treat that definition as a defun.

It is also important for function definitions to start the name of the function in column one. This helps people to search for function definitions, and may also help certain tools recognize them. Thus, using Standard C syntax, the format is this

For more details : https://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting

== Comments ==

Every program should start with a comment saying briefly what it is for. Example: ‘fmt - filter for simple filling of text’. This comment should be at the top of the source file containing the ‘main’ function of the program.

Also, please write a brief comment at the start of each source file, with the file name and a line or two about the overall purpose of the file.

Please write the comments in a GNU program in English, because English is the one language that nearly all programmers in all countries can read. If you do not write English well, please write comments in English as well as you can, then ask other people to help rewrite them. If you can’t write comments in English, please find someone to work with you and translate your comments into English.

Please put a comment on each function saying what the function does, what sorts of arguments it gets, and what the possible values of arguments mean and are used for. It is not necessary to duplicate in words the meaning of the C argument declarations, if a C type is being used in its customary fashion. If there is anything nonstandard about its use (such as an argument of type char * which is really the address of the second character of a string, not the first), or any possible values that would not work the way one would expect (such as, that strings containing newlines are not guaranteed to work), be sure to say so.

Also explain the significance of the return value, if there is one.

Please put two spaces after the end of a sentence in your comments, so that the Emacs sentence commands will work. Also, please write complete sentences and capitalize the first word. If a lower-case identifier comes at the beginning of a sentence, don’t capitalize it! Changing the spelling makes it a different identifier. If you don’t like starting a sentence with a lower case letter, write the sentence differently (e.g., “The identifier lower-case is …”).

The comment on a function is much clearer if you use the argument names to speak about the argument values. The variable name itself should be lower case, but write it in upper case when you are speaking about the value rather than the variable itself. Thus, “the inode number NODE_NUM” rather than “an inode”.

There is usually no purpose in restating the name of the function in the comment before it, because readers can see that for themselves. There might be an exception when the comment is so long that the function itself would be off the bottom of the screen.

See: https://www.gnu.org/prep/standards/html_node/Comments.html#Comments

== Syntactic Conventions ==
* Clean use of C constructs.

Don’t make the program ugly just to placate static analysis tools such as lint, clang, and GCC with extra warnings options such as -Wconversion and -Wundef. These tools can help find bugs and unclear code, but they can also generate so many false alarms that it hurts readability to silence them with unnecessary casts, wrappers, and other complications. For example, please don’t insert casts to void or calls to do-nothing functions merely to pacify a lint checker.

Declarations of external functions and functions to appear later in the source file should all go in one place near the beginning of the file (somewhere before the first function definition in the file), or else should go in a header file. Don’t put extern declarations inside functions.

It used to be common practice to use the same local variables (with names like tem) over and over for different values within one function. Instead of doing this, it is better to declare a separate local variable for each distinct purpose, and give it a name which is meaningful. This not only makes programs easier to understand, it also facilitates optimization by good compilers. You can also move the declaration of each local variable into the smallest scope that includes all its uses. This makes the program even cleaner.

Don’t use local variables or parameters that shadow global identifiers. GCC’s ‘-Wshadow’ option can detect this problem.

See: https://www.gnu.org/prep/standards/html_node/Syntactic-Conventions.html#Syntactic-Conventions

== Naming variables, functions, and files ==

The names of global variables and functions in a program serve as comments of a sort. So don’t choose terse names—instead, look for names that give useful information about the meaning of the variable or function. In a GNU program, names should be English, like other comments.

Local variable names can be shorter, because they are used only within one context, where (presumably) comments explain their purpose.

Try to limit your use of abbreviations in symbol names. It is ok to make a few abbreviations, explain what they mean, and then use them frequently, but don’t use lots of obscure abbreviations.

Please use underscores to separate words in a name, so that the Emacs word commands can be useful within them. Stick to lower case; reserve upper case for macros and enum constants, and for name-prefixes that follow a uniform convention.

For example, you should use names like ignore_space_change_flag; don’t use names like iCantReadThis.

Variables that indicate whether command-line options have been specified should be named after the meaning of the option, not after the option-letter. A comment should state both the exact meaning of the option and its letter.

https://www.gnu.org/prep/standards/html_node/Names.html#Names

==Portability between System Types==

In the Unix world, “portability” refers to porting to different Unix versions. For a GNU program, this kind of portability is desirable, but not paramount.

The primary purpose of GNU software is to run on top of the GNU kernel, compiled with the GNU C compiler, on various types of CPU. So the kinds of portability that are absolutely necessary are quite limited. But it is important to support Linux-based GNU systems, since they are the form of GNU that is popular.

Beyond that, it is good to support the other free operating systems (*BSD), and it is nice to support other Unix-like systems if you want to. Supporting a variety of Unix-like systems is desirable, although not paramount. It is usually not too hard, so you may as well do it. But you don’t have to consider it an obligation, if it does turn out to be hard.

The easiest way to achieve portability to most Unix-like systems is to use Autoconf. It’s unlikely that your program needs to know more information about the host platform than Autoconf can provide, simply because most of the programs that need such knowledge have already been written.

Avoid using the format of semi-internal data bases (e.g., directories) when there is a higher-level alternative (readdir).

As for systems that are not like Unix, such as MSDOS, Windows, VMS, MVS, and older Macintosh systems, supporting them is often a lot of work. When that is the case, it is better to spend your time adding features that will be useful on GNU and GNU/Linux, rather than on supporting other incompatible systems.

If you do support Windows, please do not abbreviate it as “win”. In hacker terminology, calling something a “win” is a form of praise. You’re free to praise Microsoft Windows on your own if you want, but please don’t do this in GNU packages. Instead of abbreviating “Windows” to “win”, you can write it in full or abbreviate it to “woe” or “w”. In GNU Emacs, for instance, we use ‘w32’ in file names of Windows-specific files, but the macro for Windows conditionals is called WINDOWSNT.

It is a good idea to define the “feature test macro” _GNU_SOURCE when compiling your C files. When you compile on GNU or GNU/Linux, this will enable the declarations of GNU library extension functions, and that will usually give you a compiler error message if you define the same function names in some other way in your program. (You don’t have to actually use these functions, if you prefer to make the program more portable to other systems.)

But whether or not you use these GNU extensions, you should avoid using their names for any other meanings. Doing so would make it hard to move your code into other GNU programs.

https://www.gnu.org/prep/standards/html_node/System-Portability.html#System-Portability

* CPU Portability: Supporting the range of CPU types.
* System Functions: Portability and “standard” library functions.

Coding standards

2018-01-27T17:38:36Z

KD3SU: misc

== Formatting source code ==

Keep the length of source lines to 79 characters or less, for maximum readability in the widest range of environments.

It is important to put the open-brace that starts the body of a C function in column one, so that they will start a defun. Several tools look for open-braces in column one to find the beginnings of C functions. These tools will not work on code not formatted that way.

Avoid putting open-brace, open-parenthesis or open-bracket in column one when they are inside a function, so that they won’t start a defun. The open-brace that starts a struct body can go in column one if you find it useful to treat that definition as a defun.

It is also important for function definitions to start the name of the function in column one. This helps people to search for function definitions, and may also help certain tools recognize them. Thus, using Standard C syntax, the format is this

For more details : https://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting

== Comments ==

Every program should start with a comment saying briefly what it is for. Example: ‘fmt - filter for simple filling of text’. This comment should be at the top of the source file containing the ‘main’ function of the program.

Also, please write a brief comment at the start of each source file, with the file name and a line or two about the overall purpose of the file.

Please write the comments in a GNU program in English, because English is the one language that nearly all programmers in all countries can read. If you do not write English well, please write comments in English as well as you can, then ask other people to help rewrite them. If you can’t write comments in English, please find someone to work with you and translate your comments into English.

Please put a comment on each function saying what the function does, what sorts of arguments it gets, and what the possible values of arguments mean and are used for. It is not necessary to duplicate in words the meaning of the C argument declarations, if a C type is being used in its customary fashion. If there is anything nonstandard about its use (such as an argument of type char * which is really the address of the second character of a string, not the first), or any possible values that would not work the way one would expect (such as, that strings containing newlines are not guaranteed to work), be sure to say so.

Also explain the significance of the return value, if there is one.

Please put two spaces after the end of a sentence in your comments, so that the Emacs sentence commands will work. Also, please write complete sentences and capitalize the first word. If a lower-case identifier comes at the beginning of a sentence, don’t capitalize it! Changing the spelling makes it a different identifier. If you don’t like starting a sentence with a lower case letter, write the sentence differently (e.g., “The identifier lower-case is …”).

The comment on a function is much clearer if you use the argument names to speak about the argument values. The variable name itself should be lower case, but write it in upper case when you are speaking about the value rather than the variable itself. Thus, “the inode number NODE_NUM” rather than “an inode”.

There is usually no purpose in restating the name of the function in the comment before it, because readers can see that for themselves. There might be an exception when the comment is so long that the function itself would be off the bottom of the screen.

See: https://www.gnu.org/prep/standards/html_node/Comments.html#Comments

== Syntactic Conventions ==
* Clean use of C constructs.

Don’t make the program ugly just to placate static analysis tools such as lint, clang, and GCC with extra warnings options such as -Wconversion and -Wundef. These tools can help find bugs and unclear code, but they can also generate so many false alarms that it hurts readability to silence them with unnecessary casts, wrappers, and other complications. For example, please don’t insert casts to void or calls to do-nothing functions merely to pacify a lint checker.

Declarations of external functions and functions to appear later in the source file should all go in one place near the beginning of the file (somewhere before the first function definition in the file), or else should go in a header file. Don’t put extern declarations inside functions.

It used to be common practice to use the same local variables (with names like tem) over and over for different values within one function. Instead of doing this, it is better to declare a separate local variable for each distinct purpose, and give it a name which is meaningful. This not only makes programs easier to understand, it also facilitates optimization by good compilers. You can also move the declaration of each local variable into the smallest scope that includes all its uses. This makes the program even cleaner.

Don’t use local variables or parameters that shadow global identifiers. GCC’s ‘-Wshadow’ option can detect this problem.

See: https://www.gnu.org/prep/standards/html_node/Syntactic-Conventions.html#Syntactic-Conventions

== Naming variables, functions, and files ==

The names of global variables and functions in a program serve as comments of a sort. So don’t choose terse names—instead, look for names that give useful information about the meaning of the variable or function. In a GNU program, names should be English, like other comments.

Local variable names can be shorter, because they are used only within one context, where (presumably) comments explain their purpose.

Try to limit your use of abbreviations in symbol names. It is ok to make a few abbreviations, explain what they mean, and then use them frequently, but don’t use lots of obscure abbreviations.

Please use underscores to separate words in a name, so that the Emacs word commands can be useful within them. Stick to lower case; reserve upper case for macros and enum constants, and for name-prefixes that follow a uniform convention.

For example, you should use names like ignore_space_change_flag; don’t use names like iCantReadThis.

Variables that indicate whether command-line options have been specified should be named after the meaning of the option, not after the option-letter. A comment should state both the exact meaning of the option and its letter.

https://www.gnu.org/prep/standards/html_node/Names.html#Names

==Portability between System Types==

In the Unix world, “portability” refers to porting to different Unix versions. For a GNU program, this kind of portability is desirable, but not paramount.

The primary purpose of GNU software is to run on top of the GNU kernel, compiled with the GNU C compiler, on various types of CPU. So the kinds of portability that are absolutely necessary are quite limited. But it is important to support Linux-based GNU systems, since they are the form of GNU that is popular.

Beyond that, it is good to support the other free operating systems (*BSD), and it is nice to support other Unix-like systems if you want to. Supporting a variety of Unix-like systems is desirable, although not paramount. It is usually not too hard, so you may as well do it. But you don’t have to consider it an obligation, if it does turn out to be hard.

The easiest way to achieve portability to most Unix-like systems is to use Autoconf. It’s unlikely that your program needs to know more information about the host platform than Autoconf can provide, simply because most of the programs that need such knowledge have already been written.

Avoid using the format of semi-internal data bases (e.g., directories) when there is a higher-level alternative (readdir).

As for systems that are not like Unix, such as MSDOS, Windows, VMS, MVS, and older Macintosh systems, supporting them is often a lot of work. When that is the case, it is better to spend your time adding features that will be useful on GNU and GNU/Linux, rather than on supporting other incompatible systems.

If you do support Windows, please do not abbreviate it as “win”. In hacker terminology, calling something a “win” is a form of praise. You’re free to praise Microsoft Windows on your own if you want, but please don’t do this in GNU packages. Instead of abbreviating “Windows” to “win”, you can write it in full or abbreviate it to “woe” or “w”. In GNU Emacs, for instance, we use ‘w32’ in file names of Windows-specific files, but the macro for Windows conditionals is called WINDOWSNT.

It is a good idea to define the “feature test macro” _GNU_SOURCE when compiling your C files. When you compile on GNU or GNU/Linux, this will enable the declarations of GNU library extension functions, and that will usually give you a compiler error message if you define the same function names in some other way in your program. (You don’t have to actually use these functions, if you prefer to make the program more portable to other systems.)

But whether or not you use these GNU extensions, you should avoid using their names for any other meanings. Doing so would make it hard to move your code into other GNU programs.

https://www.gnu.org/prep/standards/html_node/System-Portability.html#System-Portability

* CPU Portability: Supporting the range of CPU types.
* System Functions: Portability and “standard” library functions.

Main Page

2018-01-27T16:56:12Z

KD3SU: typo

Welcome to the AllStarLink Wiki. We're gradually moving content from [http://docs.allstarlink.org docs.allstarlink.org] to this new Wiki site.
__NOTOC__
=AllStarLink Menu=
*[[DIAL FAQ]] - Questions and answers about the AllStarLink software distribution.
*[[Features]] - List of AllStarLink Features
*[[:Category:How to|How To's]] - A collection of AllStarLink how to's.
*[[:Category:Node Configuration|Node Configuration]] - Detail configuration settings.
*[[Radio Connections]] - Instructions to Connect Radios, Repeaters and Other Devices to AllStar.

=Downloads=
* [http://dvswitch.org/files/AllStarLink/allstar-firmware-8.7.1-amd64-i386-netinst.tar.gz DIAL AMD] Latest DIAL for x86/AMD
* [http://dvswitch.org/files/AllStarLink/RAT_RC1.tar.gz DIAL Pi] Latest DIAL for the Raspberry Pi

=RTCM Info=
The Radio Thin Client Module (RTCM) is commercially available hardware for interfacing radios to an AllStarLink computer.
*[[RTCM Client]] - About the RTCM hardware itself.
*[[RTCM Channel Driver]] - About the RTCM server software.

=Related Links=
* [https://allstarlink.org/ AllStarLink Portal] - If you are looking to set up your own AllStarLink node.
* [http://stats.allstarlink.org/ AllStarLink Stats] - shows all the existing public nodes.
* [http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users AllStarLink users mailing list]- This is the app_rpt mailing list for discussion, help and helping others.
* [https://allstar.aargdmr.net/ Development Portal Site] - Our Portal development site. Check out the searchable and sortable [https://allstar.aargdmr.net/nodelist/ Node List].
* [https://github.com/AllStarLink/ Source Code] - All of the source code for the DIAL, Asterisk and app_rpt is available on GitHub.

=History=
* [[History]] from the Duuude, Jim Dixon WB6NIL SK.

=WiKi Getting started=
* You do not need an account on this site to use it. However, if you would like to help us document AllStar then please do request an account using the link above.
* Consult the [https://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

=Source Code=
* [https://github.com/AllStarLink/ Source Code] - All of the source code for the DIAL, Asterisk and app_rpt is available on GitHub.

* [[Coding standards|C Coding standards]] Based on GNU's "Making The Best Use of C"

Main Page

2018-01-27T16:55:49Z

KD3SU: Started adding a separate area on Allstar Source code

Welcome to the AllStarLink Wiki. We're gradually moving content from [http://docs.allstarlink.org docs.allstarlink.org] to this new Wiki site.
__NOTOC__
=AllStarLink Menu=
*[[DIAL FAQ]] - Questions and answers about the AllStarLink software distribution.
*[[Features]] - List of AllStarLink Features
*[[:Category:How to|How To's]] - A collection of AllStarLink how to's.
*[[:Category:Node Configuration|Node Configuration]] - Detail configuration settings.
*[[Radio Connections]] - Instructions to Connect Radios, Repeaters and Other Devices to AllStar.

=Downloads=
* [http://dvswitch.org/files/AllStarLink/allstar-firmware-8.7.1-amd64-i386-netinst.tar.gz DIAL AMD] Latest DIAL for x86/AMD
* [http://dvswitch.org/files/AllStarLink/RAT_RC1.tar.gz DIAL Pi] Latest DIAL for the Raspberry Pi

=RTCM Info=
The Radio Thin Client Module (RTCM) is commercially available hardware for interfacing radios to an AllStarLink computer.
*[[RTCM Client]] - About the RTCM hardware itself.
*[[RTCM Channel Driver]] - About the RTCM server software.

=Related Links=
* [https://allstarlink.org/ AllStarLink Portal] - If you are looking to set up your own AllStarLink node.
* [http://stats.allstarlink.org/ AllStarLink Stats] - shows all the existing public nodes.
* [http://lists.allstarlink.org/cgi-bin/mailman/listinfo/app_rpt-users AllStarLink users mailing list]- This is the app_rpt mailing list for discussion, help and helping others.
* [https://allstar.aargdmr.net/ Development Portal Site] - Our Portal development site. Check out the searchable and sortable [https://allstar.aargdmr.net/nodelist/ Node List].
* [https://github.com/AllStarLink/ Source Code] - All of the source code for the DIAL, Asterisk and app_rpt is available on GitHub.

=History=
* [[History]] from the Duuude, Jim Dixon WB6NIL SK.

=WiKi Getting started=
* You do not need an account on this site to use it. However, if you would like to help us document AllStar then please do request an account using the link above.
* Consult the [https://meta.wikimedia.org/wiki/Help:Contents User's Guide] for information on using the wiki software.
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]
* [https://lists.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]
* [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]

=Source Code=
* [https://github.com/AllStarLink/ Source Code] - All of the source code for the DIAL, Asterisk and app_rpt is available on GitHub.

[[Coding standards|C Coding standards]] Based on GNU's "Making The Best Use of C"

Coding standards

2018-01-27T16:53:18Z

KD3SU: Added some info on C coding standards from GNU

== Formatting: ==
* Formatting your source code.

Keep the length of source lines to 79 characters or less, for maximum readability in the widest range of environments.

It is important to put the open-brace that starts the body of a C function in column one, so that they will start a defun. Several tools look for open-braces in column one to find the beginnings of C functions. These tools will not work on code not formatted that way.

Avoid putting open-brace, open-parenthesis or open-bracket in column one when they are inside a function, so that they won’t start a defun. The open-brace that starts a struct body can go in column one if you find it useful to treat that definition as a defun.

It is also important for function definitions to start the name of the function in column one. This helps people to search for function definitions, and may also help certain tools recognize them. Thus, using Standard C syntax, the format is this

For more details : https://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting

== Comments ==
* Commenting your work.
Every program should start with a comment saying briefly what it is for. Example: ‘fmt - filter for simple filling of text’. This comment should be at the top of the source file containing the ‘main’ function of the program.

Also, please write a brief comment at the start of each source file, with the file name and a line or two about the overall purpose of the file.

Please write the comments in a GNU program in English, because English is the one language that nearly all programmers in all countries can read. If you do not write English well, please write comments in English as well as you can, then ask other people to help rewrite them. If you can’t write comments in English, please find someone to work with you and translate your comments into English.

Please put a comment on each function saying what the function does, what sorts of arguments it gets, and what the possible values of arguments mean and are used for. It is not necessary to duplicate in words the meaning of the C argument declarations, if a C type is being used in its customary fashion. If there is anything nonstandard about its use (such as an argument of type char * which is really the address of the second character of a string, not the first), or any possible values that would not work the way one would expect (such as, that strings containing newlines are not guaranteed to work), be sure to say so.

Also explain the significance of the return value, if there is one.

Please put two spaces after the end of a sentence in your comments, so that the Emacs sentence commands will work. Also, please write complete sentences and capitalize the first word. If a lower-case identifier comes at the beginning of a sentence, don’t capitalize it! Changing the spelling makes it a different identifier. If you don’t like starting a sentence with a lower case letter, write the sentence differently (e.g., “The identifier lower-case is …”).

The comment on a function is much clearer if you use the argument names to speak about the argument values. The variable name itself should be lower case, but write it in upper case when you are speaking about the value rather than the variable itself. Thus, “the inode number NODE_NUM” rather than “an inode”.

There is usually no purpose in restating the name of the function in the comment before it, because readers can see that for themselves. There might be an exception when the comment is so long that the function itself would be off the bottom of the screen.

https://www.gnu.org/prep/standards/html_node/Comments.html#Comments

* Syntactic Conventions: Clean use of C constructs.
* Names: Naming variables, functions, and files.
* System Portability: Portability among different operating systems.
* CPU Portability: Supporting the range of CPU types.
* System Functions: Portability and “standard” library functions.

Coding standards

2018-01-27T16:51:24Z

KD3SU: Created page with "== Formatting: == * Formatting your source code. Keep the length of source lines to 79 characters or less, for maximum readability in the widest range of environments. It..."

Main Page

2018-01-27T16:43:44Z

KD3SU:

Stats Server

2018-01-27T12:55:58Z

KD3SU: