[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnuastro-devel] [bug #48609] Modifier 'const' should be used for functi
From: |
Vladimir Markelov |
Subject: |
[gnuastro-devel] [bug #48609] Modifier 'const' should be used for function arguments and results where appropriate |
Date: |
Sun, 24 Jul 2016 01:56:54 +0000 (UTC) |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 |
URL:
<http://savannah.gnu.org/bugs/?48609>
Summary: Modifier 'const' should be used for function
arguments and results where appropriate
Project: GNU Astronomy Utilities
Submitted by: vvm
Submitted on: Sat 23 Jul 2016 06:56:52 PM PDT
Category: All Gnuastro
Severity: 3 - Normal
Item Group: Source code
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Details:
A lot of functions takes pointers to data and returns pointers. It would be
good to mark 'const' pointers if a function does not change the data or a
caller should not change the returned data.
Why:
1. It will be a good hint for a user - a person can easily see if a function
changes his/her data or function just reads them
2. A compiler can be a real helper and warn a user if the user tries to change
the data(returned by a function) that should be changed at all
A good example for #2 is function 'hdutypestring'. It returns 'char*' but
really it returns a pointer to read-only data, so a client code will likely to
crash if, e.g, the client code tries to change the returned value in place. A
compiler warns the user in this case about casting a 'const char*' to 'char
*'.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?48609>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [gnuastro-devel] [bug #48609] Modifier 'const' should be used for function arguments and results where appropriate,
Vladimir Markelov <=